状态和相关处理逻辑可以按照功能进行划分,不必散落在各个生命周期中,降低开发和维护的难度,除了这几个hooks还有其他额外的hooks,在此继续了解 Hooks API Reference
提出相关问题
出现Hooks之后应该如何选择函数组价和类组件
Our goal is for Hooks to cover all use cases for classes as soon as possible. There are no Hook equivalents to the uncommon getSnapshotBeforeUpdate and componentDidCatch lifecycles yet, but we plan to add them soon.
It is a very early time for Hooks, so some integrations like DevTools support or Flow/TypeScript typings may not be ready yet. Some third-party libraries might also not be compatible with Hooks at the moment.
Often, render props and higher-order components render only a single child. We think Hooks are a simpler way to serve this use case. There is still a place for both patterns (for example, a virtual scroller component might have a renderItem prop, or a visual container component might have its own DOM structure). But in most cases, Hooks will be sufficient and can help reduce nesting in your tree
Hook新的特性
为什么需要引入Hooks特性
核心API
注意事项
为什么要多使用Hooks特性
Hooks解决问题
针对目前存在的这种问题,有两种解决方法一种是Render Props、另一种是Higher-Order Components,但是这两种方法都存在明显的缺陷,一是造成组件数量增多,组件树结构的改变,而且还可能出现组件嵌套地狱的情况,现在React中通过
custom Hooks
来解决这个问题。这里面约定命名要使用use*开头,方便我们进行区分,有利于我们进行维护,并且可以将封装好的Hooks提交到社区中进行共享
状态和相关处理逻辑可以按照功能进行划分,不必散落在各个生命周期中,降低开发和维护的难度,除了这几个hooks还有其他额外的hooks,在此继续了解 Hooks API Reference
提出相关问题
React Fiber
原来组件更新是同步的,但是这种同步更新会带来页面卡顿,这种体验很不好,为了解决这个问题,react团队历时两年,将核心是更新算法重写,通过将javascript中同步的任务分成很多小片,把一个耗时长的任务分成很多小片,每一个小片的运行时间很短,虽然总时间依然很长,但是在每个小片执行完之后,都给其他任务一个执行的机会,这样唯一的线程就不会被独占,其他任务依然有运行的机会。React Fiber把更新过程碎片化,每执行完一段更新过程,就把控制权交给React负责任务协调的模块,看有没有优先级高的任务,如果没有就继续更新,如果有紧急任务,则首先处理紧急任务。
相关资料