美文网首页让前端飞React Native实践
数据流架构学习笔记(二)-Redux

数据流架构学习笔记(二)-Redux

作者: 乐帅 | 来源:发表于2017-10-14 19:02 被阅读274次

    初期参加工作开发项目时,使用React Native + Flux进行手机应用跨平台开发,在上一篇博文中数据流架构学习笔记(一)-Flux 对Flux做了一次总结,本文是我对数据流管理架构学习总结的第二篇数据流架构学习笔记(二)-Redux,是我在工作过程中对项目使用Redux进行重构状态管理和数据流的学习记录。

    Redux的由来

    2014年 Facebook 提出了 Flux 架构的概念和单向数据流管理的思想,并给出了管理状态的基本数据流,但是随着前端应用的复杂性指数级的提升,前端页面需要管理的状态也越来越多,于是出现了很多基于Flux基本的数据流概念和单向数据流思想的实现方式。2015年,Redux 出现,将 Flux 与函数式编程结合一起,很短时间内就成为了最热门的前端架构。

    在实际项目中,你应该有遇到过以下这样情况的发生:

    • 在debug项目进行问题查找时,复杂的数据刷新页面时,由于一些不规范的监听和观察者机制使用或过多使用React中this.setState进行渲染页面,由于是异步进行数据渲染页面,经常无法判断本次造成是因为什么数据状态改变而造成页面渲染,而且更可恶的是此时你无法知道当前状态下,你的App实际的数据状态是如何的,就是说,你无法知道你App当前的所有数据是多少,而你同样也无法快速预测接下来你的App会如何变化。使用Redux就可以很好的解决这个问题。
    • 同样的如果你还在项目中进行模块划分,组件化开发,使用Redux可以快速将你的模块组件进行并入项目和拆分重组。

    Redux工作原理

    Redux 把自己标榜为一个“可预测的状态容器 ”,它充分利用函数式的特性,让整个实现更加优雅纯粹,使用起来也更简单。

    Redux(oldState) => newState
    

    Redux 可以看作是 Flux 的一次进化。Redux遵循以下三个基本原则:

    • 整个应用只有唯一一个可信数据源,也就是只有一个 Store
    • State 只能通过触发 Action 来更改
    • State 的更改必须写成纯函数,也就是每次更改总是返回一个新的 State,在 Redux 里这种函数称为 Reducer


    View 触发数据更新 —> Actions 将数据传递到 Store —> Store 更新 state —> 更新 View。
    

    Redux 中整个应用的状态存储在一颗 object tree 中,对应一个唯一的 Store,并且 state 是只读的,使用纯函数 reducer 来更新 state 会生成一个新的 state 而不是直接修改原来的。

    Redux 通过以上约束让 state 的变化可预测。

    如果无法理解这些概念,建议先学习Redux官方文档,再来查看他人的博客和使用方式,才能更快的使用。

    Redux实例封装

    这里以React Native实际项目登录部分展示如何将Redux应用到React Native开发中进行数据管理,在实际架构项目时,每个人有各自的编码习惯,因而,虽然同样是Redux,但是在各部分代码写法总是有所不一样,而实际项目中用起来的写法也是不一样的,但是思想总体上是一样的,不要拘泥于代码的写法,代码只是作为参考和总结,应该理解写法的目的思想和如何体现Redux的融入和使用。

    视图层View

    登录页:

    import { bindActionCreators } from 'redux';
    import { connect } from 'react-redux';
    import LoginAction from '../../actions/loginAction';
    ...
    class Login extends Component {
        ...
        _doLogin = () => {
            const param = {
              uid: this.state.uid,
              pwd: this.state.pwd
            };
        
            this.props.actions.doLogin(param)
              .then(() => {
                const { navigation, login } = this.props;
                if (login.status === 'done' && navigation) {
                  navigation.resetRouteTo('TabBar', { title: '首页', selectedTab: 'home' });
                } else {
                  Alert.alert(
                    '提示',
                    login.message
                  );
                }
              });
          };
        ...
    }
    ...
    const mapStateToProps = (state) => {
      return {
        login: state.loginReducer
      };
    };
    const mapDispatchToProps = dispatch => {
      return ({
        actions: bindActionCreators({ ...LoginAction }, dispatch)
      });
    };
    export default connect(mapStateToProps, mapDispatchToProps)(Login);
    

    简单说View层主要作用就是响应用户的操作,而实际在代码中我们主要的作用就是触发Action,如代码中调用this.props.actions.doLogin()函数,在this.props会存在actions属性是由于在最后使用bindActionCreators方法将对应的LoginAction绑定至页面组件Login中,这样造成我在View层只会做调用action的操作,不会直接使用dispatch进行消息分发。这样就完成了View -> Actions的过程。

    行为Action

    
    const _loginSuccess = (data) => {//eslint-disable-line
      return {
        type: ActionTypes.LOGIN_SUCCESS,
        payload: {
          user: data.uid
        }
      };
    };
    
    const _loginFailed = (error) => {
      return {
        type: ActionTypes.FAIL,
        payload: {
          message: error.message
        }
      };
    };
    
    const _doLogin = (url, param) => dispatch => {
      dispatch(CommonAction.showLoading());
      return Fetcher.postQsBodyFetch(url, param)
          .then((response) => {
            dispatch(CommonAction.dismissLoading());
            dispatch(_loginSuccess(param, response));
          }).catch((error) => {
            dispatch(CommonAction.dismissLoading());
            dispatch(_loginFailed(error));
          });
    };
    
    const LoginAction = {
      doLogin: (param) => _doLogin(NetLink.login, param),
      loginSuccess: (data) => _loginSuccess(data),
      loginFailed: (error) => _loginFailed(error),
    };
    
    

    Action通常都是在进行网络层调用、请求数据和分发数据,因在View层使用了bindActionCreators方法和组件绑定后,将会直接获取View层组件dispatch属性方法,使得在Action的纯函数中在数据返回后调用dispatch()进行数据分发。这样就完成了Actions -> Reducer的过程。

    Reducer

    import ActionType from '../constants/actionType';
    
    const initialState = {
      status: 'init',
      user: '',
      message: null
    };
    
    const loginReducer = (state = initialState, action) => {
      switch (action.type) {
        case ActionType.LOGIN_SUCCESS:
          return Object.assign({}, state, {
            status: 'done',
            user: action.payload.user,
          });
        case ActionType.FAIL:
          return Object.assign({}, state, {
            status: 'fail',
            message: action.payload.message,
          });
        default:
          return state;
      }
    };
    
    

    Reducer类似原来Flux的store,作为数据仓库来源,这里将会收到来自调用dipatch()后获得的消息,并进行处理和保存,并在及时更新数据后,通过redux的组件绑定,自动反馈至页面组件中进行数据更新和异步渲染,而在这里你应该return一个全新的对象,redux才能知道你是更新了当前组件关联的reducer,到了这一步你应该会产生疑问,数据状态是如何反馈至View,而你写的普普通通的Action和Reducer等js文件是如何关联上你的组件和应用。

    绑定和引入

    入口组件Root.js:

    import React, { Component } from 'react';
    import { Provider } from 'react-redux';
    import { createStore, applyMiddleware } from 'redux';
    import thunk from 'redux-thunk';
    import Fetcher from './network/fetcher';
    import Main from './containers/mainContainer';
    import rootReducer from './reducers/rootReducer';
    
    const middlewares = [thunk];
    const createStoreWithMiddleware = applyMiddleware(...middlewares)(createStore);
    const createLogger = require('redux-logger');
    
    if (process.env.NODE_ENV === 'development') {
      const logger = createLogger();
      middlewares.push(logger);
    }
    
    function configureStore(initialState) {
      const store = createStoreWithMiddleware(rootReducer, initialState);
      return store;
    }
    
    const store = configureStore();
    
    export default class Root extends Component {
      constructor(props) {
        super(props);
        Fetcher.initNetworkState();
      }
    
      componentWillUnmount() {
        Fetcher.removeNetworkStateListener();
      }
    
      render() {
        return (
          <Provider store={store}>
            <Main {...this.props} />
          </Provider>
        );
      }
    }
    

    其中rootReducer.js:

    import { combineReducers } from 'redux';
    import LoginReducer from './loginReducer';
    ...
    
    const rootReducer = combineReducers({
      loginReducer: LoginReducer,
      ...
    });
    
    export default rootReducer;
    

    先使用combineReducer将所有的reducer合并成一个rootReducer,使用rootReducer,在接着开始通过createStore方法创建了store对象,通过redux提供的Provider组件直接将store对象绑定至实际的View组件上,这样就完成了

    View 触发数据更新 —> Actions 将数据传递到 Store —> Store 更新 state —> 更新 View。
    

    关于其中的applyMiddlewarebindActionCreators等等方法是关于异步actions、异步数据流、Middleware的进阶知识。具体内容建议查看Redux官方文档了解相关内容。以下Redux进阶也将会大概讲解他们的使用和为什么使用。

    Redux进阶

    使用redux-thunk和redux-logger框架,并使用applyMiddleware和Middleware来加强Redux的使用,使Redux更加强大、规范和合理。其中redux-logger框架简单理解就是添加一个Redux日志打印和处理框架,开发者无需知道他如何规范打印出Redux的dispatch日志的,但是在开发时,用于debug等是很有用的工具。redux-thunk属于处理异步Actions和异步数据流的框架。

    异步Actions和异步数据流

    什么是异步Actions和异步数据流,简单来说,就是网络请求来控制的Actions。如App中你点击一个按钮立即发出了一个dispatch(), 这是你对App控制作出的dispatch(), 这叫做同步Actions,而异步Actions并不是你控制的,如网络请求成功或失败后,才会发出一个dispatch(),这就是异步Actions,你无法知道这个dispatch()是什么时间做出的操作,也不知道你发出的是成功的dispatch()或是失败的dispatch()。

    如我loginAction中方法,现在应该就能很好的理解这个方法这样写的原理:

    const _doLogin = (url, param) => dispatch => {
      dispatch(CommonAction.showLoading());
      return Fetcher.postQsBodyFetch(url, param)
          .then((response) => {
            dispatch(CommonAction.dismissLoading());
            dispatch(_loginSuccess(param, response));
          }).catch((error) => {
            dispatch(CommonAction.dismissLoading());
            dispatch(_loginFailed(error));
          });
    };
    

    Middleware

    middleware翻译成中文意思中间件,很贴切也很容易理解,像redux-thunk 或 redux-promise就可以叫做中间件,如果你想使用这些中间件,就需要使用applyMiddleware等等相关方法为你的项目添加上这些框架。使项目使用redux更加强大和规范。

    像redux-thunk 或 redux-promise 这样支持异步的 middleware 都包装了 store 的 dispatch() 方法,以此来让你 dispatch 一些除了 action 以外的其他内容,例如:函数或者 Promise。你所使用的任何 middleware 都可以以自己的方式解析你 dispatch 的任何内容,并继续传递 actions 给下一个 middleware。比如,支持 Promise 的 middleware 能够拦截 Promise,然后为每个 Promise 异步地 dispatch 一对 begin/end actions。

    当 middleware 链中的最后一个 middleware 开始 dispatch action 时,这个 action 必须是一个普通对象。这是 同步式的 Redux 数据流 开始的地方(译注:这里应该是指,你可以使用任意多异步的 middleware 去做你想做的事情,但是需要使用普通对象作为最后一个被 dispatch 的 action ,来将处理流程带回同步方式)。

    middleware 可以完成包括异步 API 调用在内的各种事情,了解它的演化过程是一件相当重要的事。而他们是如何演化过来的,并如何加强你的应用的,这里不再具体说明。

    总结

    Redux很强大,也相对复杂。简单的项目也许并不需要使用到,但是如果你的项目越来越大,数据越来越复杂,Redux将会使你项目更加规范和健壮。在项目中使用规范的框架架构,是一件非常重要的事情,你可以为你的项目使用架构,这是一件很有趣的事情。

    文章很长,Redux也很复杂,文中如有不对请告知,我会及时改正。一起进步和学习。谢谢!

    参考

    Redux 中文文档

    Redux 入门教程-阮一峰

    相关文章

      网友评论

        本文标题:数据流架构学习笔记(二)-Redux

        本文链接:https://www.haomeiwen.com/subject/rqjfuxtx.html