React v16.8 发布:带来稳定版的 Hooks 功能

局长
 局长
发布于 2019年02月12日
收藏 2

React v16.8 版本已于2月6日发布,最值得关注的更新莫过于带来了稳定版的 Hooks 功能。

hooks 可以让你在不编写类的情况下使用 state 和 React 的其他功能。你还可以构建自己的 hooks,在组件之间共享可重用的有状态逻辑。

从 16.8.0 开始,React 包含稳定的 React Hooks 实现:

  • React DOM

  • React DOM Server

  • React Test Renderer

  • React Shallow Renderer

要注意的是,如需使用 hooks,所有 React 包都需要升级到 16.8.0 或更高版本。如果忘记更新某个包(例如 React DOM),hooks 将无法工作。此外,React Native 将在 0.59 版本中支持 hooks

不过官方表示,开发者不一定现在就要学习 hooks,因为它没有带来重大变化,开发团队暂时也没计划从 React 中删除类。hooks 的 FAQ 提到了 hooks 的逐步采用策略。

官方的建议是,不要为了马上采用 hooks 而对现有应用程序进行重写。相反,可以在一些新组件中尝试使用 hooks,并进行意见反馈。现阶段的情况是,使用 hooks 的代码仍可以与使用类的现有代码并存。

使用示例和详细更新内容请查看:https://reactjs.org/blog/2019/02/06/react-v16.8.0.html

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:React v16.8 发布:带来稳定版的 Hooks 功能
加载中

精彩评论

下里巴人_770728
下里巴人_770728
仔细学习过hooks, 感觉这玩意儿对react的影响非常深远. 以前react老提"纯函数", 但引入hooks后, 其实更倾向于"响应式"(因为不纯了).
引入hooks后, 最大的变化就是绝大多数情况下, 不用再写class, 直接写function.
以前感觉很多状态绕在一起, 没办法提取, 只好采用(子组件 + 一堆属性)解决. 现在直接将状态提出为hooks, 组件职责更清晰.
提出的hooks, 自然可以被其它组件复用(虽说hoc也可以做到, 但结合typescript非常麻烦, 用过的相信都有体会).
现在社区已经有一堆hooks了, 非常好用, 推荐看下 awesome-hooks 项目.
下里巴人_770728
下里巴人_770728

引用来自“keep_wan”的评论

赞是不是可以抛弃redux. 这玩意的确一堆的概念

引用来自“左华栋”的评论

react 使用 apollo-garaphql 的话有 store 可以做状态管理,不需要用到 redux , mobx 这些了。
hooks 这些所解决的问题,其实 angular 全家桶早就解决了。前端这套工程化思想还得发展好几年才能基本稳定。
感觉apollo-graphql的缓存管理非常不方便, api也不直观. 相比而言, 更喜欢mobx.
angular全家桶解决hooks解决的问题? 我感觉不太一样: hooks不仅仅是useState, 还有useEffect...
打个比方, 响应窗口尺寸变化的 [useWindowSize] 这样的hooks, 恐怕angular就很难有简单的对应版本 ( 注意: 需要在安装组件时加事件, 在卸载组件时清除事件).
不知这个理解对否.
左华栋
左华栋

引用来自“keep_wan”的评论

赞是不是可以抛弃redux. 这玩意的确一堆的概念
react 使用 apollo-garaphql 的话有 store 可以做状态管理,不需要用到 redux , mobx 这些了。
hooks 这些所解决的问题,其实 angular 全家桶早就解决了。前端这套工程化思想还得发展好几年才能基本稳定。

