Skip to content

Expose ~JSX namespace~ HResult globally #18

Closed

Description

@alecmev

Initial checklist

Problem

I'm using TypeScript with "moduleResolution": "Node16" and JSX, and I want to have explicit return types. Currently I do this:

import type { Root, Element } from "hast";
const Foo = (): Root | Element => <div />;

Instead, I'd like to be able to do this:

const Foo = (): JSX.Element => <div />;

I know it's an alias of HResult, which can be imported from lib/core, but it isn't idiomatic, and lib/core currently isn't exposed, so it doesn't work in this module resolution mode.

Solution

@types/react puts JSX in declare global. Could hastscript do that too?

Alternatives

Export lib/core.

Activity

  1. added
    👋 phase/newPost is being triaged automatically
    🤞 phase/openPost is being triaged manually
    and removed
    👋 phase/newPost is being triaged automatically
    on Aug 22, 2022
  2. wooorm commented on Aug 22, 2022

    @wooorm
    Member

    Sounds like something @remcohaszing has ideas on!

  3. remcohaszing commented on Aug 22, 2022

    @remcohaszing
    Member

    The node16 resolution type is the correct one for native ESM, and therefor for unified packages internally. Unfortunately not all of the ecosystem is compatible yet (davidbonnet/astring#646). This needs to be resolved first, then I can look at how all of this affects hastscript.

    A quick history on this topic:

    • At first the TypeScript JSX namespace had to be global.
      declare global {
        namespace JSX {
          // …
        }
      }
      During this time the React types were created.
    • At some point TypeScript allowed specifying local JSX namespaces
      declare function h();
      
      namespace h.JSX {
        // …
      }
      This allows people to mix multiple JSX implementations in different filed within the same project 🤯 So these two files could live in the same project:
      // react-hello.tsx
      import React from 'react'
      
      const Hello = () => <div>Hello</div>
      // hastscript-hello.tsx
      /* @jsx h */
      import { h } from 'hastscript'
      
      const Hello = () => <div>Hello</div>
    • Then the automatic runtime was released.

    As far as I know, this requires a global JSX namespace. However, this issue suggests this is incorrect. If this is indeed incorrect, then IMO it is the desired behaviour, because it would allow to mix multiple JSX implementationg using JSX comments.

    I do think it would be nice to expose the HResult type though. I totally agree it makes sense to use this type, i.e. for explicit return types as the OP suggests.

    import { HResult } from 'hastscript'
    
    const Foo = (): HResult => <div />;
  4. alecmev commented on Aug 22, 2022

    @alecmev
    Author

    Thanks, that makes sense! So I went ahead and checked if anybody has reported this in TypeScript, since this feels like their responsibility, and I found something even better: microsoft/TypeScript#41330 (comment) Here's how Preact implemented it: https://github.com/preactjs/preact/pull/2811/files Edit: And I see that it's already exported, so why doesn't it work? Edit 2: Ah, likely because it isn't re-exported here and here and here. Edit 3: No, I still don't understand why this isn't sufficient:

    // svg/jsx-runtime.d.ts
    
    export * from '../lib/runtime-svg.js'
    
    // lib/runtime-svg.d.ts
    
    export * from './jsx-automatic.js'
    
    // lib/jsx-automatic.d.ts
    
    export namespace JSX ...

    Edit 4: Okay, finally found the definitive answer to this: microsoft/TypeScript#47072 (comment) The JSX namespace is an implementation detail, not meant to be public. So, in the end, import { HResult } is the way to go.

  5. wooorm commented on Aug 23, 2022

    @wooorm
    Member

    As far as I understand the above comments, then it would be bad to do this?
    And exposing HResult is an adequate solution?

  6. alecmev commented on Aug 23, 2022

    @alecmev
    Author

    it would be bad to do this?

    Yep! Looks like JSX isn't meant to be accessed ever.

    exposing HResult is an adequate solution?

    I believe so. The name is a little cryptic, but it's not worth a refactor, and breaking existing consumers.

  7. wooorm commented on Aug 24, 2022

    @wooorm
    Member

    I’m up for exposing HResult, I don’t see downsides.
    @alecmev Interested in working on a PR?

  8. changed the title [-]Expose JSX namespace globally[/-] [+]Expose ~JSX namespace~ `HResult` globally[/+] on Aug 24, 2022
  9. github-actions commented on Aug 24, 2022

    @github-actions
  10. github-actions commented on Oct 10, 2022

    @github-actions
  11. wooorm commented on Oct 10, 2022

    @wooorm
    Member

    Released in 7.1.0!

    I noticed that HChild, HProperties, were also exposed as Child and Properties, so I used Result as the type name for this

  12. alecmev commented on Dec 22, 2022

    @alecmev
    Author

    Sorry for the radio silence, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions