Question

我已经阅读了Flux文档，Redux文档，实现了Redux，构建了我自己的Connect版本，以及我自己的Flux模式版本，我发现自己对一个核心概念感到困惑，这是：

为什么必须重新呈现父组件以便从子级访问状态更改？

让我举个例子。假设我们有一个父组件呈现一个表单，以及两个表单字段元素，它们是组件。

<Form>
  <Field />
  <Field />
</Form>

每个Field都可以拥有自己的onBlur SyntheticEvent处理程序，它将更改分派给全局状态对象（这里选择状态管理无关紧要）。可以有单个对象或对象列表等。

每个Field都可以在全局状态中注册一个侦听器，只要全局状态发生变化，就会重新发送Field。这可以通过为setState()调用Field来完成。

在我假设的场景中，每个Field都可以包装在HOC中，或者渲染道具可用于为mount上的每个Field组件设置订阅，并删除unMount上的订阅。 / p>

父Form组件可以有一个处理程序，在提交Form时，要求Fields状态为true才能提交Form {1}}。

有多种方法可以为Form组件提供Fields状态所需的数据。

场景1 Form可以在全局状态中注册一个侦听器，该侦听器将导致Form更新，使用当前Field状态刷新状态中的道具。

场景2 Form可以将回调传递给Fields，以允许他们更新Blur上Form内的状态。 Form会检查此onSubmit。

场景3 允许Form按需读取全局状态。

我已经尝试了上述所有三种情况，但我无法理解为什么你会强迫Form在场景1中重新渲染，如果不需要的话。

场景2运作良好但似乎不必要的复杂性。

场景3运作良好，并且是最不复杂和最容易推理的，具有最少量的重新渲染。

所以我的问题是，我是否有理由希望Form在场景1中重新发布以更新其道具，其中包含每个Field与访问全局的状态国家按需？这里有一些我失踪的模式吗？

注意：我知道React不一定会重新渲染组件，但是，为什么甚至强迫React调和任何东西呢？这似乎是不必要的计算。

Answer 1

场景4 - 使用ref

onSubmit()
{

 if(!this.field1.status || !this.field2.status) {
   //can't submit
 }

}

render() 
{
     return (
      <Form>
        <Field ref={(f) => this.field1 = f} />
        <Field ref={(f) => this.field2 = f} />
      </Form>
     );
}

React：为什么父组件必须重新呈现以访问子状态更改？

1 个答案: