React进阶(1)-理解Redux

虽互不曾谋面,但希望能和你成为笔尖下的朋友

以读书,技术,生活为主,偶尔撒点鸡汤

不作,不敷衍,意在真诚吐露,用心分享

点击左上方,可关注本刊

   

前言

在React中,数据流是单向的,并且是不可逆的,这其实,也很好理解,之所以这么设计,是因为组件复用的特点

父(外部)组件向子(内部)组件传递数据是通过自定义属性props值的方式进行实现的,并且在子组件内部通过this.props进行获取,它并不能直接被修改,如果想要修改,那么得通过React内置的一个setState的方法进行触发

而子组件想要传递数据给父组件,是通过调用父组件的方法进行通信

一个组件可能存在着很多状态,组件之间有时需要进行通信,对于多个组件状态维护,如果依旧用原来的方式,那么就比较复杂了的

那么Redux正好解决了这一问题.个人觉得,Redux学起来很抽象,的确是块硬骨头,但是高山始终是要越过的

下面就一起来学习下Redux的

您将在本文中学习到

• Redux是什么

• Redux的使用场景以及与不使用Redux的灵魂对比

• Redux的工作流程

• Redux的设计基本原则

本篇虽不涉及代码层面上的,但是对后续编码Redux非常重要,磨刀不误砍柴工

 Redux是什么?

官方解释:JavaScript应用程序的可预测的状态容器(一个管理应用程序状态的框架）

通俗一点:管理组件公共数据状态的容器(仓库/区域)

解决的问题: 当应用组件拥有多个状态,并且组件之间需要共享数据状态时,从原始的组件传递数据的方式中解脱出来,集中管理组件的状态

你可以把Redux理解为一个仓库,房产中介.拥有很多共享的房源的一个管理者,后面会有具体的例子

 Redux的使用场景

从上面提到的Redux解决问题可以看出,Redux只是用来管理和维护组件的状态的

React开发的模式就是组件化开发,将一个大的应用拆分成若干个小的应用,然后拼接成一个大的应用,而编写一个大小应用就是在编写各个大小组件

而组件的显示形态又取决于它的状态,这不区分于无论是外部的props还是内部的state,而组件之间有时需要共享传递数据,Redux仅仅就是用来管理这些组件的状态的

在一些开发者眼里,项目里要是没有用到Redux,就觉得很low,要么把Redux捧得高高在上,要么说都已经快0202年了,都用React hook了,鄙视得不行,个人觉得完全没有必要.

React与Redux本身就是解决两个不同方向的问题,某种程度上讲,React可以视为MVC架构中的视图层V,而Redux则是model数据层M,而C层往往是连接视图层和model的连接器,往往处理前端数据请求,路由跳转等业务逻辑

即使不用Redux,照样能做小应用,只是略复杂繁琐一些而已,下面会介绍他们之间的对比

那么对于技术选型,什么时候用Redux什么时候不用?

以下是选用Redux的场景:

• 项目非常庞大,公共组件与业务组件非常多,用户的使用方式比较复杂

• 不同身份的用户角色权限管理(例如很多后台管理系统,普通用户,超级管理员,VIP用户)读,写权限管理等

• 多个用户之间可以协作实时操作(很多那种在线敏捷协作办公文档工具,多个用户可以实时编辑操作同一份文档等的,例如石墨文档,语雀,confluence.钉钉等的)

• 需要与服务器大量的交互,或者使用了webscoket的,聊天,直播等应用的

• 视图层view需要从多个来源获取数据

• ....只要你发现React解决不了的问题,遇到多交互,多数据源的,那么就可以考虑使用Redux的

(房中一墅景,少年,你渴望力量?)

对于技术性的投入,我从来都是不吝啬的,主动学习是对自己最好的投资

（Redux的确理解有些绕,但并不代表学不会,多读书,多实践,巩固基础）

反之