共计 1997 个字符，预计需要花费 5 分钟才能阅读完成。
生产 web API 来做出现，所以有了客户端软件，就像 iOS SDK 里的组件会通过 web API 获取信息, 而后展现在屏幕上。
react 与 angular 的区别，能够从它们对于 HOC (高阶组件) 的应用上看到。HOC 这种货色显然是诞生于特定的编程模型的。
故而 angular 既没有 HOC 又没有纯函数的概念，因为它没有采纳 js the good part 之外的方面，而仅仅是把 js 当作 java 在应用似的。
react 从 jsx 开始，让一个组件的渲染机去渲染一个组件的状态机，而后通过内部条件对于此组件状态机的扭转（精确地说，是对此组件的状态机的裁减），让此组件的渲染机能渲染进去的数据 越来越多。
这些数据来自 render props 和 HOC。render props 的用法是简略的，HOC 的用法是简略又敌对的，至多对于开发者来说是这样的。
如果说整个的 HOC 机制和 setState 机制都是 react SDK 里的一个提供（推广），那么为什么 angular SDK 没有 HOC 呢？既然 angular 也是 js。为什么 iOS SDK 里没有 HOC 呢？它们可都是客户端开发。这是我的一个纳闷。
angular SDK 里对于组件能渲染出那些数据是明确的，在组件通信方面 它并没有用到 状态晋升 也没有用到 而是间接用了 service 订阅模式。
在 react SDK 中，状态晋升的滥用是非常容易的，props drilling 也是因为组件之间共享数据是如此简略才会呈现的，以及之后的 context、useContext useReducer useMemo (显然它是为函数组件减少能力的)，以及在数据更新与告诉机制订阅机制方面的 redux recoil。
在 react SDK 中，函数组件更像一个 partial (能够渲染变量的一个文件片段, 这个概念是远古 PHP 和动态站点生成器的概念)，而且这个 partial 的 rerender 数应该是越低越好的。谁来管制 partial 的 rerender？这篇文章 1 里有提到。
我的了解是，一个 partial 的从新渲染肯定是因为它被判断是（就它负责渲染的数据而言）有了新数据值 所以它才要从新渲染的。一旦没有新值，那么它就不须要从新渲染。如果在没有新值的状况下从新渲染了，那么就等于呈现了 rerender 问题，这是能够优化的。
在 react SDK 中，这样的 partial 被叫做 dummy component (只负责渲染 props 里的货色) 也能够叫做 presentational component，而且还有了 stateful dummy component 和 stateless dummy component 的概念。而后就不可避免地再次（在承受了“简略又敌对”的状况下）走到组件通信机制，而在组件通信机制里 稍有不慎就会触发 rerender 问题。
比方表格，表格状态该如何向表格记录者来提交表格呢？如果搜寻子组件如何向父组件通信 react child state to parent communication 那么会失去这样的答案。这里有三个考量：1 尽量不触发 rerender 问题（即不该 rerender 的组件 不要从新渲染，不要放在一个组件的渲染机制里）2 尽量不引入第三方库 3 你能用的只有事件 而事件做了两件事件 第一在订阅机制下和你感兴趣的数据源进行交互 – 这是扭转数据源的而数据源的扭转会触发所有订阅了此数据源的组件的正当的“自我刷新”第二更新本人的 state — 这是本组件内的 presentational 的 stateful 的。最初我的发现是：1 state props pass down 是一个简直不能用的货色 2 父组件 子组件 本应该是两个平行组件 它们的渲染机制不应该缠绕在一起（即 不应该由父组件渲染出子组件，这会引起 rerender 问题）（应该是 在一个 dummy component container component 里垒组件，各组件拿到各自数据做各自的渲染：这会简直杜绝 rerender 问题，因为你的 rerender 只会来自 render 你的那个组件的状态变动 (当初好了, 它不蕴含状态) or 你订阅的数据的更新 能够来自 context 或 redux 或 recoil whatever）3 所谓的 单向数据流 React is all about data flowing down the component’s tree, never up. 只适宜那些永远不会变动的数据或（动态站点生成器里的）填充 slot 的数据，而不会是真正变动的数据（真正变动的数据 要么来自 props 要么来自订阅机制）4 解决 props drilling 的最好方法就是不嵌套组件 尽可能多写平行组件，因为平行组件嘛 没有 props 的传递了，天然就不会有 props drilling。
最初 一张图片 1 揭示本人关注 rerender 问题和其它性能问题。
最初 接下来要看的是 angular 如何解决表格 1，在没有高阶组件也没有组件嵌套的状况下，没有 HOC 又没有纯函数，什么都没有。
0
