Redux: нормализация состояния необходима для композиционных отношений?

Question

Как мы знаем, при сохранении данных в хранилище с избыточностью они должны быть преобразованы в нормализованное состояние.Таким образом, внедренные объекты должны быть заменены их идентификаторами и сохранены в выделенной коллекции в магазине.

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

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

Answer 1

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

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

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

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

Answer 2

Я не согласен с тем, что данные «должны быть [нормализованы]».Нормализация - это полезная структура для доступа к данным, но вы принимаете это решение.

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

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