Jarvis's Blog

白帽子、全栈、IoT安全专家、嵌入式系统专家

深入理解react-redux

之前在Jarvis OJ的前端开发的时候,使用了react+redux的数据流组织形式,由于redux只是一个通用的Javascript模块,本身和React并没有什么关系,所有就有了一个react-redux的项目,提供了一些api用于react和redux之间更方便的连接和更科学的代码组织方式。记得当时开发的时候,参考了网上许多的教程和例子,但许多文章只是给出了demo或者写法,并未给出为什么要这样写的深层原因,当时开发的时候我也只是依样画葫芦并未深究其所以然,直到最近,我发现突然理解了react+redux为什么要写成这样的深层原因,因此本文本着探究的目的,谈谈我对react+redux项目写法的理解。

在开始之前,先吐槽吐槽,正如一些网友所说的,react的作者信奉unix哲学,希望把react打造成一个小而美的框架,只提供基本的功能,而不像AngularJS那样是一个all-in-one的整体解决方案。也正是因为如此,如果要使用react完成一个交互复杂的庞大单页面应用是远远不够的,还需要借助一些其他的第三方框架,本文所提到的redux就是其中之一。但是经过一番开发体验也会发现,也正如大家所说,在react加上了这些第三方框架之后,整体代码反而变得更加复杂了,比如angularJS只需要100多行就可以完成的一个数据流绑定操作的demo页面,而使用react+redux的方式,一个基本demo就长成下面这样:

这只是一个简单的计数器页面,就有这么多复杂的文件和设定。也就是说,整体看起来变得更加复杂了。这也是许多angular阵营的开发者诟病react的黑点之一。当然,我这里并不想讨论react和angular孰优孰劣的问题,也不想引战,这里仅仅就个人开发体验吐槽吐槽而已。

下面进入正题,首先,对Provider的理解,一个通常的react+redux项目,通常会在app的最外层用Provider再包一层,就像下面这样:

// config app root
const history = createHistory()
const root = (
  <Provider store={store} key="provider">
    <Router history={history} routes={routes} />
  </Provider>
)

// render
ReactDOM.render(
  root,
  document.getElementById('root')
)

而当我们不使用redux的时候,只需要<Route/>那个组件就可以了,这一点如何理解呢,实际上这个并不难理解,开发过react界面就会知道,react的工作原理实际上是父组件将属性,也即property传递给子组件,而最终子组件将自身的property渲染为实际浏览器显示的内容,而组件的state则是与用户操作相关的,当state改变时,整个render()方法都会重新执行,然后将新的dom和当前显示的dom对比,将差异的部分进行更新。所以我们不使用redux的时候,通常会将父组件的state传入子组件,以完成整体页面的动作更新,就像下面这样:

<TextField style={styles.textField} 
           floatingLabelText="E-mail" 
           value={this.state.email} 
           errorText={this.state.emailerr} 
           onChange={this.handleEmailChange} />

TextField就是一个子组件,我们将父组件的回调函数以及state值传入,这样当父组件的state.email改变时,子组件textField的value也会立即改变,改变也会显示在实际的UI界面上。我们知道React中的数据流是单向传递的,只能由父组件传递给子组件,这一点和AngularJS不同,AngularJS的数据流是既可以单向也可以双向绑定的。单向传递这个特性虽然给我们造成了一些不便,但却可以使代码更易读更易维护,数据流以及state的变化更易于理解。所以通常来说,我们在一个应用里,会碰到的所有情况可以归结为以下三种:

1.父组件向子组件传递数据

2.子组件向父组件传递数据

3.子组件和子组件之间传递数据

我们知道1是最自然的情况,react原生就是这样的数据传递模式,而2的话,可以使用回调函数来解决。而3是最麻烦的情况,我们要解决3,通常会选择用父组件再将这2个子组件包一下,然后子组件分别向父组件的回调函数传递数据,然后再通过父组件根据相应的回调函数操作改变自身的state,传递给相应的子组件,这样子组件之间就可以交互数据了。虽然这样也能解决问题,但是不同人写的代码参差不齐,而且花样百出,可读性会很差,难以维护,在这时候,就要请出我们的redux了,其实也不止是redux,类似的数据流框架还有flux和reflux也能解决问题,框架的目的其实是为了更好的去组织代码,易于理解和方便维护,仅此而已。如果愿意自己造轮子解决,就像我上面说的,用父组件去包裹,不用redux也是完全可以的。redux只是提供了一个优雅的解决方案和设计思路而已,其被设计的目的也主要是为了解决上面的第3种情况的。

