javascript - 我应该如何替换 componentWillMount()？

Question

我正在使用 React.js，如您所知，componentWillMount() 将被弃用。我想替换我的 componentWillMount。

我要把它的逻辑移到constructor中。在 componentWillMount 和 constructor 中执行一些逻辑有什么不同吗？

例如，

之前

class Hello extends React.Component {
    componentWillMount() {
      doSomething();
    }

  render() {
    return <div>{this.state.name} </div>
  }
}

之后

class Hello extends React.Component {
    constructor(props) {
      super(props);

      doSomething();
    }

  render() {
    return <div>{this.state.name} </div>
  }
}

另外，doSomething 为setState 时，constructor 和public prop 中设置state 有什么不同吗？

在构造函数中

constructor(props) {
  super(props);

  this.state = { foo: 1 };
}

在公共(public) Prop 中

state = { foo: 1 };

Answer 1

constructor 不是执行某些操作的正确位置。因为它将保留其他操作直到它完成。

componentDidMount 是正确的选择，因为它是一个异步函数，因此操作在后台运行并且不会妨碍 UI 呈现。

---

这是一个 list您可以选择何时在 constructor 和 componentDidMount 之间使用:

构造函数

做:

• 初始化状态
• 绑定(bind)事件处理器

如果您不初始化状态并且不绑定(bind)方法，则不需要实现构造函数。

不要:

避免引入任何副作用或订阅。不要在构造函数中使用 setState() 来设置状态。

componentDidMount

做:

• 需要DOM节点的初始化
• 从远程端点加载数据(在何处实例化网络请求)
• 设置任何订阅(不要忘记在 componentWillUnmount() 中取消订阅)

---

您可能也对read the comment感兴趣来自 React 的创造者 Dan Abramov:

I won't like to wait for the component to be mounted to dispatch an ajax call to fulfill the component data dependencies. I would like to do it as soon as possible, like in the constructor, not even in componentWillMount.

If it's an async request, it won't be fulfilled by the time the component mounts anyway, regardless of where you fire it. This is because JS is single threaded, and the network request can't "come back" and be handled while we are still rendering. So the difference between firing it earlier and later is often negligible.

You're right that it matters in some rare cases though and for those cases it might make sense to break the recommendation. But you should be extra cautious as state can update before mounting, and if your data depends on state, you might have to refetch in that case. In other words: when in doubt, do it in componentDidMount.

The specific recommendation to avoid side effects in the constructor and Will* lifecycles is related to the changes we are making to allow rendering to be asynchronous and interruptible (in part to support use cases like this better). We are still figuring out the exact semantics of how it should work, so at the moment our recommendations are more conservative. As we use async rendering more in production we will provide a more specific guidance as to where to fire the requests without sacrificing either efficiency or correctness. But for now providing a clear migration path to async rendering (and thus being more conservative in our recommendations) is more important.

---

如需更多兴趣，您还可以visit this post .