上一篇中简单的描述了Redux的主要使用流程,本篇针对上一篇做一些补充。
1、Action 与 Reducer的详细理解
先回顾一下不使用Redux的情况下,React的Class该怎么写。
import React, { Component } from 'react';
class Test extends Component{
constructor(props){
super(props);
state={
name:''
}
}
handlerFunc = () =>{
const inputName = this.refs.inputValueTest.value;
this.setState({
name:inputName
})
}
render() {
const {name} = this.state;
return (
<div>
<label> {name} </label><br/>
<input ref="inputValueTest" /><br/>
<button onClick={this.handlerFunc}>confirm</button><br/>
</div>
);
}
}
嗯,主要就是这样:constructor 里初始化状态,然后渲染组件,onClick里绑定点击事件,事件函数中setState()一下,此时得到了新的状态,并使虚拟DOM重新渲染,最终Label显示我们输入的值。
这个过程理解了的话,也就能够和Redux进行对照理解。
然后看看使用Redux 后,组件是怎么写的:
import React, { Component } from 'react';
import PropTypes from 'prop-types'
class Test extends Component{
static propTypes = {
firstname:PropTypes.string.isRequired,
addName:PropTypes.func.isRequired
}
handlerFunc = () =>{
const inputName = this.refs.inputValueTest.value;
this.props.addName(inputName);
}
render() {
const {firstname} = this.props;
return (
<div>
<label> {firstname} </label><br/>
<input ref="inputValueTest" /><br/>
<button onClick={this.handlerFunc}>confirm</button><br/>
</div>
);
}
}
观察两种写法,会发现:
(1)初始化状态没有了,
(2)setState()也移除了,然后通过属性结构赋值。
总之,状态管理方面的东西都被移除了。因为采用Redux框架,本身就是要让他接管状态的,所以,redux框架下的React的代码就很好理解了。就是react组件里面是没有State相关的东西(当然,特殊情况下还是需要用的组件自己的状态管理的)。它所要做的就是,传递动作(按钮点击)或者请求(请求数据),并根据自身属性向HTML中填入数据。这里用到了prop-types这个库。来进行属性的校验。
之后可以这样理解,setState()方法在Redux那边被拆分成两步,现在Action中,把获取到的值,弄成一个Object,代码如下:
import { ADDNAME} from "./action-type";
//包含所有的action creator
export const addName = (name) =>({type:ADDNAME,data:name})
这里面的addName 就是React代码里按钮触发的方法中要执行的函数,name 就是我们或得到的输入框里的值。
接着redux帮我们做的就是用Store中提供的dispatch方法,把这个动作传到reducer那去,然后来看看Reducer做了什么:
import {ADDNAME} from './action-type'
const initialState = {
name:'Peter'
}
const name = (state=initialState,action) => { //形参默认值
switch(action.type){
case ADDNAME:
return action.data
default:
return state
}
}
由于我们把React中的状态让redux单独拎出来,所以最终会生成一棵大的状态树,也就是一个Object。所以这里的name,最终会成为这个状态树的一个属性,值就是返回值,action.data ,对应action里传入的值。可以看一下,状态树可以通过Store.getState获得:
State.png
Reducer 可以类别理解为,充当了setState的角色。并且也负责了初始化state的任务。
所以,reducer在case到ADDNAME 这个动作之后,就把从action那传来的值,做了一个相当于setState()的操作。要是一开始没有触发任何动作,则Store会帮我们在程序运行之初执行一遍Reducer,使用初始值,initialState
this.setState({
name:action.data
})
2、展示组件与容器组件
redux写的代码单拎出来与react代码是没啥联系的。写完上面的东西后,一运行就会报错,一大堆undefined。这个时候就需要一个connect来连接Redux和React。现在有这么一个库'react-redux'. 使用里面的connect 即可。如下:
import React from 'react'
import {connect} from 'react-redux'
import {addName} from '../redux/actions'
import Test from '../component/Test'
export default connect(
state => ({
firstname :state.name
}),
{addName}
)(Test)
(1)容器组件
这样就写好了一个组件,官方称之为容器组件,我个人把更愿意把它称之为封装组件,就是引入之前写好的React组件Test,再引入之前action和reducer 里的动作、状态,进行一个封装,这样就把Test里事件函数与属性匹配到了一起。
其中 firstname 对应Test 里面的firstname 属性 ,state.name 就是reducer 里定义的那个name.这样的话,到时候Test组件里用的firstname的值,就是state.name给赋上去的。属性状态匹配完之后要匹配动作,Test中点击事件中执行的addName,就匹配action里的addName。因为我这里两边都命名为addName,根据es6规则,属性名和属性值相同的话,可以省略不写,这样就单写一个就可以。这样,点击按钮之后,数据就会通过action传到Reducer那去做类似于setState()这样的操作。
最终拿出去用的,也都是这个组件,可以把它命名为TestContainer.jsx 用于路由或者直接放到哪都可以。
(2)展示组件 这个就是Test那个组件。里面一般不包含任何Redux相关的东西。纯净的React组件。称之为展示组件。可以理解为容器组件(封装组件)的一部分
3、异步
一个web应用,大多数都需要做请求操作的。而在React + Redux这样的一个结构中,异步请求操作最合适的位置就是放到Redux中的action中。首先,展示组件,即Test组件,这个是view层。view层显然不适合掺杂异步请求的。然后reducer其实是实现的类似于setState()的作用,并且这个时候才请求数据就有点晚了。所以在Redux中的Action中做异步请求是比较合适的。action其实也是个传接数据的载体。
既然选择在Redux中进行异步请求,就需要引入一个库 react-thunk,来帮助我们进行异步请求.
首先进行配置。
import {createStore,applyMiddleware} from 'redux'
import {finalReducer } from './reducers'
import thunk from 'redux-thunk'
//生成store对象
const store = createStore(finalReducer,applyMiddleware(thunk));//内部会第一次调用reducer函数,得到初始state
export default store
第一步 npm i redux-thunk;
第二步 引入 redux-thunk的thunk 以及Redux的applyMiddleware
第三步,在createStore中加入这个库
很简单。
然后就是使用了
正常来说,一般我们是触发一个动作,让他进行请求,得到数据后,再去setState.在Action中也是一样。如下:
export const addNameAsync = (name) =>{
return dispatch =>{
setTimeout(()=>{
dispatch(addNameCreater(name))
},2000);
}
}
这里用setTimeout模拟请求过程。两秒后,数据请求到了,再把数据给Reducer进行状态替换。这里的话,我们需要手动调用dispatch这个函数,向Reducer去分发动作。
总结
Redux这块一开始接受很多概念确实很难理解。学习就是如此,一下子铺天盖地的抛出很多你从来没听过的概念,无论是谁都接受的很困难。作为学习者,就需要类比,理解,然后追根溯源,看看底层如何实现。
就本篇与前一篇的例子而言,原本不到一百行的东西,在使用了Redux之后,分出了这么多个文件。确实,折中小来小去的玩意儿,放在一个文件里写就完事儿了。但是如果没有状态管理的这个意识。在进行大型项目的构建时,就很麻烦,一个请求过来的数据,可能要在多个组件用。这个时候,无论MobX 还是Redux这类的状态管理库,会节省很多开发时间,提高开发效率。
另外就是封装性很好,清晰的文件结构和代码结构,能够大大提高项目的可扩展行、可维护性以及降低耦合度。而对于一些把任何东西写到一起的那种项目,一个页面上千行甚至几千行,扩展维护起来的体验可想而知。
作为开发者,还是要对自己写的东西负责。
=========================
多少要有点基本的素养。不要动不动就把请求写在componentWillMount里!!!
网友评论