从 loading 的 9 种写法谈 React 业务开发

浅浅的花香味﹌ 2022-01-31 16:39 208阅读 0赞

![banner][]

**前言**

这是一篇比较全面讲解 React 的文章，里面很多基础知识希望你自己一边查阅资料一边学习。全文从业务开发中最常用见 loading 效果不同是实现讲起，说下现在前端开发在业务上应该有的思考。  
  
**入门级操作**

[State][]

最简单的实现，我们在 Loading 组件内部声明一个状态，通过代码逻辑判断 loading 效果的展示。

JavaScript

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 </td> 
 <td> export default class extends Component { &nbsp;&nbsp;... &nbsp;&nbsp;render() { &nbsp;&nbsp;&nbsp;&nbsp;return this.state.loading ? &lt;div className="loader" /&gt; : &lt;div&gt;finish&lt;/div&gt;; &nbsp;&nbsp;} } </td> 
 </tr> 
 </tbody> 
</table>

[完整演示][Link 1]

[Props][]

随着业务的发展，这个 Loading 组件用到的地方会非常多，上面这个代码耦合了很多逻辑，为了让这个组件能够很好的复用，那我们抽离出组件的业务逻辑，将内部状态进行提升，那这个组件就是一个能被复用的 UI 组件。

JavaScript

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 </td> 
 <td> export default function(props) { &nbsp;&nbsp;return props.loading ? &lt;div className="loader" /&gt; : &lt;div&gt;finish&lt;/div&gt;; } </td> 
 </tr> 
 </tbody> 
</table>

[完整演示][Link 2]

注：上面两段代码你可能会想，为什么 `Func` 和 `Class` 都能实现一个组件，他们有什么差别吗？  
其实你在开发时不容易感觉到差别，但 React 本身是进行了很多差别处理，如果是 Class 类，React 会用 `new` 关键字实例化，然后调用该实例的 `render` 方法，如果是 Func 函数，React 会直接调用它。

[Refs][]

如果你是一个 jQuery 转型 React 的开发，会很自然的想到，我找到 Loading 组件的节点，控制他的显示与隐藏，当然这也是可以的，React 提供 Refs 方便你访问 DOM 节点 或 React 元素。

JavaScript

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 </td> 
 <td> export default class extends Component { &nbsp;&nbsp;componentDidMount() { &nbsp;&nbsp;&nbsp;&nbsp;fetch().then(() =&gt; { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;this.el.changeLoading(false); &nbsp;&nbsp;&nbsp;&nbsp;}); &nbsp;&nbsp;} &nbsp; &nbsp;&nbsp;render() { &nbsp;&nbsp;&nbsp;&nbsp;return ( &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;Loading ref={el =&gt; { this.el = el; }} /&gt; &nbsp;&nbsp;&nbsp;&nbsp;); &nbsp;&nbsp;} } </td> 
 </tr> 
 </tbody> 
</table>

[完整演示][Link 3]  
  
**通用逻辑抽离**

当你的应用做到一定的复杂度，不同的页面都会有 loading 效果，你肯定不希望每个页面都重复的书写一样的逻辑，这样会导致你的代码重复且混乱。

React 中有两个比较常见的解决方案 `HOC` 和 `Render Props`，其实这两个这两个概念都是不依赖 React 的。

让我们暂时忘掉 React，下面我对 `HOC` 和 `Render Props` 写两个例子，你会发现组件复用是如此简单。

[HOC][]

HOC 其实就是一种装饰器模式，它接受一个组件作为参数，然后返回相同的组件，这样就可以额外增加一些功能。

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 </td> 
 <td> const func = () =&gt; { &nbsp;&nbsp;console.log("func"); }; &nbsp; const wrap = func =&gt; { &nbsp;&nbsp;console.log("wrap"); &nbsp;&nbsp;return func; }; &nbsp; // wrap 逻辑已被复用 wrap(func)(); </td> 
 </tr> 
 </tbody> 
</table>

[完整演示][Link 4]

[Render Props][]

