Monthly Archives: April 2016

Redux是如何工作的 (一)

凡是用reactjs开发的项目,但凡规模稍微大一些,都很可能要引入redux来管理组件状态的变迁和组件彼此之间的通信,权威的解释和说明当然是官方的这篇文章,但是,但是,但是,这篇长文处处透露着一种玄妙而不可言说的味道,处处是一些principle,best practice,never,absolutely,you should……的字眼,到处是强调,加粗的段落,一些模糊的store,action,reducer之类的抽象用词,我尝试着写篇小文来记录自己对Redux的学习理解过程。

1. 从reactjs本身谈起

正如官方文档强调的,我们只做view层,是的,reactjs利用JSX把UI的开发演进到另一种模式,就个人观点,我并不觉得其比其他基于模版的view技术究竟高到哪里去,有人说virtual dom技术比原来的直接操作dom来得效率高,拜托,它只是节省了dom元素的寻找时间,react使得程序员从数据变化耦合ui变化的面条代码中抽离出来,每个组件保持了极高的内聚性,给使用者带来了极大的方便,使得在view层堆积木式的开发成为可能,每个UI组件的state对于使用者是完全透明的,使用者只要为它设置好初始的props,组件本身可以响应各种事件来改变自身的状态,重新渲染外观。如果每一个组件都不需要跟外界通信,都不需要跟别的组件联动,那传统的state,props便足以对付所有的开发。但是组件之间的通信,这对一个稍微大型的SPA应用来说,都是必须要有的功能。

2. 我们能从传统的设计模式汲取什么

observer/observable,Event Listener是我们最常用的手段来注册,监听,响应外界感兴趣的变化,假设react组件A监听了组件B的变化,当组件B变化时它调用A注册的回调函数,同时把自己的state传递给B,注意,这里已经完全破坏了组件的边界,当A拿到B的state时,它可以做任何修改,所以实现时,B应该clone了一份自己最新的的state给A,那么问题来了,

1. A组件必须理解B组件的实现细节,不然它没办法理解B的state的含义,但state本身是应该对外界透明的。

2. 每个UI组件都必须暴露注册监听的接口

3. 大量的state复制操作

我们想一想如何自己解决这些问题,

1.  想不到,是的,真的想不到啊

2.  加个属性,不好办啊,A,C组件都想监听B的变化怎么办?

3.  前两个解决不了,这个就不是个问题啊

3. Redux 是怎么解决问题的

1.  计算机问题总是可以通过分层来解决,Redux引入了一个称之为store的层,所有的组件不再维护自身的状态,所有的状态都在这一层来维护,作为一个best practice,Redux推荐用扁平的方式来为维护这个store,所以每个状态都必须小心命名以防止同名冲突,一般的我都会加组件名作为前缀。

2.  既然组件不再维护状态的变化,那么组件的渲染必须通过组件属性的变化来完成,所以Redux在原组件外面重新包了一层,然后外层通过更新内层属性来触发内层UI的重新渲染,内层组件所有的数据通过props来绑定,同时调用通过属性传过来的回调函数来与外界通信,所以组件本身的内聚性得到了保证,组件总是通过属性来工作,需要特别指出的是,组件本身并不需要知道是否工作在Redux的上下文,它根本不知道action,reducer是什么东西,它只是根据传给它的属性来决定是否需要调用以及调用哪个作为属性传给它的回调函数,所以Redux本身也不需要必须和reactjs绑定,这个外部组件传进来的回调函数,它简单的dispatch一个action,action本身只是一个必须包含type属性的普通javascript对象,那这个action从哪里来呢?这里引入了一个action creator的概念,说白了就是一堆函数,每个函数返回一个action,他们一般都放在xx_actions.js ( xx代表组件名 ) 的文件里,这样看似多余的封装其实跟我们经常强调封装getXXX函数一样,它提供了一个hook点,使得我们有机会对action的创建有更多的额外控制,比如这个回调函数可以再返回一个function,这个返回的function调用生成一个Promise或者action,就像trunkMiddleware做的一样,第二个好处是同时避免了大量的创建不同action的逻辑耦合在一起。所谓的reducer就是action listener,它根据action的type来更新全局的store,很显然reducer针对同一个action会有多份实现,比如A,C组件对于B组件dispatch出来的同一个action有不同的反应。同时还应该有一个东西把各种必要的属性组合起来传递给我们的UI组件,具体怎么做,且听下回分解。

(未完待续)

React开发移动端h5应用踩过的坑们(持续更新中)

1. webpack 打包字体有时候会破坏字体格式导致浏览器decode失败,有的浏览器认为是警告,有的认为是错误,认为错误的直接不渲染页面

2. Object assign 方法不是全浏览器支持,尤其andriod和微信浏览器,需要自己找个polyfill

3. Promise不是全浏览器支持,尤其andriod和微信浏览器,需要自己找个polyfill

4. 这个跟react无关,主要是IE对flex布局的支持,对于flex:1 1 0,IE和微信浏览器直接扩展最后一个为0px,导致height为0,现象就是页面一片空白,写成flex:1 1 0%解决问题

5. 用ReactCSSTransitionGroup做页面间的滑动切换,只用定义appear的css,千万不要写enter和leave的,enter和leave是用来实现组件加入/离开组的动画效果。

6. 不要有工程洁癖,例如坚决不用jquery,坚决什么都用redux封装,有时候一个很简单的东西会被这种洁癖搞的很痛苦

7. 组件设计的力度不要太细,只对非常通用的组件做比较细力度的设计用来积累团队的code base,可以用于绝大多数项目,比如navbar,footerbar,infinitescroll list

8. 少用国产的React UI组件库,虽然看上去都不错,但是一用上,经常发现各种小坑

9. 认真读官方文档,有的虽然是短短一页,但是信息密度特别大,不仔细看经常会忽略某些非常重要的知识点

10. 一定要测试android browser,chrome for android,微信浏览器,不要只在自己的iphone上测了就OK了

11. 非常值得29欧买个jshybugger

12. Redux维护的state的生命周期是贯穿应用本身的生命周期,可能会积聚大量的数据在浏览器端,传统的组件自身维护state,组件销毁,state就销毁了,需要在不同的场景做取舍。