但是新的组件语法有可能统一事物的处理方式。
除非这种语法被JSX支持，否则我无法看到这种情况发生。
直到今天，我一直认为Flow是一种类型检查器。

我也不觉得它有什么吸引力，但难道不能对JSX本身有同样的React吗？它也是React的一种特殊语法，需要被转译。

随着时间的推移，JSX已被证明在各种场景中非常有用。React转换仅需要一个类似createElement的函数，对于其他用例，还有许多其他流行的转换。它已在React、类似React的其他完全不像React VDOM基于系统以及发出HTML字符串、原始DOM元素和其他系统的系统中使用。每个人都希望为在Javascript中制作类似HTML的合理模板语法，而JSX很好地满足了这一需求。
相比之下，这些更改更具React特定性。component强制执行非常特定的签名。hook遵循React定义的“钩子规则”的兔子洞。

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

组件语法的优势并不在于其糖衣；它更多的是给代码赋予语义，并允许更严格的类型检查，如返回类型为 ReactNode ,参数为只读等。这种优势可以传递到其他linters(如eslint-plugin-react)中，以便它们可以强制执行正确的钩子调用等(完全理解如果TypeScript不想承担这种检查)。

严肃地说，在jsx: preserve或noEmit下，将component解析为TSX文件中function的别名似乎并不成问题(这将使component保留在输出的JSX文件中),否则跳过Flow推断的所有特定于元数据的规则。

就我所理解的，他们的component-to-function编译器不需要任何类型注解来正确执行操作。

正如其他人所说，React并不是唯一使用JSX的框架。作为一个构建过JSX框架的人，我对更多的语法糖并不关心，JSX已经包含了足够多的东西。它不足之处在于类型限制，目前我们不能做类似指定"渲染"类型的事情，因为JSX只允许一个静态返回类型JSX.Element。然而，像#14729这样的东西可以让JSX从泛型函数(createElement, jsx, h)中获取返回类型，这将是非常有价值的。如果你有这个功能，你可以实现"渲染",并限制子类型的类型。两个这样的例子：递归检查或用"渲染"符号和关联类型标记组件。

不清楚component的好处是什么，flow本可以同样实现"渲染"类型而不需要它。

我认为最大的优势是更好地处理props。
当前：

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

组件语法将允许的功能：

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

我希望能够通过在tsconfig中添加插件来实现这个功能。