Redux--To be, or not to be?

Posted by liveipool on June 27, 2017

Redux–To be, or not to be?

在项目中是否需要用到redux

“只有遇到 React 实在解决不了的问题,你才需要 Redux 。”

这次在编写项目的过程中,我就体会到了一次到底要不要用redux的问题。
本来在最开始写代码时,看了我的页面似乎没有很多数据的交流,因此就觉得不用redux,直接用react写就好。
直到后来,需求有了变动,需要在全局某个状态之后更改子组件的数据,研究了半天,还是觉得使用redux才是最好的方法。
所以在这里再认真回顾下redux是否需要的场景:

如果你的UI层非常简单,没有很多互动,Redux 就是不必要的:

  • 用户的使用方式非常简单
  • 用户之间没有协作
  • 不需要与服务器大量交互,也没有使用 WebSocket
  • 视图层(View)只从单一来源获取数据

下面这些情况才是 Redux 的适用场景(多交互、多数据源):

  • 用户的使用方式复杂
  • 不同身份的用户有不同的使用方式(比如普通用户和管理员)
  • 多个用户之间可以协作
  • 与服务器大量交互,或者使用了WebSocket
  • View要从多个来源获取数据

这里也是吸取了一个很宝贵的教训,以后在拿到需求和原型图时,一定要仔细思考后面怎么写代码,需要用到哪些东西,磨刀不误砍柴工就是这个道理,着急着写很可能会像这次一样导致后来来大改代码。

自定义垂直表格

在写一个别人可以复用的组件时,不用写很多类名,写一个verticlaTable,然后后面用选择器写就好。这是因为写成组件给别人用时,别人只需要一个类名就可以使用而不是很多个。

判断哪些是常量最好提取出来

因为在项目中可能会遇到一些字符串或数值常量等,这些常量可能是使用次数较多但除非产品需求变动而一般不会改变,所以如果以后需求变动,某个字符串要改一些字符,那如果没有把这个字符串写成常量,以后更改会比较复杂,还需要挨个选取然后更改之类的。写成常量就只需要在一个地方写到。

相对路径和绝对路径

在项目中,使用相对路径还是绝对路径,除非是项目有明确的规定,所以一般要根据具体情况来判断。一般来说,相对的路径较少,如‘./style.css’或‘../../pic.png’之类的,但如果是一些很长的相对路径,让人很难知道到底是哪里的文件的时候,最好采用绝对路径的写法,如‘../../../../style.css’最好就写成‘app/styles.css’这样。

在UI库的某个组件上写一个项目使用的自定义样式组件

可以在这个UI库的组件外包一层样式,然后在其他地方就可以像使用UI库的组件那样使用,同时有了自定义的样式。这样就有了一个好用的自定义样式组件。

长变量名

在某些变量名较长或层次较多时,可以用一个较短的临时变量存起来,后面用临时变量访问数据,可以减少代码长度。

无用的注释或代码

在开发时会有很多无用的注释或测试注释代码等,在上传合并到项目的主要分支时,要先删掉,如果觉得还有用的话,自己用其他的方式保存。

保持reducer的case里的纯净

reducer中的action case中,尽量保持纯净,不要有计算,就set state就好了。

赞赏码.jpeg