乐趣区

关于前端:Redux概念理解实战上手内含大量实例

前言

这篇文章零根底也能够看,我尽量写得简略易懂了,如果感觉了解起来有点费劲,也能够先去官网入门。

这篇文章也附上了许多实战代码,然而因为篇幅起因,一些实战例子我没有间接摆出来,而是放在了 sandBox 链接里,除了慢长处还是很多的。

本篇文章由小狮子团队公布,微信公众号:小狮子前端,欢送大家的关注,关注即有福利~

一、Redux 因何产生?

首先说它为什么呈现

1. 趋势所致:JavaScript 单页利用开发日趋简单,JavaScript 须要治理比任何时候都要多的 state(状态)。

2. 治理一直变动的 state 十分艰难:如果一个 model 的变动会引起另一个 model 变动,那么当 view 变动时,就可能引起对应 model 以及另一个 model 的变动,顺次地,可能会引起另一个 view 的变动。state 在什么时候,因为什么起因,如何变动未然不受管制。

二、Redux 是干什么的?

说到底它也只是个工具,理解一个工具最开始当然是要理解它是做啥的咯。

官网对它的定义:Redux 是 JavaScript 状态容器,提供可预测化的状态治理。

具体一些:

  • Redux 会将整个利用状态 (其实也就是数据) 存储到Store
  • Store 外面保留一棵状态树(state tree)
  • 组件扭转 state 的惟一办法是通过调用 store 的 dispatch 办法,触发一个 action,这个 action 被对应的reducer 解决,于是 state 实现更新
  • 组件能够派发 (dispatch) 行为 (action) 给 store, 而不是间接告诉其它组件
  • 其它组件能够通过订阅 store 中的状态 (state) 来刷新本人的视图

能够联合这张图看:

三、Redux 怎么用?

官网实例(todo)

State: 用了一个一般对象形容利用中的 State,没有 setter(修改器办法)

{
  todos: [{
    text: 'Eat food',
    completed: true
  }, {
    text: 'Exercise',
    completed: false
  }],
  visibilityFilter: 'SHOW_COMPLETED'
}

Action: 想更新 state 中的数据,例如减少 todo,须要发动一个 action。Action 就是一个一般的 JavaScript 对象, 形容产生了什么的指示器

