关于前端:React-4-种状态类型及-N-种状态管理

React 是一个视图层框架，其核心思想是 UI = f(state)，即「UI 是 state 的投影」，state 自上而下流动，整个 React 组件树由 state 驱动。当一个 React 应用程序足够简单，组件嵌套足够深时，组件树中的状态流动会变得难以管制（例如你如何跟踪父节点的 state 流动到叶子节点时产生的变动）。这时咱们就须要对 state 进行治理，在进行状态治理的同时，还须要分清 React 利用中有哪些状态类型，不便制订出最适宜的状态治理计划。

状态类型

React 应用程序状态从宏观意义上讲能够分为两类：

1. 客户端状态 Client State：少数用于管制客户端的 UI 展现，如下文将介绍到的 Local state、Feature state、Application state 都属于客户端状态。
2. 服务端状态 Server State：客户端通过异步申请取得的数据。

本地状态 – Local state

仅存在于单个组件中的状态，咱们能够称之为「本地」或「UI」状态。

通常它能够帮忙咱们治理用户界面交互，例如显示和暗藏内容或启用和禁用按钮，它还常常在咱们期待时管制渲染的内容。思考以下示例：

function Text() {const [viewMore, setViewMore] = useState(false);
  return (
    <Fragment>
      <p>
        React makes it painless to create interactive UIs. 
        {
          viewMore && <span>
            Design simple views for each state in your application.
          </span>
        }
      </p>
      <button onClick={() => setViewMore(true)}>read more</button>
    </Fragment>
  )
}

viewMore 是一种仅对这个特定组件有意义的状态，它的作用是仅管制此处文本的可见性。

在此示例中，viewMore 对应用程序的其余组件对都是没用的，因而，您不用将此状态透露到 Text 组件之外。

特色状态 – Feature state

组合两个或多个组件，这些组件须要晓得雷同的信息，咱们将这种状态定义为「特色」状态。

能够说，每一个非本地性的状态都属于这一类。然而，并非每个特色状态都是雷同的，咱们将在本文中进一步理解这一点。

特色状态的一个很好的例子是表单状态，它看起来有点像下面形容的 UI 状态，但它联合了多个输出，治理多个组件。

import {useState} from "react";
const Skill = ({onChange}) => (
  <label>
    技能:
    <input type="text" onChange={(e) => onChange(e.target.value)} />
  </label>
);
const Years = ({onChange}) => (
  <label>
    工龄:
    <input type="text" onChange={(e) => onChange(e.target.value)} />
  </label>
);
 
export default function Form() {const [skill, setSkill] = useState("");
  const [years, setYears] = useState("");
 
  const isFormReady = skill !== ""&& years !=="";
  return (<form onSubmit={() => alert("提及胜利")}>
      <Skill onChange={setSkill} /> <br />
      <Years onChange={setYears} />
      <button disabled={!isFormReady}>submit</button>
    </form>
  );
}

这里咱们有一个 Form 表单，它蕴含两个字段 skill 和 years，默认状况下，Form 表单的提交按钮处于禁用状态，仅当两个输出都有值时该按钮才变为启用状态，请留神 skill 和 years 都是必须的，以便咱们能够计算 isFormReady 的值。Form 是实现此类逻辑的最佳场合，因为它蕴含了所有相关联的元素。

此示例体现了特色状态和利用状态之间的一个界线，在这里也能够应用 Redux 进行状态治理，然而这不是一种好的做法， 咱们应该在它被晋升并成为应用程序状态之前更早地辨认特色状态 。

利用状态 – Application state

应用程序状态是疏导用户整体体验的状态，这可能是受权状态、配置文件数据或全局款式主题。 在应用程序的任何中央都可能须要它。上面是一个简略的示例：

import React, {useContext, useState} from "react";
const ThemeContext = React.createContext();
const Theme = ({onChange}) => {const { theme} = useContext(ThemeContext);
  return `Theme: ${theme}`;
}
const ThemeSelector = () => {const { theme, toggleTheme} = useContext(ThemeContext);
  return (<select value={theme} onChange={toggleTheme}>
      <option value="light">light</option>
      <option value="dark">dark</option>
    </select>
  );
}
export default function App() {const [theme, setTheme] = useState("light");
  const toggleTheme = () => setTheme(theme === "light" ? "dark" : "light");
  const themeStyle = {background: theme === "light" ? "#fff" : "#b9b9b9"};
  return (<ThemeContext.Provider value={{ theme, toggleTheme}}>
      <div className="App">
        <header style={themeStyle}>
          <Theme />
        </header>
        <footer style={themeStyle}>
          <ThemeSelector />
        </footer>
      </div>
    </ThemeContext.Provider>
  );
}

这个例子中，有一个页头和一个页脚，他们都须要晓得以后应用程序的主题。咱们通过应用 Context API 将 theme 设置为利用状态，这样做的目标以便于 Theme 和 ThemeSelector 也能轻松的拜访（它们也须要拜访 theme，但它们有可能嵌套于其余组件之中）。

如果某些属性许多组件都须要，并且可能须要从近程组件进行更新，那么咱们可能必须将其设置为应用程序状态。

服务器状态 – Server state

服务器状态能够了解为接口状态，服务端状态有以下特点：存储在远端，本地无奈间接管制、须要异步 API 来查问和更新、可能在不知情的状况下，被另一个申请方更改了数据，导致数据不同步等。

现有的状态治理库（如 Mobx、Redux 等 ) 实用于治理客户端状态，但它们并不关怀客户端是如何异步申请远端数据的，所以他们并不适宜解决异步的、来自服务端的状态。

要辨认服务器状态，您必须思考数据更改的频率以及这些数据的起源。 如果它或多或少是动态的，那么咱们应该防止从服务端获取，只需将其存储到客户端并将其作为全局变量传递。

状态治理

随着 React 生态一直壮大，社区中提供了多种形式来解决状态治理，有基于 Flux 思维的 Redux、Zustand 以及 React 自带的 useReducer + Context；有基于原子化的 Recoil、Jotail 等；还有响应式计划的代表 Mobx，在这里不过多针对介绍，咱们来理解一些最罕用的。

Hooks 是状态治理的次要机制

useState 或 useReducer 是大多数人用来治理本地状态的形式，useState 实际上是 React 中从新渲染的次要机制，这也是为什么大多数状态治理库都在底层应用它的起因。如果深入研究，你会发现这些不同的第三方库提供的 Custom Hooks 都依赖于默认的 useState、useReducer 和 useffect，上面是官网提供的一个 useReducer 的简略示例：

const initialState = {count: 0};
 
function reducer(state, action) {switch (action.type) {
    case 'increment':
      return {count: state.count + 1};
    case 'decrement':
      return {count: state.count - 1};
    default:
      throw new Error();}
}
 
function Counter() {const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <>
      Count: {state.count}
      <button onClick={() => dispatch({type: 'decrement'})}>-</button>
      <button onClick={() => dispatch({type: 'increment'})}>+</button>
    </>
  );
}

状态晋升 – Lifting State Up

在 React 中，将多个组件中须要共享的 state 向上挪动到它们的最近独特父组件中，便可实现共享 state，这就是所谓的「状态晋升」。

回顾一下本文结尾的 view-more 示例（本地状态来管制文本的可见性）。然而，如果有一个新的要求，咱们有一个全局的「开展文本」按钮，而后咱们必须把这个状态晋升，而后通过 props 传递上来。

// viewMore 是一个 local state
function Component() {const [viewMore, setViewMore] = useState(false);
  return (
    <Fragment>
      <p>Text... {viewMore && <span>More text ...</span>}</p>
      <button onClick={() => setViewMore(true)}>read more</button>
    </Fragment>
  );
}
 
// 将 viewMore 晋升为组件的 feature state
function Component({viewMore}) {
  return (<p>Text... { viewMore && <span>More text ...</span>}</p>
  );
}

当您看到一个部分状态变量变成一个 props 时，咱们就能够视其为状态晋升。 这种形式的须要留神在 prop drilling 方面的找到均衡，您也不心愿有许多只是负责将 props 传递给他们子组件的「中间人」组件。

应用 Context API

Context API 提供了一种通过组件树传递数据的办法，而无需在每个级别手动向下传递 props。

在典型的 React 应用程序中，数据通过 props 自上而下（父级到子级）传递，但这种做法对于某些类型的 props 而言是极其繁琐的（例如：地区偏好，UI 主题），这些属性是应用程序中许多组件都须要的。Context 提供了一种在组件之间共享此类值的形式，而不用显式地通过组件树的逐层传递 props。

Context 设计目标是为了共享那些对于一个组件树而言是「全局」的数据，例如以后认证的用户、主题或首选语言，因而 Context 次要利用于利用状态的治理（见利用状态示例）。

如果你只是想防止层层传递一些属性，组件组合（component composition）有时候是一个比 context 更好的解决方案。

组合模式 – Composition mode

Context API 适宜治理利用状态，如果想防止 Props Drilling 等问题，能够采纳组合模式。组合是一种通过将各组件联结在一起以创立更大组件的形式，组合不仅具备多变的灵活性和可重用性，还具备繁多职责的个性，组合也是 React 的外围。看一个官网的示例：

function SplitPane(props) {
  return (
    <div className="SplitPane">
      <div className="SplitPane-left">
        {props.left}
      </div>
      <div className="SplitPane-right">
        {props.right}
      </div>
    </div>
  );
}
 
function App() {
  return (
    <SplitPane
      left={<Contacts />}
      right={<Chat />} />
  );
}

示例中没有应用 children，而是自行约定将 Contacts 和 Chat 两个组件通过 props.left/props.right 传入，被传递的组件同父组件组成了更加简单的组件，尽管被组合在一起，但各个成员组件都具备繁多职责。

client-server 形式

这种形式体现在 Apollo 和 ReactQuery 中，基本上都是在应用程序中增加一个 layer/client 并由其负责从内部源申请 / 缓存数据。

它们带有一些不错的 hooks，对于客户端来说，这种形式看起来很像应用本地状态，它打消了数据存储和获取的繁杂性。上面是 Apollo 和 ReactQuery 的简略示例：

// Apollo 
import {useQuery, gql} from '@apollo/client';
 
// 在这个例子中，咱们应用了 GraphQL
const EXCHANGE_RATES = gql`
  query GetExchangeRates {rates(currency: "USD") {
      currency
      rate
    }
  }
`;
 
function ExchangeRates() {const { loading, error, data} = useQuery(EXCHANGE_RATES);
 
  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error :(</p>;
 
  return data.rates.map(({currency, rate}) => (<div key={currency}>
      <p>
        {currency}: {rate}
      </p>
    </div>
  ));
}

// ReactQuery
import React from "react";
import ReactDOM from "react-dom";
import {QueryClient, QueryClientProvider, useQuery} from "react-query";
 
const queryClient = new QueryClient();
 
export default function App() {
  return (<QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  );
}
 
function Example() {const { isLoading, error, data, isFetching} = useQuery("repoData", () =>
    fetch("https://api.github.com/repos/tannerlinsley/react-query").then((res) => res.json())
  );
 
  if (isLoading) return "Loading...";
  if (error) return "An error has occurred:" + error.message;
 
  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.description}</p>
      <strong>👀 {data.subscribers_count}</strong>{" "}
      <strong>✨ {data.stargazers_count}</strong>{" "}
      <strong>🍴 {data.forks_count}</strong>
      <div>{isFetching ? "Updating..." : ""}</div>
    </div>
  );
}
 
const rootElement = document.getElementById("root");
ReactDOM.render(<App />, rootElement);

从例子中咱们发现，前端负责指定如何获取数据，其余的都取决于 Apollo/ReactQuery 客户端，包含前端须要的 loading 和一个 error 两种状态都由后端提供并治理。这使得前端领有一个状态，但实际上容许在后端治理该状态，是一种乏味的联合。

论断

状态治理很简单，状态治理没有最好的计划，只有最合适的计划。

对于第三方状态治理库举荐浏览 56 个 NPM 包解决 16 个 React 问题 里的大节。

参考：
https://krasimirtsonev.com/bl…
https://www.sytone.me/b-syste…