React Key 在非数组、队列场景下的应用

猜猜这段代码会发生什么事?

以为仅仅是切换下按钮?

其实是会执行下面的流程

  1. isEditingfalse 的时候,点击 button
  2. isEditing 变成了 true
  3. 重新 render,在 virtualDOM 进行 diff 的时候,给 button 添加了 type=submit 以及 form='form-1'
  4. #form-1 表单被意外的 submit 了

来个 DEMO 验证下 继续阅读“React Key 在非数组、队列场景下的应用”

读书笔记《React-引领未来的用户界面开发框架》

React这么火,我们也来深入研究下吧。

买了本React相关的书籍,刚看了前十章,随手记一下读后感吧。

废话篇

这部分内容,人云亦云

垂直切分的组件

React对于配置多名前端开发的团队,在协作上有一定的优势。

其组件化思路,是一种垂直划分,每个组件高度自治。与我们习惯上的Html、JS、CSS三分离的水平划分思路不一样。

垂直划分,让每个组件自己决定自己的结构、行为、表现,调用方只需要拿来即可使用。使用JSX来定义组件结构,通过Sytle对象来inline样式属性。

这里有两个不爽的地方。

  • JSX语法太丑陋
  • style对象权重太高,外链样式难以做正常的样式覆盖

JSX语法问题,还好IDE能高亮,看上去稍微舒服点。内联style权重问题比较难解决,最近WebRebuild上萝卜分享过一个css_module的解决方案,挺暴力,但又十分有效。

枚举一切可变字段(state)

其实在Backbone的年代,已经有这样的东西,只是没有强调而已,且没有那么智能的去更新界面(Backbone需要手动监听字段变化,然后去执行对应的方法,一切都要手动)

在React的世界里面,一切的讨论都围绕着这些可枚举的state。为了能高效的实现刷新界面,大家都乐意去细化界面上每个可变元素,将其与组件的state映射起来(其实就是在JSX里面包个{this.state.something})

setState() => componentDidUpdate

由于所有可变因素(state)都被枚举出来了,且界面发生变化的原因有且仅有一个,这让React组件变得可预知性可测试性

大肚能容

ref、getDOMNode()、componentDidMount()、componentWillUnmount()让React有了兼容其他非React生态的JS库\组件的能力,这个还是挺赞的,对于已有业务,改造起来也稍微方便点。

高能篇

这部分脑洞比较大

论setter、getter的重要性

一个好框架\库,需要有一个统一的输入输出接口

在React里面,有一个很重要的概念,是一切改变,都必须通过setState()方法来传达。只有这样,所有的变化才是可控的、可预测的。

setter、getter这两个方法,其实在各种各样的库里面都有,但没有像React世界里面这么强调。

例如在某个中间环节,为了图快,时不时就出现直接修改原始对象属性的情况。这种变动,框架层面是没法侦测到的。

又例如读取某个带嵌套关系的对象,没用getter,一个不小心就把原始对象的引用给暴露的出来,然后极容易出现在某些边边角角发生引用被改动从而触发一些很隐晦的BUG。

论钩子的重要性

一个好框架\库,需要有丰富的外部钩子,便于拓展

WordPress占有率高吧,为啥?因为他易于定制、拓展,他有非常丰富完善的钩子机制来给各种主题、插件提供定制拓展能力。

React也有很多钩子,他强调的生命周期,其实就是一系列的钩子,给业务能非常容易的在想定制拓展的地方进行定制拓展。

Backbone有钩子吗?有,但少得可怜,没记错的话,Backbone.View默认只有initialize和render两个钩子,React组件单单存在期的钩子都比他多。

Marionette则弥补了Backbone.View在钩子上面的缺失,可惜太小众。

钩子要怎么做?简单来说就是在框架、库的生命周中埋下大量空函数供拓展的时候覆盖就好了。

未完待续