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

Question

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

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

Так что это оставляет меня три вопроса:

1. Что такое Реагировать способ для обработки изменений URL-адресов, которые не требуют меняющихся компонентов?
2. Что касается изменений URL-адресов, которые добавляют или изменяют определенные компоненты?
3. Должны ли магазины нести ответственность за инициирование событий маршрутизации?

Answer 1

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

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

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

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

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

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

Свобода быть в состоянии сделать это является одной из основных причин, которые заставляют React awesome.

Это классический случай «преждевременной оптимизации - это корень всего зла».

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

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

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

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

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