Pull to refresh

Comments 15

UFO just landed and posted this here
Официальная рекомендация из доков по реакту это избегать сайд-эффектов в конструкторе. reactjs.org/docs/react-component.html#constructor
Ну и комментарий Дэна Абрамова на эту тему. Вообще довольно туманное объяснение.
(https://github.com/reactjs/reactjs.org/issues/302)

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.
Если делать те же ajax-запросы в конструкторе или же в componentWillMount, то мы не исключаем появление каких-либо ошибок, вследтвие чего компонент не будет отрисован. И в данном случае будут отправлены лишние запросы. Поэтому и рекомендуется все сайд-действия производить в componentDidMount
UFO just landed and posted this here

А чего вы пытаетесь достичь путем их вызова в конструкторе?


Как пишет Дэн в своем комментарии, вы все равно не получите ускорения, потому асинхронный запрос в любом случае закончится уже после монтирования и окончания изначального рендера и никакой выгоды вы не получите.


Зато огребете проблем, если React захочет создать инстанс вашего компонента, а затем не станет его монтировать. В этом случае асинхронная операция уйдет в никуда.

UFO just landed and posted this here
Вы неверно перевели его комментарий, он нигде не писал что все равно не будет ускорения.

А как еще вот это понимать?


So the difference between firing it earlier and later is often negligible.

разница если и есть, то пренебрежимо мала, экономия на спичках получается.


в каких случаях React захочет создать инстанс но не станет монтировать

Это случится в будущих релизах:


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
Про монтирование — в тестах например. Просто если напишите в коде вызов компонентов до их рендеринга. В общем везде, где используете компонент, ещё не начав рендерить его в дом или вообще там, где дом нет.
componentDidMount…
НЕ ДЕЛАЙТЕ:
• Не вызывайте this.setState т.к. это будет вызывать циклическую перерисовку.

Это надо понимать ошибка?
Да, спасибо. Убрал слово циклическая.
После асинхронного вызова я кладу данные в state через this.setState, и вот тут мне кажется можно запутаться, т.к вроде нельзя делать this.setState в componentDidMount
Может лучше уточнить…
Не вызывайте this.setState синхронно или в синхронных функциях т.к. это вызовет перерисовку

Промахнулся ответом

Ну this.setState в любом случае перерисовку вызовет. Но в целом да, имеется ввиду вызов setState в самом методе, а не в коллбеке. В исходной статье есть такой же комментарий.

Есть такая хорошая схема по тому, где можно юзать setState, а где нельзя.
Единственно, что с выходом 16.3 устарела немного.
Очень просто и понятно написано. СПасибо автору
Sign up to leave a comment.

Articles