Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 9/29/2021 #46141

Closed
DanielRosenwasser opened this issue Sep 30, 2021 · 2 comments
Closed

Design Meeting Notes, 9/29/2021 #46141

DanielRosenwasser opened this issue Sep 30, 2021 · 2 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Sep 30, 2021

jsx: preserve Without Importing React

#41762

  • This is the mode where we don't transform JSX into plain JavaScript
  • TypeScript is still telling users "you still need to have React in scope" because we think it's going to become React.createElement.
  • But...we're not able to reproduce the error because React has a global UMD declaration. So how are users running into this?
  • Regardless, React is not going to be a global for some of these people.
  • allowUmdGlobalAccess
  • Seems like we trigger a look-up for React in jsx: preserve.
    • Ideally we wouldn't - everything should be defined in the JSX namespace?
  • This error in jsx: preserve is useful for people who are using older React, or if the JSX namespace isn't found for some reason.
  • Why is Next.js not using jsx: react17?
  • Oh no, how does this affect path resolution?
    • need to import from the .jsx file when module: node12 and jsx: preserve 😬
  • People are positive on decoupling the look-up.
  • Do we need a flag to turn the error off?
    • Can safely disable if jsxImportSource is enabled; don't need to introduce a new flag.
    • Some justification for original design.
    • Does that make sense in a mode where you don't really need to import React?
      • Maybe yes because we look up information in the React namespace.
  • Feel like we need to get a clear easy repro before we make a move.
  • Plausible that jsxImportSource is enough today.

Template Literal Types as Discriminants

#46137

Someone suggested something like this ought to work.

export type Action =
    | { type: `${string}_REQUEST` }
    | { type: `${string}_SUCCESS`, response: string };
  • Uncovered some issues around template literal types.
    • `${string}-bar` is not comparable with `foo-${string}`.
      • But that's not true.
    • Also, when comparing a string to a "thing" | `foo-${string}` we used to narrow the string to "thing" as opposed to the whole union.
  • CheckFlags.HasLiteralType is the magic that lets templates act as discriminants.
  • We loosen restrictions on comparability by saying template string types are always related unless we can immediately dismiss them.
  • [[Gripes around comparability being not fully bidirectional, which doesn't capture the full picture of things.]]
    • Sometimes that's fine.
    • Can say "if there's nothing in the intersection, then they're not comparable", but almost all object types can form a valid intersection.
@jasonwilliams
Copy link

Seems like we trigger a look-up for React in jsx: preserve.
Ideally we wouldn't - everything should be defined in the JSX namespace?

This error in jsx: preserve is useful for people who are using older React, or if the JSX namespace isn't found for some reason.

Why is Next.js not using jsx: react17?

Hi @DanielRosenwasser do you know if there's answers to any of these from your meeting?
Those of us on Next seem to be stuck with the "importing react" issue when using JSX/TSX :(

Issue here:
vercel/next.js#27212

@andrewbranch
Copy link
Member

That was fixed in #46368

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

3 participants