用“ setState”反应useContext

问题描述

我最近开始使用带有useContext Hook的Context React Api。 我观察到,当我们有一个状态变量时,即const someState = useState(state,setState),有些 开发人员直接在提供程序值中传递setSate,然后在子组件中调用它。 这是个好习惯吗?

不使用上下文时,必须创建一个处理程序以“访问”子组件中的setState。 我仍在使用处理函数,并将它们传递到提供程序值中,以从上下文中导入它们 在儿童中。

在上下文中传递setState是否很好?我仍然有一些疑问,因为通常您不能将setState直接传递到组件中。 我应该考虑在性能上有什么区别或其他缺点吗?

谢谢。

解决方法

如果我理解正确,则不同之处在于,一种状态是从父组件设置的,而另一种状态是从子组件设置的。 有时人们这样做是为了避免通过改变状态来渲染循环。应该没有缺点,但是使用处理程序函数是常规的方法。

,

编辑:我实际上认为我弄错了,但是我不确定。如果您编写自己的具有状态的提供程序,则我的答复对这种情况是有效的。如果您仅使用提供设置器的默认提供程序,我会同意Amel的答复。


我个人不会这样做,但这更像是一种选择。但是,像往常一样,这在很大程度上取决于您要达到的目标。

这样做的一个积极方面是,useState给出的状态设置器对于每次重新渲染始终保持相同。如果您传递一个自定义值,则应避免它经常更改,因为使用useContext监听更改的每个组件都会重新呈现。

我仍然希望通过带有状态设置的回调传递自定义对象(例如,来自useMemo以避免不必要的重发)。如果您想将来提供更多内容,则扩展起来会更容易。

这样的事情(非常简单的例子,当然这没有意义,只是为了理解):

function MyProvider({children}) {
   const [state,setState] = useState(0);
   const provided = useMemo(() => ({
       value: state,setValue: (value) => setState(value)
   },[value]);
   return <MyContext.Provider value={provided}>{children}</MyContext.Provider>;
}

在不使用上下文的情况下,无需更改代码即可进行扩展。但是,我仍然认为仅传递设置者并没有什么特别的坏处,如果那是您想要实现的目标。

相关问答

依赖报错 idea导入项目后依赖报错,解决方案:https://blog....
错误1:代码生成器依赖和mybatis依赖冲突 启动项目时报错如下...
错误1:gradle项目控制台输出为乱码 # 解决方案:https://bl...
错误还原:在查询的过程中,传入的workType为0时,该条件不起...
报错如下,gcc版本太低 ^ server.c:5346:31: 错误:‘struct...