至于第一版，把 event 直接甩给父组件，爽是爽，就是类型满天飞
最开始我是这么想的：父组件管状态。子组件就是个输入框，使用者输入啥，我就把 event 传给父组件，父组件自己去拿 event.target.value。
听起来没毛病对吧？我当时也觉得挺合理的，
代码大概长这样：
// 父组件
import * as React from 'react';import Hello from './components/Hello';import NameEditComponent from './components/NameEditComponent';const APP: React.FC = => {
const = React.useState;const setUserNameState = => {
setUserName;}
return (
)
}
子组件更简单，就是个纯展示的 input：
// 子组件
import * as React from 'react';interface Props {
userName: string;onChange: => void;}
const NameEditComponent: React.FC = => {
return (
)
}
跑起来没问题，功能也实现了。但我越看越别扭 ——
input 还是 textarea，父件都得知道。其实，
这就好比你去餐厅吃饭。服务员把后厨的菜刀直接递给你，说 “来你自己切”。菜能吃上，但总觉得哪里不对。话说回来，
而且你发现没。React.ChangeEvent 这个类型，两边都得写一遍。怎么说呢，以后子件换成 textarea，两边都改。这耦合度，让人头疼，
等等，先插一句：React.FC 到底是个啥？
说到类型。我得先聊聊 .React.FC. 最开始我照教程抄，加了它，却不知道为什么要加。
"它就是一个泛型类型别名"
// type FC
= FunctionComponent
"FunctionComponent 本质上就是一个函数",接收 props 返回 ReactElement。说白了它就是给“函数式组件”上加约束。
不过，泛型像函数参数，只但是传的是类型，而不是值。比如 `<.React.FC< Props>` 就表示这是一个函数式组件，其 props 类型为 `Props`。
"Props 怎么样定义": 用 interface 或 type 描述对象形状，如下：
// interface 描述对象形状
interface Props {
userName: string;}
-
类型，一目了然。"
-
"TS 报红能帮你捕获拼写错误、缺失字段等低级错误。"
-
"在多人协作中，用 interface 可以快速了解每个 component 接收什么。"
说到第二版。子件自己管自己的状态
I 当时觉得将 event 一口气丢给父件太别扭，于是换思路——让输入框那点事儿由子件自行搞定。
// 子件 - 自己管理编辑状态
import * as React from 'react';interface Props {
initialName: string;onNameUpdate: => void;}
const NameEditComponent : React.FC<Props>= =>{
const =React.useState;const onChange==>{setEditing;}，const submit==>{props.onNameUpdate;}，return(
<>
...
)};
再看第三版，状态提高到父件
以下代码示例已经做简化和注释。以便阅读
ts
// 父件 - 管理所有状态
如前所示，此版本进一步演示如何将共享状态提高至共同祖先，并通过受控与非受控模式分离职责。其实，
单向数据流概念梳理—从数据往下传到事件往上传—为何如此关键?按理说，
-
'数据从上往下流' → 父部份负责 state 再以 props 的形式交付至子部份.
-
'事件从下往上传' → 子部份通过 callback 通知上层改变 state.
-
'受控' 与 '非受控' 则基于是否共享此类 state 决定.
useEffect 四种打开方式——从初学者困惑到熟练掌握!