{type: 'ADD_TODO', text: 'Go to swimming pool'}
{type: 'TOGGLE_TODO', index: 1}
{type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL'}

强制应用 action 来形容所有变动带来的益处是能够清晰地晓得利用中到底产生了什么。如果一些货色扭转了,就能够晓得为什么变。

Reducer: 把 action 和 state 串起来,reducer 只是一个接管 state 和 action,并返回新的 state 的函数。

// 编写很多小函数来别离治理 state 的一部分
function visibilityFilter(state = 'SHOW_ALL', action) {if (action.type === 'SET_VISIBILITY_FILTER') {return action.filter;} else {return state;}
}

function todos(state = [], action) {switch (action.type) {
  case 'ADD_TODO':
    return state.concat([{text: action.text, completed: false}]);
  case 'TOGGLE_TODO':
    return state.map((todo, index) =>
      action.index === index ?
        {text: todo.text, completed: !todo.completed} :
        todo
   )
  default:
    return state;
  }
}

``````
//reducer 调用上两个 reducer,进而治理整个利用的 state
function todoApp(state = {}, action) {
  return {todos: todos(state.todos, action),
    visibilityFilter: visibilityFilter(state.visibilityFilter, action)
  };
}

手写实战(TodoList)

感兴趣的能够看一下 codesandbox-TodoList 例子可能会比较慢。

没有用过 sandbox 的,我展现一下大略长这样:

集体感觉这样比拟直观一些,所以前面有的还是贴的链接~
todo 这种例子还是比较简单的,相当于入门,了解 Redux 工作。

四、react-redux

能够看到下面咱们并没有应用到 react-redux,尽管能实现性能,但仔细会发现我是间接拿的 store,组件多的话个个拿 store,这样不好。我来总结一下不必 react-redux 可能会遇到头痛的问题比方:

1.store 并不是那么不言而喻,一旦组件层级变得更简单,这个 store 就会变得很难管制。

2. 逻辑组件看上去很乱,不清晰的起因 state 和 dispatch 没有各自写在一起,反复代码有点多,不直观。

3.React 组件从 Redux store 中读取数据,向 store 中散发 actions 更新数据还不够不便。

Provider

这个还是很好了解的,就是把 store 间接集成到 React 利用的顶层 props 外面Provider 是把 store 注入到 context,connect 才是吧 context 转换成 props,益处是,所有组件都能够在 react-redux 的管制之下,所有组件都能拜访到 Redux 中的数据。

<Provider store={store}>
    <App />
 </Provider>,

connect

  • 技术上讲,容器组件就是应用 store.subscribe() 从 Redux state 树中读取局部数据,并通过 props 来把这些数据提供给要渲染的组件。
  • 为啥要用它,简略来说节俭工作,没有他得手工开发容器组件,并为了性能而手动实现 React 性能优化倡议中的 shouldComponentUpdate 办法。
  • 应用 React Redux 库的 connect() 办法来生成,这个办法做了性能优化来防止很多不必要的反复渲染。

connect 的应用

代码如下:

const App = connect(mapStateToProps, mapDispatchToProps)(Counter);
export default App;

mapStateToProps

了解这个单词 mapStateToProps:把 state 映射到 props 中去,state 就是 redux 的 state 啦,props 就是 react 的 props 咯。

代码:

// Map Redux state to component props
function mapStateToProps(state) {
  return {value: state.count}
}

而后在组件中应用 this.props.value 就能实现渲染

class Counter extends Component {render() {const { value, onIncreaseClick} = this.props;
    return (
      <div>
        <span>{value}</span>
        <button onClick={onIncreaseClick}>Increase</button>
      </div>
    );
  }
}
export default Counter;

mapDispatchToProps

了解这个单词 mapDispatchToProps:map 各种 dispatch 变成 props。

// Map Redux actions to component props
 function mapDispatchToProps(dispatch) {
   return {onIncreaseClick: () => dispatch(increaseAction)
   }
 }

``````
class Counter extends Component {render() {const { value, onIncreaseClick} = this.props;
    return (
      <div>
        <span>{value}</span>
        <button onClick={onIncreaseClick}>Increase</button>
      </div>
    );
  }
}
export default Counter;

同理也是能够通过 this.props.onIncreaseClick 调用 dispatch,这样就不须要在代码中运行 dispatch 了。

connect、provider 利用实例

看了下面的介绍,应该能比较清楚的理解 connect 是干什么的了,而后也根本能明确怎么做了,但还是没有写哥实例更分明直白的了:

简略的点击减少 count 的实例,应该还有许多须要优化的中央,这里就学明确 connect 和 provider 就好了。

简单一点的 todolist 的实例 这里用了 hooks、connect、provider 没有用 react-redux 里的 hooks 钩子(如果有看不懂的话能够学学 hooks 或者等我有工夫再出一个 class 改写成 hooks 的文章,还是很简略的,只有你分心学)

五、Hooks 下的 redux

如果我的项目开发是用的 hooks,那很好,你又省了许多力量,比方计数器这个这种 简略 的状态治理例子,几行代码解决。

import {useState} from 'react';
function Example() {const [count, setCount] = useState(0);
  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

然而咱们能齐全不必 redux 状态治理了嘛?哈哈哈怎么可能呢

  • 对于曾经应用 redux 的:首先在 redux 没有给出对 hooks 较好反对之前,大多不会为了 hooks 来齐全重构我的项目吧,顺便一讲重构可能造成的问题:

    • 失去很多 connect()提供的主动援用缓存,可能导致性能问题,除非用大量的 useCallback()来包裹
    • 如果代码依赖于 mapStateToProps 中的 ownProps,那么你可能会应用 redux hooks 编写更多代码,而不能间接拿到这个属性。
    • 不能像以前那样在 mapDispatchToProps 中,为 action creator 提供依赖注入
  • 对于有可能是简单利用的:许多公司的我的项目大部分都是用的 redux 治理状态,他的许多长处比方繁多数据源、数据共享、事务状态、数据状态 I / O 和副作用隔离、状态回溯以及一系列辅助工具带来的弱小调试能力等等,使得用 redux 来治理数据流成为更好的抉择。
  • react-redux 公布了新的版本,与之前的 contextAPI 拆散,提供对 hooks 的反对,那这不就更香了

新的 redux 带来的扭转

  1. 不再须要应用 mapStateToPropsmapDispatchToPropsconnect来保护独自的 container 组件和 UI 组件,而是在组件中间接应用 redux 提供的 hooks, 读取 redux 中的 state。
  2. 能够将任何现有的自定义hooks 与 redux 集成,而不是将通过 hooks 创立的 state,作为参数传递给其余 hooks。

redux 对 hooks 的反对

首先介绍几个外围:

  • useSelector: 用于从 Redux 存储的 state 中提取值并订阅该 state。
  • useDispatch: 除了读取 store 中的 state,还能 dispatch actions 更新 store 中的 state。
  • useStore: 用于获取创立的 store 实例。

光看简介还不是很分明,一个个来说:

useSelector

看它的介绍,就很像 mapStateToProps,然而

  • 不提供 ownProps API,最好用 useCallback 或 useMemo 来获取
  • 和 useEffect 一样,如果不提供第二个参数,每次组件更新就会从新计算

那可能会存在一些担心,会不会新的没有之前用的 mapStateToProps 好用呢?那来看看他的一些益处吧:

  • 当然是配合 hooks 写代码更 简洁
  • 性能上连续 redux 以前的性能优化逻辑,比拟 props,如果以后的 props 跟老的 props 雷同,则组件将不会从新渲染。
  • 批处理更新,使得多个 useSelector()从新计算出 state,组件只会从新渲染一次,不必放心 useSelector 反复渲染问题

首先看看以前是怎么写的:

//before

// React component
class Counter extends Component {render() {const { value, onIncreaseClick} = this.props;
    return (
      <div>
        <span>{value}</span>
        <button onClick={onIncreaseClick}>Increase</button>
      </div>
    );
  }
}
export default Counter;

// Connected Component
// Map Redux state to component props
function mapStateToProps(state) {return {value: state.count}}
// Map Redux actions to component props
function mapDispatchToProps(dispatch) {return {onIncreaseClick: () => dispatch(increaseAction)}}

// Connected Component
const App = connect(mapStateToProps,mapDispatchToProps)(Counter)
export default App

而后让咱们用新的 useSelect 改写之前写得计数器:

//after
const Counter = props=> {const { count} = useSelector((state) => ({count: state.count})
  );
  return (
    <div>
      <span>{count}</span>
    </div>
  );
}
export default Counter;

useDispatch

之前是应用 mapDispatchToProps:

//before
// Map Redux actions to component props
  function mapDispatchToProps(dispatch) {
    return {onIncreaseClick: () => dispatch(increaseAction)
    }
  }

当初应用 useDispatch,能够间接在组件中应用,以匿名函数模式:

//after
const dispatch = useDispatch();
return (
    <div>
      <button onClick={()=>dispatch(increaseAction)}>Increase</button>
    </div>
  );

因为匿名函数的性质,每次从新渲染取得新的援用,如果作为 props 传递给子组件,那么子组件每次都要从新渲染。

优化的意见是在 useCallback 中创立这个匿名函数:

//after
import React, {useCallback} from "react";
import {useDispatch, useSelector} from "react-redux";
import increaseAction from "./store/action";
const Counter = props=> {const { count} = useSelector((state) => ({count: state.count})
  );
  const dispatch = useDispatch();
  const onIncreaseClick = useCallback(() => dispatch(increaseAction),[dispatch]
  );
  return (
    <div>
      <span>{count}</span>
      <button onClick={onIncreaseClick}>Increase</button>
    </div>
  );
}
export default Counter;

useStore

在任何须要拜访 store 的利用中,都能够通过 usestore 来获取。如果出于某种原因,比如说单元测试时,想要获取不同的 store,咱们能够将 store 通过新的 contextAPI 传递进组件树中,就像上面这样:

import React from 'react';
import {useStore} from 'react-redux';
import OtherProvider from './OtherProvider';

const Component = props => {const store = useStore();
  return <OtherProvider store={store}>{props.children}</OtherProvider>
}

实战

接着下面曾经改成 hooks 的 todolist 然而还是用的 connect 的实例,来从新用 react-redux 的 useSelector 和 useDispatch 实现。

根本思维后面介绍的差不多来,这里我就不败代码,为了更直观还是用 sandbox 尽管不是很快:

SandBox —— useSelector、useDispatch 实战 TodoList

Hooks 下的 redux 总结

为什么还是要用 redux?
简略来说:Redux 提供了应答大型利用的代码组织和调试能力,在程序出错时,能帮你疾速定位问题。

对于一些场景的需要 hooks 没法解决:

  • 须要保留或者加载状态
  • 跨组件共享状态
  • 须要与其余组件共享业务逻辑或数据处理过程

配合 hooks 新的 redux 带来的不一样的扭转:通过应用 useSelector、useDispatch 和 useStore 搭配这 hooks 写的确也是个不错的尝试。

总结

作为一个之前 vue 技术栈转 react 技术栈的菜鸟来说,还是踩了一些的坑的:
比方在有了 vuex 的根底之后,而后有没有了解分明了解 redux,很容易感觉他两差不多,但理论还是有挺多区别的,也是我深刻学习 redux 的一个导火索。

简略的说一下:
在 Vuex 中,$store 被间接注入到了组件实例中,因而能够比拟灵便的应用:

  • 应用 dispatch 和 commit 提交更新
  • 通过 mapState 或者间接通过 this.$store 来读取数据
  • 组件中既能够 dispatch action 也能够 commit updates

在 Redux 中:

  • 咱们每一个组件都须要显示的用 connect 把须要的 props 和 dispatch 连接起来。
  • Redux 中只能进行 dispatch,并不能间接调用 reducer 进行批改。
    从实现原理上来说,最大的区别是两点:

Redux 应用的是不可变数据,而 Vuex 的数据是可变的。Redux 每次都是用新的 state 替换旧的 state,而 Vuex 是间接批改。

Redux 在检测数据变动的时候,是通过 diff 的形式比拟差别的,而 Vuex 其实和 Vue 的原理一样,是通过 getter/setter 来比拟的。

挖坑

🚀🚀 后续可能大概率还会更新这篇文章,还有些没写到,心愿这篇文章对于你学习 redux 有所帮忙哦~

⭐️⭐️ 如果感觉不错的话,点个赞再走吧 ❤️ ❤️ ~~

退出移动版