Реагируйте способом на маршрут без рендеринга

Итак, у меня есть простое приложение React/Flux, использующее маршрутизатор магистрали. У меня есть случай, когда пользователь создает объект, и путь обновляется от /object/new до /object/:id. Однако нет необходимости повторно визуализировать страницу, поскольку компонент является тем же самым, и из-за связанного обновления хранилища после возврата вызова ajax-create он обновляет себя.

В настоящее время я только что исправил маршрутизатор, чтобы предоставить метод, который просто обновляет url-адрес и фактически не попадает в метод, зависящий от маршрута. Этот это выглядит банально, и на самом деле не касается случаев, когда некоторые компоненты (например, виджет) должны быть добавлены/удалены (по крайней мере, это снимает ответственность за знание, какие компоненты должны быть отрисованы из маршрутизатора), но основной пользовательский интерфейс не должен быть повторно отрисован.

Таким образом, у меня остается три вопроса:
  1. каков способ React для обработки изменений url, которые не требуют изменения компонентов?
  2. Как насчет изменений url, которые только добавляют / изменяют определенные компоненты?
  3. должны ли магазины отвечать за инициирование событий маршрутизации?
1 6
javascript reactjs reactjs-flux url-routing

1 ответ:

Одно из главных ценностных предложений React заключается в том, что рендеринг очень и очень дешев.

Это означает, что вы можете перепрофилировать чрезмерно без негативных последствий. Это полный 180 от Backbone, где рендеринг очень дорог, что приводит к логике, которую вы ищете, а именно, как избежать рендеринга.

Под капотом React делает эту проверку для вас, разделяя виртуальный DOM с DOM. Другими словами: когда вы используете функцию exposed render в React, вы на самом деле не скорее, вы просто описываете новое состояние DOM с помощью Javascript.

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

Это дает вам свободу полностью "рендерить", даже если на самом деле меняется очень мало вещей в вашем приложении.

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

Свободу, чтобы быть в состоянии сделать это одна из главных причин, которая заставляет реагировать удивительным.

Это классический случай "преждевременная оптимизация-корень всех зол".

Например: я иногда глобально переназначаю всю иерархию DOM на mouseMove события, и нет никакого влияния на производительность наблюдаемого.

Как общее правило, думайте о повторном запуске как об операции с нулевыми затратами. Теперь у вас могут быть некоторые дорогостоящие операции в ваших компонентах React. Если это так, вы можете использовать методы жизненного цикла React, чтобы сделать это по требованию. Особенно обратите внимание на shouldComponentUpdate, componentWillReceiveProps и componentWillUpdate.

Если вы используете Flux и придерживаетесь неизменность парадигмы, вы можете сделать очень дешевые референсные проверки равенства государства и реквизита, чтобы делать работу по требованию. С помощью этого вы можете улучшить производительность.

С помощью методаshouldComponentUpdate можно предотвратить вызов рендеринга, если он требует слишком больших вычислительных мощностей. Однако я сделал бы это только в том случае, если бы это дало улучшенную производительность из-за дорогостоящей операции, которую вы реализовали самостоятельно.

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

11