最新评论(10

下里巴人_770728
下里巴人_770728

引用来自“keep_wan”的评论

赞是不是可以抛弃redux. 这玩意的确一堆的概念

引用来自“左华栋”的评论

react 使用 apollo-garaphql 的话有 store 可以做状态管理,不需要用到 redux , mobx 这些了。
hooks 这些所解决的问题,其实 angular 全家桶早就解决了。前端这套工程化思想还得发展好几年才能基本稳定。

引用来自“下里巴人_770728”的评论

感觉apollo-graphql的缓存管理非常不方便, api也不直观. 相比而言, 更喜欢mobx.
angular全家桶解决hooks解决的问题? 我感觉不太一样: hooks不仅仅是useState, 还有useEffect...
打个比方, 响应窗口尺寸变化的 [useWindowSize] 这样的hooks, 恐怕angular就很难有简单的对应版本 ( 注意: 需要在安装组件时加事件, 在卸载组件时清除事件).
不知这个理解对否.

引用来自“左华栋”的评论

apollo 只是用的不深,确实会有这样的感觉。 如果配合 angular 的 service 会觉得非常方便。
api 层级深是事实,用下 apollo 的client 就会觉得爽了。

引用来自“下里巴人_770728”的评论

我对apollo-client印象不太好, 可能也是因为在react中使用, 高阶组件 包 高阶组件, 层层缩进, 强耦合, 不易抽离.
现在回想, 象你指出的, 如果象在 angular的service中 直接使用 client.query/mutate, 方法, 反而会直接得多(虽然会多写一些代码).

引用来自“左华栋”的评论

https://github.com/notadd/ng-notadd 我们现在有个项目可以用作参考
已star 👍
左华栋
左华栋

引用来自“keep_wan”的评论

赞是不是可以抛弃redux. 这玩意的确一堆的概念

引用来自“左华栋”的评论

react 使用 apollo-garaphql 的话有 store 可以做状态管理,不需要用到 redux , mobx 这些了。
hooks 这些所解决的问题,其实 angular 全家桶早就解决了。前端这套工程化思想还得发展好几年才能基本稳定。

引用来自“下里巴人_770728”的评论

感觉apollo-graphql的缓存管理非常不方便, api也不直观. 相比而言, 更喜欢mobx.
angular全家桶解决hooks解决的问题? 我感觉不太一样: hooks不仅仅是useState, 还有useEffect...
打个比方, 响应窗口尺寸变化的 [useWindowSize] 这样的hooks, 恐怕angular就很难有简单的对应版本 ( 注意: 需要在安装组件时加事件, 在卸载组件时清除事件).
不知这个理解对否.

引用来自“左华栋”的评论

apollo 只是用的不深,确实会有这样的感觉。 如果配合 angular 的 service 会觉得非常方便。
api 层级深是事实,用下 apollo 的client 就会觉得爽了。

引用来自“下里巴人_770728”的评论

我对apollo-client印象不太好, 可能也是因为在react中使用, 高阶组件 包 高阶组件, 层层缩进, 强耦合, 不易抽离.
现在回想, 象你指出的, 如果象在 angular的service中 直接使用 client.query/mutate, 方法, 反而会直接得多(虽然会多写一些代码).
https://github.com/notadd/ng-notadd 我们现在有个项目可以用作参考
下里巴人_770728
下里巴人_770728

引用来自“keep_wan”的评论

赞是不是可以抛弃redux. 这玩意的确一堆的概念

引用来自“左华栋”的评论

react 使用 apollo-garaphql 的话有 store 可以做状态管理,不需要用到 redux , mobx 这些了。
hooks 这些所解决的问题,其实 angular 全家桶早就解决了。前端这套工程化思想还得发展好几年才能基本稳定。

引用来自“下里巴人_770728”的评论

感觉apollo-graphql的缓存管理非常不方便, api也不直观. 相比而言, 更喜欢mobx.
angular全家桶解决hooks解决的问题? 我感觉不太一样: hooks不仅仅是useState, 还有useEffect...
打个比方, 响应窗口尺寸变化的 [useWindowSize] 这样的hooks, 恐怕angular就很难有简单的对应版本 ( 注意: 需要在安装组件时加事件, 在卸载组件时清除事件).
不知这个理解对否.

引用来自“左华栋”的评论

apollo 只是用的不深,确实会有这样的感觉。 如果配合 angular 的 service 会觉得非常方便。
api 层级深是事实,用下 apollo 的client 就会觉得爽了。
我对apollo-client印象不太好, 可能也是因为在react中使用, 高阶组件 包 高阶组件, 层层缩进, 强耦合, 不易抽离.
现在回想, 象你指出的, 如果象在 angular的service中 直接使用 client.query/mutate, 方法, 反而会直接得多(虽然会多写一些代码).
左华栋
左华栋

引用来自“keep_wan”的评论

赞是不是可以抛弃redux. 这玩意的确一堆的概念

引用来自“左华栋”的评论

react 使用 apollo-garaphql 的话有 store 可以做状态管理,不需要用到 redux , mobx 这些了。
hooks 这些所解决的问题,其实 angular 全家桶早就解决了。前端这套工程化思想还得发展好几年才能基本稳定。

引用来自“下里巴人_770728”的评论

感觉apollo-graphql的缓存管理非常不方便, api也不直观. 相比而言, 更喜欢mobx.
angular全家桶解决hooks解决的问题? 我感觉不太一样: hooks不仅仅是useState, 还有useEffect...
打个比方, 响应窗口尺寸变化的 [useWindowSize] 这样的hooks, 恐怕angular就很难有简单的对应版本 ( 注意: 需要在安装组件时加事件, 在卸载组件时清除事件).
不知这个理解对否.
apollo 只是用的不深,确实会有这样的感觉。 如果配合 angular 的 service 会觉得非常方便。
api 层级深是事实,用下 apollo 的client 就会觉得爽了。
下里巴人_770728
下里巴人_770728
仔细学习过hooks, 感觉这玩意儿对react的影响非常深远. 以前react老提"纯函数", 但引入hooks后, 其实更倾向于"响应式"(因为不纯了).
引入hooks后, 最大的变化就是绝大多数情况下, 不用再写class, 直接写function.
以前感觉很多状态绕在一起, 没办法提取, 只好采用(子组件 + 一堆属性)解决. 现在直接将状态提出为hooks, 组件职责更清晰.
提出的hooks, 自然可以被其它组件复用(虽说hoc也可以做到, 但结合typescript非常麻烦, 用过的相信都有体会).
现在社区已经有一堆hooks了, 非常好用, 推荐看下 awesome-hooks 项目.
下里巴人_770728
下里巴人_770728

引用来自“keep_wan”的评论

赞是不是可以抛弃redux. 这玩意的确一堆的概念

引用来自“左华栋”的评论

react 使用 apollo-garaphql 的话有 store 可以做状态管理,不需要用到 redux , mobx 这些了。
hooks 这些所解决的问题,其实 angular 全家桶早就解决了。前端这套工程化思想还得发展好几年才能基本稳定。
感觉apollo-graphql的缓存管理非常不方便, api也不直观. 相比而言, 更喜欢mobx.
angular全家桶解决hooks解决的问题? 我感觉不太一样: hooks不仅仅是useState, 还有useEffect...
打个比方, 响应窗口尺寸变化的 [useWindowSize] 这样的hooks, 恐怕angular就很难有简单的对应版本 ( 注意: 需要在安装组件时加事件, 在卸载组件时清除事件).
不知这个理解对否.
下里巴人_770728
下里巴人_770728

引用来自“keep_wan”的评论

赞是不是可以抛弃redux. 这玩意的确一堆的概念
可以换用easy-peasy, 兼具mobx+rematch 的优点, 缺点是太新, 但可共享redux的生态.
左华栋
左华栋

引用来自“keep_wan”的评论

赞是不是可以抛弃redux. 这玩意的确一堆的概念
react 使用 apollo-garaphql 的话有 store 可以做状态管理,不需要用到 redux , mobx 这些了。
hooks 这些所解决的问题,其实 angular 全家桶早就解决了。前端这套工程化思想还得发展好几年才能基本稳定。
zicjin
zicjin
对Mobx冲击更大
k
keep_wan
赞是不是可以抛弃redux. 这玩意的确一堆的概念
返回顶部
顶部