Add Support for Flow's new component syntax #58246

Activity

1. MartinJohns commented on Apr 19, 2024

   

   Martin Johns (MartinJohns)

   on Apr 19, 2024

   Contributor

   More actions

   but the new component syntax has the potential to unify how things are done

   Unless this syntax is supported by JSX I can't see this happening at all.

   And until today I always thought flow is a type checker. TIL.
2. snarbies commented on Apr 19, 2024

   

   snarbies

   on Apr 19, 2024

   More actions

   I don't see the appeal either, but couldn't one react the same way to JSX itself? It's also a special syntax for react that has to be transpiled.
3. nmain commented on Apr 19, 2024

   

   Nicholai Main (nmain)

   on Apr 19, 2024

   More actions

   Over time, JSX has proven to quite useful for a variety of scenarios. The React transform requires nothing more than a createElement-like function, and for other use cases there are many other popular transforms. It's been used in React, React-like, other not-at-all-like React VDOM-based systems, and systems that emit HTML strings, raw DOM elements, and others. Everyone wanted a reasonable template-ish syntax for making HTML-likes in Javascript, and JSX filled that need well.

   By contrast, these changes are much more React-specific. component enforces a very specific signature. hook goes down the rabbit-hole of "the rules of hooks" as defined by React.

   👍React with 👍2Reacted by snarbies and Robbie Speed
4. Ryan Cavanaugh (RyanCavanaugh)

   added

   SuggestionAn idea for TypeScriptAn idea for TypeScript

   In DiscussionNot yet reached consensusNot yet reached consensus

   on Apr 19, 2024
5. RyanCavanaugh commented on Apr 19, 2024

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Apr 19, 2024

   Member

   More actions

   Remember when everyone said Flow was better because it wasn't adding transpiles-to-runtime stuff like enum and namespace to JS? TypeScript remembers 👴

   👎React with 👎1Reacted by Slim

   😄React with 😄12Reacted by ritschwumm, Nicholai Main, snarbies, Bruce Pascoe, Rob Palmer, uhyo, berlysia, Andrii Dieiev, Tristan Hessell , Degubi and 2 more
6. Josh-Cena commented on Apr 19, 2024

   

   Joshua Chen (Josh-Cena)

   on Apr 19, 2024

   Last edited by Josh-Cena

   Contributor

   More actions

   The component syntax's advantage does not lie in its sugar; it's more about giving code semantics and allowing stricter type checks like return type being ReactNode, parameters being readonly, etc. This benefit can trickle down to other linters like eslint-plugin-react where they can enforce proper hook calls, etc. (totally understand if TypeScript doesn't want to take on this kind of checking)
7. RyanCavanaugh commented on Apr 19, 2024

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Apr 19, 2024

   Member

   More actions

   In all seriousness though, it doesn't seem that problematic to parse component as an alias for function in TSX files only under jsx: preserve (which would leave component in the emitted JSX file) or noEmit, and otherwise skip all the Meta-specific rules that Flow infers on it.

   As far as I understand, their component-to-function compiler doesn't need any type annotations to do the right thing.

   👍React with 👍2Reacted by Joseph Savona and David Sundqvist
8. robbiespeed commented on Apr 26, 2024

   

   Robbie Speed (robbiespeed)

   on Apr 26, 2024

   More actions

   As others have said, React isn't the only user of JSX. Speaking as someone who's built a JSX framework, I could care less about more syntax sugar, JSX encompasses enough. Where it falls short is the limitations of typing, currently we can't do things like specifying "renders" types because JSX only allows one static return type JSX.Element. However something like #14729 that allowed JSX to get return types from generic function (createElement, jsx, h) would be immensely valuable. If you have this, you can implement "renders" and restricting children types. Two examples of such: recursive checks or tagging components with a "renders" symbol and associated type.

   It's unclear what the benefit of component is, flow could have similarly implemented "renders" types without it.
9. Darhagonable commented on May 16, 2024

   

   David Sundqvist (Darhagonable)

   on May 16, 2024

   More actions

   The biggest advantage IMO is the nicer handling of props.
   currently:

   function MyComponent({ text = "Hello!", onClick }: { text: string, onClick: () => void }) {
     return <div onClick={onClick}>{text}</div>;
   }

   what the component syntax would allow:

   component MyComponent(text: string = "Hello!", onClick: () => void) {
     return <div onClick={onClick}>{text}</div>;
   }

   I would like to able to add a plugin to my tsconfig to have this functionality.

   👍React with 👍6Reacted by Saul, David Schwartz, David Sundqvist, n1xx1, Justin Grant and Lucas Teixeira
10. ikeyan commented on Jan 27, 2025

    

    ikeyan

    on Jan 27, 2025

    Last edited by ikeyan

    More actions

    David Sundqvist (@Darhagonable) I think that part (making destructuring, default value and type annotation closer) can be generalized into any function.

    TypeScript now:

    function MyComponent({ text = "Hello!", onClick }: { text: string, onClick: () => void }) {
      return <div onClick={onClick}>{text}</div>;
    }
    
    const arrow = ({
      array: [a1, a2],
      tuple: [t1, t2],
      object: { foo: fooAlias },
    }: {
      array: number[];
      tuple: [t1: number, t2: string];
      object: { foo: FooType };
    }) => 42;

    future TypeScript:

    function MyComponent({
      text: string = "Hello!",
      onClick: () => void,
    }) {
      return <div onClick={onClick}>{text}</div>;
    }
    
    const arrow = ({
      array: [a1, a2]: number[],
      tuple: [t1: number, t2: string],
      object: { foo: fooAlias: FooType },
    }) => 42;
    // probably should not allow this:
    // array: [t1: number, t2: string]: (number | string)[],

    👍React with 👍1Reacted by n1xx1