Open xxleyi opened 3 years ago
React 坚持单向数据流，但现实如你我所见，总是有些不那么像是单向数据流的例子存在，而这些例子如果使用 vue 的双向绑定，应用开发者可以很方便的完成此类任务。
但问题是，React 为什么如此坚持？而且既然 React 如此坚持，必然也是因为单向数据流有能力搞定一切，包括父组件状态依赖子组件状态。
问题的表象就是如此，但如果再仔细深入了解，发现这种父依赖于子的情况在编程世界无处不在，而面对这种情况，我们通常可以使用异步编程来解决。
但异步编程的通用语法 async await 也并非十全十美，而且最关键的问题是：它并非事情的本质。
async await
异步的本质是 continuation。
在 React 中，解决父组件状态依赖子组件状态的方法有两个：
了解函数式编程的话，对 lift state up 的说法应该很熟悉：这是一种将非纯函数转变为纯函数的最基础技术。但同时也应该知道，很多时候这么多是很痛苦的一件事，需要将 state 连续插入在不相干的中间层中。
而 context API 更像是对于 lift state up 的一种编程封装，从而规避掉无意义的中间层 state 插入。
context API
lift state up
在 React 的这两种解决方案中慢慢体悟，能够发现父组件状态依赖子组件状态是个伪命题，并不是事情的本质。子组件本来就是父组件的一部分，事情的本质是，将父子组件视为一个整体，这个整体出现了一种特殊状态：状态的使用超前于状态的生成。
如何解决状态的使用超前于状态的生成这一问题呢？这一问题的本质依然是 continuation，所以想要从根本上解决这类问题，真正需要的是语言或者框架级别对执行过程的具体调度。双向绑定能解决问题，但不是最优解决方案，而且是在事实上切断了通向最优解决方案的道路。
React 的两种解决方案虽然都略显笨拙，但并未偏离问题本质，依旧可以，而且是可以非常顺当的通往更优的（或者最终的）解决方案。
也许，这就是高级架构师延迟做决定的奥秘所在：中低级架构师早早定下貌似完美的架构，但殊不知也早已将自己框于当前架构之下。高级架构师的每一步貌似都在妥协，看上去是一种未完成品，但却能在最终给出一个逼近终极且几乎完美的架构形态。
React 坚持单向数据流，但现实如你我所见，总是有些不那么像是单向数据流的例子存在，而这些例子如果使用 vue 的双向绑定，应用开发者可以很方便的完成此类任务。
但问题是，React 为什么如此坚持？而且既然 React 如此坚持，必然也是因为单向数据流有能力搞定一切，包括父组件状态依赖子组件状态。
问题的表象就是如此，但如果再仔细深入了解，发现这种父依赖于子的情况在编程世界无处不在，而面对这种情况，我们通常可以使用异步编程来解决。
但异步编程的通用语法
async await也并非十全十美，而且最关键的问题是：它并非事情的本质。异步的本质是 continuation。
在 React 中，解决父组件状态依赖子组件状态的方法有两个：
了解函数式编程的话，对 lift state up 的说法应该很熟悉：这是一种将非纯函数转变为纯函数的最基础技术。但同时也应该知道，很多时候这么多是很痛苦的一件事，需要将 state 连续插入在不相干的中间层中。
而
context API更像是对于lift state up的一种编程封装，从而规避掉无意义的中间层 state 插入。在 React 的这两种解决方案中慢慢体悟，能够发现父组件状态依赖子组件状态是个伪命题，并不是事情的本质。子组件本来就是父组件的一部分，事情的本质是，将父子组件视为一个整体，这个整体出现了一种特殊状态：状态的使用超前于状态的生成。
如何解决状态的使用超前于状态的生成这一问题呢？这一问题的本质依然是 continuation，所以想要从根本上解决这类问题，真正需要的是语言或者框架级别对执行过程的具体调度。双向绑定能解决问题，但不是最优解决方案，而且是在事实上切断了通向最优解决方案的道路。
React 的两种解决方案虽然都略显笨拙，但并未偏离问题本质，依旧可以，而且是可以非常顺当的通往更优的（或者最终的）解决方案。
也许，这就是高级架构师延迟做决定的奥秘所在：中低级架构师早早定下貌似完美的架构，但殊不知也早已将自己框于当前架构之下。高级架构师的每一步貌似都在妥协，看上去是一种未完成品，但却能在最终给出一个逼近终极且几乎完美的架构形态。