你可能并不需要 Redux

AZmake 發(fā)布于2019-08-22 18:25 / 996人閱讀

摘要：你可能不需要人們經(jīng)常在他們不需要的時候選擇它。將與不需要指定格式代碼去更新的方法比較是太正常不過，可以得出結(jié)論是復(fù)雜的。保持歷史可撤銷或?qū)崿F(xiàn)可預(yù)見的變化，而不會對編寫代碼的方式發(fā)生重大變化。哇你應(yīng)該對有狀態(tài)的組件做這件事嗎可能不會。

你可能不需要 Redux

人們經(jīng)常在他們不需要 Redux 的時候選擇它。“如果我們的應(yīng)用沒有使用 Redux 怎么擴(kuò)展？”，緊接著，開發(fā)人員對間接的Redux引入他們的代碼感到不滿。“為什么我必須引用三個文件才能得到一個簡單的功能？” 為什么呢！

我能夠理解人們責(zé)怪 Redux, React, 函數(shù)式編程，不變性和其他許多事情使他們陷入困境。將 Redux 與不需要“指定格式”代碼去更新 state 的方法比較是太正常不過，可以得出結(jié)論 Redux 是復(fù)雜的。在某種程度上來說是的，但是設(shè)計如此。

Redux 提供了一個權(quán)衡，他要求你：

將應(yīng)用程序狀態(tài)描述為普通對象和數(shù)組

將系統(tǒng)中的變化描述為普通對象。

將處理更改的邏輯描述為純函數(shù)。

使用 React 或者不適用，這些都不是構(gòu)建一個應(yīng)用必要的限制。事實上這些都是很強(qiáng)的限制，在你的應(yīng)用上使用它之前，你應(yīng)該仔細(xì)考慮清楚。

你有這么做的充分理由嗎？

這些限制對我很有吸引力，因為它們可以幫助構(gòu)建應(yīng)用程序：

將 state 在本地存儲，項目啟動開箱即用。

在服務(wù)渲染提前寫入 state 以 HTML 格式發(fā)送到客戶端，在客戶端啟動，開箱即用

序列化用戶操作，并將它們與狀態(tài)快照一起附加到自動化的bug報告中，以便產(chǎn)品開發(fā)人員可以重放它們以重現(xiàn)錯誤。

通過傳遞 action 對象以實現(xiàn)寫作環(huán)境，而不會對編寫代碼的方式發(fā)生重大變化。

保持歷史可撤銷或?qū)崿F(xiàn)可預(yù)見的變化，而不會對編寫代碼的方式發(fā)生重大變化。

在開發(fā)過程中往來于 state 歷史之間，并在代碼更新時通過 action 的歷史來決定當(dāng)前的 state

為開發(fā)工具提供全面的檢查和控制能力，以便產(chǎn)品開發(fā)人員能夠為他們的應(yīng)用程序定制工具。

在重用大部分業(yè)務(wù)邏輯時提供可選的 UI。

如果你正在開發(fā)一個可擴(kuò)展的終端，一個JavaScript調(diào)試器，或者一些網(wǎng)絡(luò)應(yīng)用程序，那就值得嘗試一下，或者至少考慮一下它的一些想法（順便說一下，它們不是新的！）

然而，如果你還在學(xué)習(xí) React，不要選擇 Redux 作為你的第一選擇。

相反，學(xué)會在 React 中思考。如果你真的需要它，或者你想嘗試一些新的東西，就回過頭使用 React。但要謹(jǐn)慎對待，就像你用任何固執(zhí)己見的工具一樣。

如果你覺得有壓力去做“Redux的方式”，這可能表明你或你的隊友對此過于重視。它只是你工具箱中的一個工具，一個瘋狂的實驗。

最后，不要忘記不用Redux就可以應(yīng)用Redux中的思想。例如，考慮具有組件內(nèi)部 state 的React組件:

import React, { Component } from "react";

class Counter extends Component {
  state = { value: 0 };

  increment = () => {
    this.setState(prevState => ({
      value: prevState.value + 1
    }));
  };

  decrement = () => {
    this.setState(prevState => ({
      value: prevState.value - 1
    }));
  };
  
  render() {
    return (
      
        {this.state.value}
        
        
      
    )
  }
}

認(rèn)真重申一遍，看樣子一切都很完美。

組件內(nèi)部 state 沒毛病

Redux提供的折衷方案是增加間接性，將“發(fā)生的事情”與“事情如何變化”分開。

這總是一件好事嗎？不，這是一個折衷方案。

例如，我們可以從我們的組件中提取一個 reducer：

import React, { Component } from "react";

const counter = (state = { value: 0 }, action) => {
  switch (action.type) {
    case "INCREMENT":
      return { value: state.value + 1 };
    case "DECREMENT":
      return { value: state.value - 1 };
    default:
      return state;
  }
}

class Counter extends Component {
  state = counter(undefined, {});
  
  dispatch(action) {
    this.setState(prevState => counter(prevState, action));
  }

  increment = () => {
    this.dispatch({ type: "INCREMENT" });
  };

  decrement = () => {
    this.dispatch({ type: "DECREMENT" });
  };
  
  render() {
    return (
      
        {this.state.value}
        
        
      
    )
  }
}

注意我們?nèi)绾卧诓贿\行npm install的情況下使用Redux。哇！

你應(yīng)該對有狀態(tài)的組件做這件事嗎？可能不會。也就是說，除非你有計劃從這種額外的間接中受益。按照我們這個時代的說法，制定計劃是