Redux Многие для многих отношений

Я пытаюсь найти хорошую структуру, чтобы создать много-много отношений в Redux. Для этого примера у нас есть изображения (которые могут иметь несколько тегов) и теги (которые могут иметь несколько изображений).Redux Многие для многих отношений

Это хороший способ структурировать его в Редуксе?

images: { 
    1: { 
     title: "A bunch of hills" 
    }, 
    2: { 
     title: "Hiking in a forest" 
    } 
}, 
tags: { 
    1: { 
     title: "landscape" 
    }, 
    2: { 
     title: "outdoors" 
    } 
}, 
imagesTags: { 
    [ 
     image: 1, 
     tag: 1 
    ], 
    [ 
     image: 1, 
     tag: 2 
    ], 
    [ 
     image: 2, 
     tag: 2 
    ] 
}

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

источник

2017-02-15 joshhunt

Я не хочу предполагать, что вам не нужно это делать, но, по моему опыту, этот тип отношений для базы данных. Вы отправляете свои изображения с помощью связанных тегов. Вы полагаетесь на API, чтобы быть источником правды и позволить вашему клиенту быть довольно глупым. Каков прецедент, требующий такого кросс-поиска на клиенте? – Samo

Справедливая точка, однако в моем случае у меня нет базы данных. Это небольшой персональный проект, и все хранится в локальном хранилище браузеров. – joshhunt

Даже если у вас есть база данных, вы не хотите, чтобы какие-то отношения были уверены, что они остаются в синхронизации? Например, если вы отправляете изображения с их тегами, что произойдет, если вы хотите загрузить страницу «Теги» ? Отправить другой запрос на сервер для получения тегов и связанных с ними изображений? Что произойдет, если вы удалите изображение из тега? Вам нужно было бы удалить его из изображений и редукторов тегов? – joshhunt

Да, это пример «нормализованного» состояния. В документах Redux включена нормализация в разделе Structuring Reducers. См. Structuring Reducers - Prerequisite Concepts, Structuring Reducers - Normalizing State Shape и Structuring Reducers - Updating Normalized Data. Кроме того, в FAQ Redux обсуждается нормализация в "How do I organize nested or duplicate data in my state?".

Помимо этого, я большой поклонник использования библиотеки Redux-ORM для управления реляционными данными в моем магазине Redux. Я написал пару сообщений, которые обсуждают, как я их использую: Practical Redux Part 1: Redux-ORM Basics и Practical Redux Part 2: Redux-ORM Concepts and Techniques. Остальная часть моего "Practical Redux" tutorial series также показывает эту библиотеку в действии.

источник

2017-02-15 18:14:59 markerikson

Прекрасное спасибо! Это [точный пример] (http://redux.js.org/docs/recipes/reducers/NormalizingStateShape.html#relationships-and-tables) того, что я искал. Я попытался найти что-то подобное, но, к сожалению, кажется, что документы находятся на довольно низком уровне. Последующий вопрос, почему таблица соединений использует идентификаторы? И немного от темы вопрос, в чем цель allIds? Я не могу придумать пример, где это было бы полезно. – joshhunt

Когда я написал страницу документа «Нормализовать состояние штата», я основывал примеры формы состояния, как это делает структуры Redux-ORM. Redux-ORM определяет эти «сквозные таблицы» для многогранных отношений, и поскольку каждая запись является технически значением для экземпляра модели, ей нужен свой собственный идентификатор. Что касается массивов ID, в то время как JS-механизмы теперь имеют довольно стандартизованный процесс для итерации по ключам в объекте, вы не должны полагаться на это, чтобы определить порядок. Сохранение массивов идентификаторов позволяет вам определить порядок для элементов. Redux-ORM использует это для поиска «всех элементов типа». – markerikson

А это имеет смысл, спасибо! – joshhunt

ответ

Смежные вопросы