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

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

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

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

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

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

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


reactjs javascript redux reselect immutable.js
person jedzej    schedule 10.05.2018    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

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

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

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

person jwinn    schedule 15.11.2018

arrow_upward
0
arrow_downward

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

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

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

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

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

  3. Исключается ненужное копирование данных.

person Aditya Gururaja Rao Karnam    schedule 15.11.2018