Add Support for Flow's new component syntax

[bruno-gregorio]

🔍 Search Terms

"syntax", "flow", "component", "tsx"

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

First of all, I'd like to apologize; this request doesn't satisfy the last three viability checks. But I couldn't submit this if I didn't mark them. That said, if someone from the typescript team could at least read this proposal, I would be extremely grateful.

Recently, flow has added a new syntax to write components and hooks. For react devs, that's huge, and as someone who uses (and loves) typescript, I'd love to have something like this on TSX files too.

I understand that there are a few limitations on what can be done in typescript; for example, I don't expect typescript to check the rules of hooks and other react-specific things. I know that things like Solid and Stencil also use JSX.

To be completely blunt: I WANT SUGAR. Most influencers covering this new feature mentioned that it's extremely unlikely that Typescript will implement it. But I decided to try anyway, even if just to understand the reason.

In a more practical sense, here's what I would expect to see in a realist scenario:

• The changes would only affect TSX files.
• component blocks would be transpiled into function components.
• hook blocks would be transpiled into functions.
• Render types are nice. If I'm correct there's some arcane way of doing the same in typescript, but getting something more explicit wouldn't hurt.

📃 Motivating Example

Here's the post that explains what I'm talking about: https://medium.com/flow-type/announcing-component-syntax-b6c5285660d0

💻 Use Cases

1. What do you want to use this for? Pure and refined Syntax Sugar.
2. What shortcomings exist with current approaches? For components, there are 5-6 ways to deal with props currently, but the new component syntax has the potential to unify how things are done, reducing friction for new developers in large code bases. I recommend checking this video: https://youtu.be/HOFIefkepMA?si=i45CFr72m2GCaH5l
3. What workarounds are you using in the meantime? It's not impossible to write another tool that will take this syntax and output typescript, but that would be yet another tool in an already bloated web dev ecosystem.

[MartinJohns]

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.

[snarbies]

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.

[nmain]

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.

[RyanCavanaugh]

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

[Josh-Cena]

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)

[RyanCavanaugh]

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.

[robbiespeed]

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.

[Darhagonable]

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.

[ikeyan]

@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)[],