大家好,我卡颂。
我们知道,react发布Hooks后,带来了业界一波Hooks热。很多框架(比如vue Composition api、Solid.js)都借鉴了Hooks的模式。
但是,即使这些框架都借鉴了Hooks,但由于框架作者的理念不同,发展方向也逐渐不同。
比如,在Vue Composition API中,对标React useEffect API的是watchEffect,在Vue文档中,有一小段内容介绍他的用法:
而在React beta文档中,介绍useEffect的,则有整整6节内容:
为什么会有这样的区别?让我们从useEffect看看React、Vue设计理念的不同。
当Hooks刚问世时,他被看作是类组件的替代方案。文档中介绍Hooks时也是将他与类组件对比。
其中useEffect的执行时机囊括了如下3个生命周期函数:
反观借鉴了Hooks的Vue Composition API,则同时提供了watchEffect API与不同场景的生命周期函数。
这里已经体现出两者设计理念的不同了:
React作为Facebook为探索「UI开发」最佳实践而生的框架,一贯的做法是 —— 保持API稳定(比如this.setState从React诞生伊始就一直存在)。
而Vue则借鉴了各种框架中的最佳实践(比如虚拟dom、响应式更新...)。
所以,从易用性上来说,Vue Composition API是一定优于React Hooks的,比如:
并且,这种易用性的差异会随着框架迭代,愈发明显。
本着「保持API稳定」的原则,当前useEffect主要与上述三个生命周期函数相关。
但是,未来会有更多触发时机与useEffect挂钩。
所以,React团队在努力做一件事 —— 淡化useEffect与生命周期的关系,甚至淡化useEffect与组件的关系(因为当谈到组件时,很自然的会想到组件生命周期)。
怎么淡化呢?答案是 —— 在严格模式下,DEV环境会触发多次useEffect回调。
如果你将useEffect当作componentDidMount/WillUnmount来用,这个特性很可能让你的代码出bug。
React团队之所以这么做,就是想教育开发者 —— useEffect和生命周期没有关系。开发者应该将useEffect看作「针对某个数据源的同步过程」。
比如,下述聊天室组件,其中的useEffect可以看作是「针对聊天室连接的同步过程」:
const serverUrl = 'https://localhost:1234';
function ChatRoom({ roomId }) {
useEffect(() => {
const connection = createConnection(serverUrl, roomId);
connection.connect();
return () => {
connection.disconnect();
};
}, [roomId]);
// ...
}
当聊天室组件mount、update、unmount时,对应的同步过程应该进行。
当roomId变化时,对应的同步过程应该进行。
同理,如果React原生支持了Vue中的KeepAlive,那么当聊天室组件从「可见」变为「不可见」,以及从「不可见」变为「可见」状态,同步过程都应该进行。
所以,当我们从「同步过程应该何时进行」的角度看待useEffect时,上述useEffect触发时机都是合理的。
但是,如果从生命周期函数的角度看待useEffect,等未来(可能是v18的某个版本),Offscreen Component特性落地(对标Vue中的KeepAlive),组件从「可见」变为「不可见」状态时,useEffect销毁函数与useEffect回调函数会依次执行,就会让人很头大。
这就是为什么,我上文说,React团队一直在淡化useEffect与生命周期的关系,甚至淡化useEffect与组件的关系。
一切都是为了「未来其他特性与useEffect的挂钩」打下理论基础。而这些特性从「组件」或「生命周期函数」的角度讲不通。
这也是为什么在新文档里有6节内容与useEffect相关的原因。
作为对比,Vue在遇到新的场景时会怎么做呢?显然是设计新的API。
到底是提供一个API,但是能覆盖更多场景(文档有6节来介绍他)好,还是每个场景都提供一个API好?
不同开发者有自己的答案。
但有一点很明确,对于前端新手,React的上手难度会越来越高,而Vue的上手难度会尽可能保持平滑。
这里的前端新手,可能是想入行前端的新人,也可能是觉得「前端我也能干」的后端。
所以,对于当前的从业者来说,这究竟是好事还是坏事呢?
来源: 魔术师卡颂
如今的 Web 前端已被 React、Vue 和 Angular 三分天下,尽管现在的 jQuery 已不再那么流行,但 jQuery 的设计思想还是非常值得致敬和学习的,特别是 jQuery 的插件化。
受控组件与非受控组件在官网与国内网上的资料都不多,有些人觉得它可有可不有,也不在意。这恰恰显示React的威力,满足不同规模大小的工程需求。
一般在传统模式下,我们构建前端项目很简单。就是下载各种js文件,如JQuery、Echart等,直接放置在html静态文件。Webpack则是JavaScript中比较知名的打包工具。这两个构建工具构成了React应用快速搭建的基础。
Gatsby能快速的使用 React 生态系统来生成静态网站,可以结合React Component、Markdown 和服务端渲染来完成静态网站生成让他更强大。
React推出后,出于不同的原因先后出现三种定义react组件的方式,殊途同归;具体的三种方式:函数式定义的无状态组件、es5原生方式React.createClass定义的组件、es6形式的extends React.Component定义的组件
React主要思想是通过构建可复用组件来构建用户界面,每个组件都有自己的生命周期,它规定了组件的状态和方法需要在哪个阶段改变和执行。所谓组件就是有限状态机,,表示有限个状态以及在这些状态之间的转移和动作行为的模型。
React 相关的优化:使用 babel-react-optimize 对 React 代码进行优化,检查没有使用的库,去除 import 引用,按需打包所用的类库,比如 lodash 、echarts 等.Webpack 构建打包存在的问题两个方面:构建速度慢,打包后的文件体积过大
这篇文章主要介绍React Router定义路由之后如何传值,有关React和React Router 。react router中页面传值的三种方法:props.params、query、state
react 高阶组件简单的理解是:一个包装了另一个基础组件的组件。高阶组件的两种形式:属性代理(Props Proxy)、反向继承 (Inheritance Inversion)
React 支持一种非常特殊的属性 Ref ,你可以用来绑定到 render() 输出的任何组件上。这个特殊的属性允许你引用 render() 返回的相应的支撑实例( backing instance )。这样就可以确保在任何时间总是拿到正确的实例
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!