精读《setState 做了什么》
1 引言
但是 通过 how-does-setstate-know-what-to-do 这篇文章,可以解开这个秘密。 2 概述
但是 所以可以推断,平台相关的 UI 更新逻辑分布在平台相关的包里, React 引擎不在 react 包里从 react 0.14 版本之后,引擎代码就从 react 包中抽离了,react 包仅仅做通用接口抽象。 也就是说,react 包定义了标准的状态驱动模型的 API,而 各平台具体的渲染引擎实现被称为 reconciler,通过这个链接可以看到 这说明了 react 包仅告诉你 React 拥有哪些语法,而并不关心如何实现他们,所以我们需要结合 react 包与 react-xxx 一起使用。 对于 // A bit simplified function createContext(defaultValue) { let context = { _currentValue: defaultValue,Provider: null,Consumer: null }; context.Provider = { $$typeof: Symbol.for("react.provider"),_context: context }; context.Consumer = { $$typeof: Symbol.for("react.context"),_context: context }; return context; } 具体用到时,由 这也说明了,如果你不同步升级 setState 怎么调用平台实现每个平台对 UI 更新逻辑的实现,会封装在 // Inside React DOM const inst = new YourComponent(); inst.props = props; inst.updater = ReactDOMUpdater; // Inside React DOM Server const inst = new YourComponent(); inst.props = props; inst.updater = ReactDOMServerUpdater; // Inside React Native const inst = new YourComponent(); inst.props = props; inst.updater = ReactNativeUpdater; 不同于 // A bit simplified setState(partialState,callback) { // Use the `updater` field to talk back to the renderer! this.updater.enqueueSetState(this,partialState,callback); } 关系可以这么描述: HooksHooks 的原理与 // In React (simplified a bit) const React = { // Real property is hidden a bit deeper,see if you can find it! __currentDispatcher: null,useState(initialState) { return React.__currentDispatcher.useState(initialState); },useEffect(initialState) { return React.__currentDispatcher.useEffect(initialState); } // ... }; ReactDOM 提供了 // In React DOM const prevDispatcher = React.__currentDispatcher; React.__currentDispatcher = ReactDOMDispatcher; let result; try { result = YourComponent(props); } finally { // Restore it back React.__currentDispatcher = prevDispatcher; } 可以看到,Hooks 的原理与 和 由于需要同时实现 3 精读与其他 React 分析文章不同,本文并没有过于刨根问题的上来就剖析 reconciler 实现,而是问了一个最基本的疑问:为什么 通过这个疑问,我们了解了 React 更上层的抽象能力,如何用一个包制定规范,用 N 包去实现它。 接口的力量在日常编程中,接口也拥有的强大力量,下面举几个例子。 UI 组件跨三端的接口由于 RN、Weex、Flux 的某些不足,越来越多的人选择 “一个思想三端实现” 的方式做跨三端的 UI 组件,这样既兼顾了性能,又可以照顾到平台差异性,对不同平台组件细节做定制优化。 要实施这个方案,最大问题就是接口约定。一定要保证三套实现遵循同一套 API 接口,业务代码才可以实现 “针对任意一个平台编写,自动移植到其他平台”。 比较常用的做法是,通过一套统一的 API 文件约束,固定组件的输入输出,不同平台的组件做平台具体实现。这个思想和 React 如出一辙。 当然 RN 这些框架本身也是同一接口在不同平台实现的典型,只是做的不够彻底,JS 与 Native 的通信导致了性能不如源生。 通用数据查询服务通用数据查询服务也比较流行,通过磨平各数据库语法,让用户通过一套 SQL 查询各种类型数据库的数据。 这个方案中,一套通用的查询语法就类似 React 定义的 API,执行阶段会转化为各数据库平台的 SQL 方言。 小程序融合方案现在这种方案很火。通过基于 template 或者 jsx 的语法,一键发布到各平台小程序应用。 这种方案一定会抽象一套通用语法,甚至几乎等价与 4 总结这种分平台实现方案与跨平台方案还是有很大区别的,像 JAVA 虚拟机本质还是一套实现方案。而分平台的实现可以带来最原生的性能与体验,同样收到的约束也最大,应该其 API 应该是所有平台支持的一个子集。 另外,这种方案不仅可以用于 一套规范,不同平台的实现,甚至可以用在 “同一平台的实现”。 无论是公司还是开源节界,都有许多重复的轮子或者平台,如果通过技术委员会约定一套平台的实现规范,大家都遵循这个规范开发平台,那未来就比较好做收敛,或者说收敛的第一步都是先统一 API 规范。 留下一个思考题:还有没有利用 讨论地址是: 精读《setState 做了什么》 · Issue #122 · dt-fe/weekly 如果你想参与讨论,请点击这里,每周都有新的主题,周末或周一发布。前端精读 - 帮你筛选靠谱的内容。 来源:https://segmentfault.com/a/1190000017787272 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |