javascript - 为什么 React Context.Provider 是必需的(或有用的)？

Question

React 有上下文的原因是允许多个兄弟组件共享一个状态数据。这是允许两个不相关的组件在共享变量中读/写的首选方法。之所以有必要，是因为 React 无法在不实际在屏幕之间传递数据的情况下轻松地将数据值提供给多个屏幕。相反，它允许每个屏幕在需要时访问数据。

所以... 实现需要创建一个组件，称为 Context.Provider 组件，然后您必须将需要访问共享数据的组件包装在 中上下文提供者。但为什么？为什么这是一个要求？ Context 旨在在层级关系不相关的组件之间共享数据，是否需要将组件置于层级结构中才能这样做？

简单地放弃使用 Context.Provider 的要求会简单 100 倍并且同样有效，简单地让 useContext 函数默认提供对设置变量的访问:

// In ctx.js
import React from 'react';
export default CTX = React.createContext({val: "value"});

// In compA.js
import CTX from './ctx.js';
import {useContext} from 'react';
function A(props) {
    var [context, setContext] = useContext(CTX);
    console.log(context); //Logs {val: 'value'};
    setContext({val: "newValue"});
}

然后，假设组件 B 在 A 之后呈现:

import CTX from './ctx.js';
import {useContext} from 'react';
function B(props) {
    var [context, setContext] = useContext(CTX);
    console.log(context); //Logs {val: 'newValue'};
}

上面的用法，如果真的有效，解决了“在不相关的组件之间共享数据”的任务，并且比要求在上下文文件中定义一个全新的组件要简单得多。这个解决方案更好，因为:1. 无需重组申请。您不需要将组件包装在提供者中。2.任何组件都可以轻松地请求任何共享状态，并且可以轻松地设置共享状态。3. 代码更少，更容易理解(一行代码用于导入，一行代码用于启动上下文)。4. 不牺牲任何东西。这种方法允许在组件之间轻松共享状态，这首先是上下文的全部原因。

我疯了吗？我们绝对需要将我们的组件包装在一个特殊的组件中以共享数据是否有正当理由？..为什么共享状态不能独立存在？好像他们选择了一个糟糕的解决方案……为什么让每个开发人员在使用共享状态之前将组件包装在另一个组件中，为什么不让开发人员在需要使用该死的共享状态时使用它而不是跳过一个箍？有人请教我。

编辑:一个答案说，使用我描述的方法，我们将无法使用单个组件访问多个上下文。那是错误的。使用我描述的方法实际上更容易:

// In context.js
export const CTX = React.createContext({val: "val"});
export const CTX2 = React.createContext({val2: "val2"});

// In app.js

function App(props) {
    const [state, setState] = useContext(CTX);
    const [state2, setState2] = userContext(CTX2);
    return (<></>);
}

简单。不需要 Context.Provider。这是在一个组件中使用多个上下文，只需要两次调用 useContext 而不是将整个应用程序包装在两个嵌套的上下文中，这是您必须使用当前 Context.Provider 方法做的事情。 .

Answer 1

伙计，答案很简单。 React 组件仅在 props 或 state 发生变化时才重新渲染。如果没有 Context.Provider，组件 React 将永远无法理解何时重新渲染子组件，因此您将拥有陈旧的、渲染受阻的组件。