Render Props 就是我们给一个函数传递一个回调函数做为参数，该回调函数就能利用外面函数的执行结果做为参数，执行任何操作。

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 </td> 
 <td> const func = param =&gt; { &nbsp;&nbsp;console.log("func"); }; &nbsp; const wrap = (param, func) =&gt; { &nbsp;&nbsp;console.log("wrap"); &nbsp;&nbsp;func(param); }; &nbsp; // wrap 逻辑已被复用 wrap("", func); </td> 
 </tr> 
 </tbody> 
</table>

[完整演示][Link 5]

相同点：

*  两者都能很好的帮助我们`重用组件逻辑`；
 *  和回调函数类似，当嵌套层数很多时，会造成`回调地狱`。

不同点：

*  HOC 和 父组件有相同属性名属性传递过来，会造成属性丢失；
 *  Render Props 你只需要实例化一个中间类，而 HOC 你每次调用的地方都需要额外实例化一个中间类。

总的来说，在需要复用组件逻辑的时候，我个人更倾向于 Render Props 的方式。  
  
**复杂状态管理**

当你的应用越来越大，组件之间交互越来越复杂，那整个页面的数据逻辑将变得难以管理，这时候为了方便管理应用的状态，你可以选择一些状态管理工具，例如 [Redux][]、[Flux][]、[dva][]等。

[Redux][Redux 1]

![Redux][Redux 2]

我不太想谈这些数据流框架，因为他们的概念 `action`、`store`、`dispatch` 太过于生涩难懂。  
  
现代前端框架 React 和 Vue 其实都是一个套路，通过数据渲染试图，然后视图上操作反过来更新数据，重新渲染视图，刷新页面。  
  
数据叫做 `store`，动作叫做 `ation`，触发行为叫 `dispatch`，然后数据到视图的渲染由 React/Vue 处理的。

（图片来自 [这里][Link 6]）

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 </td> 
 <td> // reducers.js const initialState = { &nbsp;&nbsp;loading: false }; &nbsp; export default function reducer(state = initialState, action) { &nbsp;&nbsp;switch (action.type) { &nbsp;&nbsp;&nbsp;&nbsp;case "CHANGE_LOADING": &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;loading: action.payload &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}; &nbsp;&nbsp;&nbsp;&nbsp;default: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return state; &nbsp;&nbsp;} } </td> 
 </tr> 
 </tbody> 
</table>

[完整演示][Link 7]

[Saga][]

当你代码中有大量的异步操作时，例如 fetch 请求，你肯定会想到`事件监听`、`回调函数`、`发布/订阅`。  
很好，上一个例子其实就是`事件监听`的处理方式，然后`回调函数`的主流的解决方案是 [redux-thunk][]，而`发布/订阅`的主流解决方案是 [saga][Saga]。

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 </td> 
 <td> import { takeLatest, put } from "redux-saga/effects"; &nbsp; import fetch from "./fetch"; &nbsp; function* fetchInfo(action) { &nbsp;&nbsp;yield put({ &nbsp;&nbsp;&nbsp;&nbsp;type: "CHANGE_LOADING", &nbsp;&nbsp;&nbsp;&nbsp;payload: true &nbsp;&nbsp;}); &nbsp; &nbsp;&nbsp;yield fetch(); &nbsp; &nbsp;&nbsp;yield put({ &nbsp;&nbsp;&nbsp;&nbsp;type: "CHANGE_LOADING", &nbsp;&nbsp;&nbsp;&nbsp;payload: false &nbsp;&nbsp;}); } &nbsp; export default function* fetchSaga() { &nbsp;&nbsp;yield takeLatest("FETCH_REQUEST", fetchInfo); } </td> 
 </tr> 
 </tbody> 
</table>

[完整演示][Link 8]

当你耐心看到这里，我知道你对 React 肯定有一定的经验，现在还可以做很多，例如把 loading 状态提升到 Store 的顶部，那整个站点就只有一个 loading 了，然后你还可以将 fetch 再封装一个 HOC 修改 loading 状态，这就是一个相对完美的 loading，其实 React 业务开发都可以用这个套路。  
  
**新的 API**

[Context][]

![context][]

