Redux - Зачем нормализовать?
Я пытался научиться лучше структурировать свои магазины Redux и наткнулся на этот урок Дэна.
https://egghead.io/lessons/javascript-redux-normalizing-the-state-shape#/guidelinesModal
Хотя я понимаю, как это сделать, чтобы нормализовать мои данные, я не понимаю мотивацию. В частности, у меня есть два вопроса.
-
Почему обычно достаточно простых массивов? Дэн упоминает: "В сложных приложениях у нас может быть более одного массива, и todos с одинаковыми идентификаторами в разных массивах может выйти из синхронизации". Я этого не понял, могу ли я привести пример? Единственное преимущество, которое я вижу в использовании объекта, - это повышение эффективности, поскольку нам не нужно отображать весь массив, если я хочу делегировать определенное todo другому редуктору.
-
Почему нам нужно поддерживать список allIds? Зачем поддерживать это дополнительное состояние, когда мы можем легко перечислить список всех todos и получить его?
Я знаю, что нормализует это для нас, но почему мы должны нормализовать в первую очередь? Имеет ли смысл нормализовать, даже если ответы не глубоко вложены?
Изменить 1:
Спасибо за ваш ответ, Кристофер.
Предположим, что ваше государственное дерево выглядит так
{
user: {
byId: {
1: {
id: 1,
name: 'Buy stuff'
},
2: {
id: 2,
name: 'Yeah'
}
}
},
allIds: [1, 2],
subscribedIds: [5],
}
department: {
byId: {
5: {
id: 5,
name: 'Sell Stuff'
}
},
allIds: [5],
subscribedIds: []
}
}
Я не вижу преимущества наличия объекта вместо массива здесь. Я мог бы также иметь селекторы, которые могли бы получить подписанный todo по ID из отделов, даже если это массив. По-моему, мое понимание концепции немного неполноценно. Не могли бы вы рассказать?
Ответы
Ответ 1
- "В сложных приложениях у нас может быть более одного массива, и todos с одинаковыми идентификаторами в разных массивах может выйти из синхронизации".
Например, у вас может быть TODO (например, с идентификатором 1), который, например, входит в список пользователей TODO и список "TODO отдела". И затем, если пользователь обновит ее todo, TODO также должен быть обновлен в списке "TODO отдела". Если ваши данные нормализованы, TODO будет обновляться в обоих местах (ну, действительно, будет только один экземпляр TODO, который просто упоминается из нескольких мест). Но если это не нормируется, отдел будет иметь устаревшую копию todo.
- "Зачем хранить список всех идентификаторов?"
Честно говоря, я прав. Если вы собираетесь беспокоить нормализацию, то дублирование списка типов идентификаторов, похоже, противоречит этим усилиям.
Во всяком случае, я думаю, что случай нормализации данных в React, вероятно, отражает случай нормализации данных вообще (например, в базах данных). Это немного больше усилий, но гибкость, которую он дает вам, в целом стоит того.
Кроме того, я не всегда нормализую свой код React, но я считаю, что не нормализация заканчивается тем, что делает мой код sloppier с течением времени. Я просто становлюсь менее дисциплинированным. Я думаю, это похоже на эффект разбитого окна. В ненормированном коде я просто начинаю бросать значения в места, которые они, вероятно, не должны быть просто из-за удобства.
Ответ 2
Почему нам нужно поддерживать список allIds? Зачем поддерживать это дополнительное состояние, когда мы можем легко перечислить список всех todos и получить его?
Хранение массива идентификаторов позволяет нам определить порядок для элементов. В то время как у JS-двигателей теперь есть довольно стандартизированный процесс для итерации по ключам в объекте, вы не должны полагаться на это, чтобы определить порядок.
Отвечать спасибо markerikson