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, 10/28/2022 #51344

Closed
DanielRosenwasser opened this issue Oct 28, 2022 · 2 comments
Closed

Design Meeting Notes, 10/28/2022 #51344

DanielRosenwasser opened this issue Oct 28, 2022 · 2 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Specify Acceptable JSX Tags with JSX.ElementType

#51328

  • Menu can't restrict its children to MenuItems because <JSXTags> always returns JSX.Element.
  • Tried to fix this - huge perf and compat issues.
  • Why are we revisiting?
  • Will this work for class components/render methods?
    • Unclear from the proposal.
  • ElementType specifies what the type of a tag can be.
  • Seems reasonable overall? Some questions though.
    • Why does it need generics?
    • Why can't we modify JSXElementConstructor?
      • Try that offline.
  • Two concepts
    • What can functions used as tags return?

      • JSX.Element
    • What type can tags have?

      • JSX.Renderable
    • Playground Example

      import * as React from "react";
      
      function Foo(): JSX.Renderable {
          return "hello!";
      }
      
      // What type can tags have?                - JSX.Renderable(?)
      // What can functions used as tags return? - JSX.Element
      
      // () => string assignable to () => JSX.Element
      const element = <Foo />;
      //    ^?
      
      const divTag = <div />
      //    ^?
  • Conclusion: not opposed. We do want some more clarity on:
    • Could React we get away with just modifying React.JSXElementConstructor?
    • Why is the type parameter required?

Too Many Types!

  • Lots of avenues for performance improvements.
  • But we have a Turing-complete type system.
    • Horrendously expensive types - you usually discover this when statement completion is slow.
    • We get the blame for a lot of these, but you can write arbitrary amounts of work!
    • Yes we should speed up the type system
    • But as we speed things up, that affords people with the ability to write slow types.
      • Example of induced demand (e.g. building roads doesn't reduce traffic - it incentivizes drivers).
    • How do we bring awareness to where the complex types come from?
    • Today the only thing we do is say "instantiation was deep and possibly infinite."
      • Kind of a panic button for us.
  • Can we give something like an earlier error/warning of "huh, this seems risky"?
    • Maybe we need some sort of opt-in to say "I don't care".
  • There are TSServer events - we can possibly provide a pop-up to warn people when a library is causing a lot of type instantiations.
    • We can point out expensive statements, but we can't point to the type that is being instantiated a lot.
    • User code looks innocent, the library is the thing doing a lot of the work.
  • We already have the "panic button" error - is that good enough today, or is the location of the error too confusing?
  • How do we help library authors know that they're writing slow types?
    • Tests for libraries (e.g. on DefinitelyTyped) are often shallow unit-testy use-cases, not complete real-world examples.
  • Some of the "bananas" types that we see are people trying to achieve explainable things.
    • Good example - people want a function call to infer as if the user had always written as const so they write recursive conditional types.
    • But they don't want users to have to write as const.
  • What about overlaying the things that are "expensive" in the editor as an experimental feature? Like a heatmap?
    • What does it measure? Type instantiation? Not a perfect measure.
      • But it's something!
  • No conclusion, but some avenues to explore.
@Andarist
Copy link
Contributor

Good example - people want a function call to infer as if the user had always written as const so they write recursive conditional types.

Please tell me that the solution to this is coming 🙏 😜 5.0 is just around the corner, just saying... 😉

@mihailik
Copy link
Contributor

mihailik commented Dec 4, 2022

What's needed is a tool that will map type system delays onto text.

Load file(s) — get a map.

Plug it into the Playground, VSCode maybe. But key is to capture metrics.

Will help investigate issues too, of course.

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

4 participants