上面 redux 的例子是不是过于复杂  
  
对于简单的业务，虽然有很多页面，嵌套层次也很复杂，你当然可以不用状态管理工具，你可以试着使用 Context，它可以方便你传递数据，它其实就是 Render Props 的一种实现。

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 </td> 
 <td> export default React.createContext({ &nbsp;&nbsp;loading: false, &nbsp;&nbsp;changeLoading: () =&gt; {} }); </td> 
 </tr> 
 </tbody> 
</table>

[完整演示][Link 9]

[Hooks][]

写到这，静一下，是不是哪里做错了什么？

我的业务只是想写个简单的 loading 效果，却了解了一堆组件生命周期的概念。

Hooks 刚好帮你解决了这样的问题，Hooks 能允许你通过执行单个函数调用来使用函数中的 React 功能，让你把`面向生命周期编程`变成`面向业务逻辑编程`。

JavaScript

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 </td> 
 <td> import React, { useState, useEffect } from "react"; &nbsp; import Loading from "./Loading/index"; import fetch from "./fetch"; &nbsp; function App() { &nbsp;&nbsp;const [loading, setLoading] = useState(true); &nbsp; &nbsp;&nbsp;useEffect(() =&gt; { &nbsp;&nbsp;&nbsp;&nbsp;fetch().then(() =&gt; { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;setLoading(false); &nbsp;&nbsp;&nbsp;&nbsp;}); &nbsp;&nbsp;}, []); &nbsp; &nbsp;&nbsp;return &lt;Loading loading={loading} /&gt;; } &nbsp; export default App; </td> 
 </tr> 
 </tbody> 
</table>

[完整演示][Link 10]  
  
**好好总结**

上面对每个点都做了具体实现，但他们都不是隔离的，你可以根据你的认知和业务特点总结抽象一套自己的方法论；

`多了解`、`多抽象`、`多思考`，练就十八般武艺，遇到问题的时候才能游刃有余；

React 现在宣传的东西越来越多，你最好先深入了解他们，然后用批判的眼光，保持理智，防止自己每天用很新的特性重构你自己的代码。  
  
**参考文章**

[React 官网][React]

[When do I know I’m ready for Redux?][Link 6]

[banner]: https://www.itcodemonkey.com/data/upload/portal/20190115/1547518153542125.png
[State]: https://reactjs.org/docs/state-and-lifecycle.html
[Link 1]: https://codesandbox.io/s/j22nqo2k4y
[Props]: https://reactjs.org/docs/components-and-props.html
[Link 2]: https://codesandbox.io/s/k39472w027
[Refs]: https://reactjs.org/docs/refs-and-the-dom.html
[Link 3]: https://codesandbox.io/s/ywwmm3j46z
[HOC]: https://reactjs.org/docs/higher-order-components.html
[Link 4]: https://codesandbox.io/s/8zx85nrzk2
[Render Props]: https://reactjs.org/docs/render-props.html
[Link 5]: https://codesandbox.io/s/0v1p4rp7xv
[Redux]: https://github.com/reduxjs/redux
[Flux]: https://github.com/facebook/flux
[dva]: https://github.com/dvajs/dva
[Redux 1]: https://redux.js.org/
[Redux 2]: https://www.itcodemonkey.com/data/upload/portal/20190115/1547518153407707.gif
[Link 6]: https://medium.com/dailyjs/when-do-i-know-im-ready-for-redux-f34da253c85f
[Link 7]: https://codesandbox.io/s/94zoy50q6w
[Saga]: https://redux-saga.js.org/
[redux-thunk]: https://github.com/reduxjs/redux-thunk
[Link 8]: https://codesandbox.io/s/rrnp9vk3wp
[Context]: https://reactjs.org/docs/context.html
[context]: https://www.itcodemonkey.com/data/upload/portal/20190115/1547518153205457.jpg
[Link 9]: https://codesandbox.io/s/6lp0p7z4jz
[Hooks]: https://reactjs.org/docs/hooks-intro.html
[Link 10]: https://codesandbox.io/s/98m4j00vwo
[React]: https://reactjs.org/