Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

React+Redux 组合使用之感受

Posted on 06/11/201710/08/2024 by 四火

最近完成了一个使用 React+Redux 组合的项目,以前仅仅是接触了解以及学习,并未正儿八经地使用过,因此这一次可以说是第一次完整地再一个项目当中使用。因而对于认识之浅显请轻拍。

从架构和层次的层面,这个组合给我最好的感受是干净利落的解耦。有不少 JavaScript 框架尝试解决解耦问题,但是到了落实的层面上很容易出现分层分模块不容易严格控制,缺少清晰标准等问题。但是 React+Redux 的组合没有这个问题,我们把应用中 JavaScript 的部分分层为 action、client、config、constant、reducer、store、util 和 view 几个部分,其中 view 又进一步划分成 component(不带业务逻辑)和 widget(包含业务逻辑)等几个子包。每一个小模块对应有规约路径和命名的 scss,在应用中基本上没有出现层次混乱的情况。当然也不尽美,其中一个容易混乱的地方在于传递的数据模型的设计,比如从服务端取回的对象,之后的数据处理可以放在 action 中,可以放在 reducer 中,甚至也可以放在 view 中——这是由(1)“到底想给 reducer 传递怎样的消息” 和(2)“在 store 中要存储怎样的数据结构” 来决定的。这一条标准的理解不同,容易引起不同的代码风格和不同的层次模块划分。

我们有一些新员工初涉 JavaScript,我觉得应用 React+Redux 组合的代码是非常好的 “第一个项目”,因为相对来说稍微严格一些的代码控制和清晰的层次模块划分,对于培养良好的设计和代码习惯有着非常大的作用。本来前端的世界里面就是良莠丛生,容易上手但是水又深,相对代码自由度高,而且杂七杂八的风格范型到处都是。培养一个好的习惯在职业生涯中受益无穷。

再吐槽关于 view 的一切都由 store 中的状态决定这一点。其实这个初衷非常好,特别利于解耦,view 可以划分到很小的模块,只有零零散散几个状态,并且问题定位的时候可以牢牢抓住状态变化这一点。但是凡事有利有弊,在大型项目的时候这一点明显增加了可维护性,但是也明显让项目的代码显得臃肿。基本上每添加一个小小的功能,都要从 action->reducer->view 等等一层一层写好多代码。如果遇到了一些特殊的情形,比如需要一些动画效果,真可谓杀鸡用牛刀,逻辑繁琐。以前也用过一些其他框架,比如 Angular 等等,如果从代码量上看,Redux 可以说是比较多的,如果你喜欢简洁清晰的代码,不喜欢一大堆 js 文件,那么你不会喜欢 Redux 的。

关于 JSX。React 中 JSX 可谓是最大的创新了,我本人也非常喜欢这种不同编程范型的融合(命令式代码和声明式代码)。如果有一个好的 IDE 插件,编码的过程是非常愉悦的。同时,JSX 和 JS 一样,测试非常方便,通常我们把测试用例和源码放在一起,只是每一个测试子包以 “_test” 命名,这一点非常利于源码和测试代码关联起来阅读。

最后赞一下 Redux 的 devtools,非常好用。结合起一些其他辅助测试的工具,我们现在基本上在开发模式下每当有任何源码的改动,或者 UT 的改动,改动影响到的 UT 会在后台自动运行,并且调试页面会自动加载改动的内容,省去了传统模式下 build-deploy-refresh 的过程。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 一些前端框架的比较(下)——Ember.js 和 React
  2. JavaScript 实现继承的几种方式
  3. 一个前端项目,到底要集成多少库和工具
  4. Chrome 插件开发
  5. 前端解耦的一个最简单示例

3 thoughts on “React+Redux 组合使用之感受”

  1. owenliang says:
    06/17/2017 at 1:47 PM

    react+redux 我也玩了一圈。分层解耦明显,工程非常清晰。

    代价就是每写一个 component 都要带入一套 action,reducer,当然简单组件不想用 redux 也可以不走 connect,这是可选的。

    Reply
  2. Xin v31.1.1 says:
    06/13/2017 at 3:06 PM

    同意!这是容器组件和展示组件相分离的典型例子。如果疲于写文中提到的 action->reducer->view 的层层代码,楼主可以尝试一下 dva 框架,它将 action 和 reducer 封装到 model 当中去了,简化了不少。

    Reply
    1. Kai says:
      06/13/2017 at 3:08 PM

      码工中我就服写 Javascript 的!

      Reply

Leave a Reply to Xin v31.1.1 Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme
Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接