Возврат простого JS-объекта из запомненного селектора с помощью Immutable.js

Question

Я работаю над приложением React + redux + Immutable.js + reselect. Я рассматриваю проект, в котором я использую Immutable.js в редукторах и сагах, но не хочу связывать эту библиотеку с интеллектуальными компонентами, поэтому моя презентационная часть приложения настолько чиста, насколько это возможно.

Согласно избыточной документации ваши селекторы всегда должны возвращать неизменный объект .

Моя идея состоит в том, чтобы вычислить производное состояние в селекторе повторного выбора и вернуть простой объект JS. Если я использую памятный селектор, новый объект не будет создаваться при каждом вызове, если лежащая в основе часть избыточного состояния одинакова, поэтому мой компонент не будет перерисован без необходимости.

Я знаю, что я частично заплачу с возможностью компоновки, поскольку селектор нельзя использовать в качестве входных данных для других селекторов, готовых к Immutable.js, но я получу намного более чистые интеллектуальные компоненты.

Есть ли другие недостатки такого решения?

Почему избыточная документация так сильно поощряет передачу неизменных объектов в интеллектуальные компоненты?

Answer 1

Есть ли другие недостатки такого решения?

toJS стоит дорого, и отладка приложения становится более сложной.

Почему избыточная документация так сильно поощряет передачу неизменных объектов в интеллектуальные компоненты?

1. Неизменяемые объекты проверяются глубже, чем простые Объекты. В случае проверки oldObject === newObject простые объекты будут сравниваться на глобальном уровне, тогда как oldImmutableObject === newImmutableObject сравнивается глубже. Это более эффективно для дерева рендеринга, позволяя избежать ненужных обновлений рендеринга компонентов React.

2. Легко изменить объекты с помощью вспомогательных функций. get, set и более.

3. Избегается ненужного копирования данных.

Answer 2

Есть ли другие недостатки такого решения?

toJS - дорогостоящая операция, даже если она запомнена. Аргумент, почему toJS, если вам не нужно?

Почему избыточная документация так сильно поощряет передачу неизменных объектов в интеллектуальные компоненты?

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

С учетом всего сказанного все сводится к предпочтениям и тому, где чувствуются узкие места / компромиссы в архитектуре. Если вы чувствуете, что чистое разделение перевешивает потенциальные риски / предостережения с наличием toJS в селекторе, то это правильный вызов для вашей архитектуры.

В примечании, касающемся потери компоновки в селекторе, у вас всегда могут быть два селектора: один, который возвращает неизменяемое состояние - используется для композиции селектора, и тот, который использует неизменяемый селектор состояния и вызывает toJS, где необходимо.