Подтвердить что ты не робот

Redux - Зачем нормализовать?

Я пытался научиться лучше структурировать свои магазины Redux и наткнулся на этот урок Дэна.

https://egghead.io/lessons/javascript-redux-normalizing-the-state-shape#/guidelinesModal

Хотя я понимаю, как это сделать, чтобы нормализовать мои данные, я не понимаю мотивацию. В частности, у меня есть два вопроса.

  1. Почему обычно достаточно простых массивов? Дэн упоминает: "В сложных приложениях у нас может быть более одного массива, и todos с одинаковыми идентификаторами в разных массивах может выйти из синхронизации". Я этого не понял, могу ли я привести пример? Единственное преимущество, которое я вижу в использовании объекта, - это повышение эффективности, поскольку нам не нужно отображать весь массив, если я хочу делегировать определенное todo другому редуктору.

  2. Почему нам нужно поддерживать список 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 из отделов, даже если это массив. По-моему, мое понимание концепции немного неполноценно. Не могли бы вы рассказать?

4b9b3361

Ответ 1

  1. "В сложных приложениях у нас может быть более одного массива, и todos с одинаковыми идентификаторами в разных массивах может выйти из синхронизации".

Например, у вас может быть TODO (например, с идентификатором 1), который, например, входит в список пользователей TODO и список "TODO отдела". И затем, если пользователь обновит ее todo, TODO также должен быть обновлен в списке "TODO отдела". Если ваши данные нормализованы, TODO будет обновляться в обоих местах (ну, действительно, будет только один экземпляр TODO, который просто упоминается из нескольких мест). Но если это не нормируется, отдел будет иметь устаревшую копию todo.

  1. "Зачем хранить список всех идентификаторов?"

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

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

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

Ответ 2

Почему нам нужно поддерживать список allIds? Зачем поддерживать это дополнительное состояние, когда мы можем легко перечислить список всех todos и получить его?

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

Отвечать спасибо markerikson