说到这里,Provider的作用就显而易见了,由于redux全局只有1个store,而在react中,数据流只能由父组件传递给子组件,因此,Provider就是这样一个“超级父组件”,它是整个根节点的父组件,store就由这个“超级父组件”向所有子组件传递。所以你会发现,使用了redux之后,所有组件都只需要设定propeties而不再需要state了。

下面就是一个典型的使用了redux之后子组件的写法:

import React,{Component,PropTypes} from 'react';

class Counter extends Component {
    static propTypes = {
        //increment必须为fucntion,且必须存在
        increment: PropTypes.func.isRequired,
        incrementIfOdd: PropTypes.func.isRequired,
        incrementAsync: PropTypes.func.isRequired,
        decrement: PropTypes.func.isRequired,
        //counter必须为数字,且必须存在
        counter: PropTypes.number.isRequired
    };

    render() {
        //从组件的props属性中导入四个方法和一个变量
        const { increment, incrementIfOdd, incrementAsync, decrement, counter } = this.props;
        //渲染组件,包括一个数字,四个按钮
        return (
            
<div>


                    Clicked: {counter} times
                    {' '}
                    <button onClick={increment}>+</button>
                    {' '}
                    <button onClick={decrement}>-</button>
                    {' '}
                    <button onClick={incrementIfOdd}>Increment if odd</button>
                    {' '}
                    <button onClick={() => incrementAsync()}>Increment async</button>
                

            </div>

        );
    }
}

export default Counter;

其中,渲染组件的状态使用的是props去渲染的,因为这时候所有子组件的properties,都被Provider所传递的store中的state所设定了,所以只需要properties就可以了,而两个类型是func的属性,其实就是回调函数。然而,正是因为单向数据流的关系,当子组件层数非常深的时候,此时在每个组件里都加入一个用来传递store的属性,难免这种写法有点太冗余了。所以,这时候就要请出我们的connect方法了。connect方法的目的就是将子组件和store直接connect在一起,而不用每一层都去传递这个store了,实际也相当于一个语法糖的作用。

于是,使用了redux之后,子组件通常会用下面这样的一个Container包起来:

import {bindActionCreators} from 'redux';
import {connect} from 'react-redux';
import Counter from '../components/Counter';
import * as CounterActions from '../actions/counter';


function mapStateToProps(state) {
    return {
        counter: state.counter,
    }
}

function mapDispatchToProps(dispatch) {
    return bindActionCreators(CounterActions,dispatch);
}


export default connect(mapStateToProps,mapDispatchToProps)(Counter);

 

其中,connect方法的2个参数分别是mapStateToProps和mapDispatchToProps,然后最后传入我们的Counter组件。这时候,就很容易理解了,mapStateToProps的作用就在于从store中取出渲染这个组件所需要的state,将其注入该子组件的Props,而redux中的Dispatch作用就是发起一个action让reducer处理,就相当于前面提到的,父组件的回调函数的作用,也就是说,mapDispatchToProps的作用就在于将父组件的回调函数也作为Props传入子组件。这就是我前面所述的“子组件通过父组件回调函数改变父组件状态,进而改变自身或者其他子组件Props来实现子组件间的数据传递”这个实现思路的一种实现而已,到现在,应该对于react-redux每个操作的意义就很容易理解了。

至于action和reducer,实际上是一种回调函数的组织形式而已,每个action发出的dispatch用于区分这个操作要完成什么,而reducer根据具体要完成的工作来改变store里的内容,这样的话,就可以更清晰的去组织回调函数(在这里叫reducer),而不必对于每个功能,都自己在父组件中自己命名一个过几天就忘了要干啥的回调函数,相比之下,用action+dispatch+reducer的模式去组织代码显然比自己随便命名回调函数要有章法的多。

至于其他middleware的功能,主要是为了解决一些细节方面的处理,比如redux-thunk用于解决异步action的问题,还有一些将reducer组合在一起的功能等等,这些都属于细节方面的实现,其实思路还是非常简单明了的。

最后说说结论吧,说白了react-redux就是实现了将所有子组件用超级父组件包裹,然后通过回调函数解决单向数据流中子组件之间的耦合问题,并用更优雅易于理解和维护的方式将代码组织起来,这就是react-redux的精髓所在。

当然,笔者水平有限,本文也仅仅处于笔者个人开发体会和观点,有任何其他观点或者本文中有任何疏漏或错误之处,也欢迎一起探讨。

关于文中示例项目的完整代码,大家可以在这里下载。

 

CTF Rank网站开发笔记(一)

上一篇

对于OJ类产品形式的一些思考

下一篇
评论
发表评论 说点什么
还没有评论
521
0

    浙公网安备 33011002014706号