Я сейчас не использую редакс, но в те времена когда использовал я хранил чисто хеш таблиц с хешем айдишников и объектов без отдельного массива айдишников. И у меня был только один редюсер который автоматически обрабатывал все экшины для всех таблиц. То есть вместо ADD_USER я пишу dispatch({type: 'add', table: 'user', record: {...}}) и также с обновлением - dispatch({type: 'update', table: 'user', recordId: 123, mutation: {....}}) и третий экшин у меня был dispatch({type: 'delete', table: 'user', recordId: 123}). Больше кастомных экшинов не было. А один единственный редюсер перехватывает эти три вида действий - add, update, delete и расфасовывает по айдишникам объекты в состоянии и получаем вот такое состояние { users: { 1: {id: '1', name: 'user1', boards: ['1','2','3']}, 2: {id: '2', name: 'user2', boards: ['2','3','4']}, } boards: { 1: {id: '1', title: 'board1',user: '1',posts: ['1','2','3']}, 2: {id: '2', title: 'board2',user: '2',posts: ['2','3','4']}, } posts: { 1: {...} 2: {...} } } То есть у нас данные в полностью нормализированном состоянии и мы во всем приложении диспатчим всего три типа экшинов - add, update, delete, передавая параметром имя таблицы, и таким образом у нас один редюсер автоматически обрабывает все за нас и мы больше не пишем редюсеры и экшины на каждый чих

Каждый экшн должен быть атомарным, то есть желательно не допускать некогерентного состояния между ними изначально

Каждый редюсер может реагировать на любой экшн абсолютно по своему, можно отталкиваться от этого и сразу писать когерентные нормализованные данные

На самом деле 90% всего это CRUD, и вполне естественно что появляются коллекции с универсальными экшенами. Богдан судя по всему делал все с этой мыслью.

а что значит когерентное состояние между редьюсерами?

Вот есть кстати красивый нормализованный стейт. Как его очищать от лишних данных?

накой черт делать что-то реляционное?)

накой черт делать что-то реляционное?)

Не вносить их. В моём примере выше лишними данными является поле id в объекте, потому что оно выностится за его пределы. Поэтому редюсер, который отвечает за сохранение только самого объекта просто кладёт объект в стор, убирая из него ставшее ненужным поле

Не вносить их. В моём примере выше лишними данными является поле id в объекте, потому что оно выностится за его пределы. Поэтому редюсер, который отвечает за сохранение только самого объекта просто кладёт объект в стор, убирая из него ставшее ненужным поле

а как с чистой вложенностью моделировать дерево в редаксе? тебе нужно обновить объект на 100-ом уровне вложенности - тебе с редаксом нужно будет вернуть новые объекты всех родителей всех 99 уровней вверх а это будет тормозить

Ты не понял. Кейс что данные когда-то показывались, легли в коллекцию. Потом перестали показываться. И может быть никогда больше не будут показываться. Но место у тебя уже занимают

redux против вложенности

Ну на одной страницы они нужны на другой уже нет тип данных тот же

то есть при переходе на какую-то страницу мы можем удалить часть данных? Тогда редюсер, срабатывающий при переходе же

Да но не хотелось бы вот прямо на переходе удалять потому как это типа кэш между делом

как понять что данные не показываются уже никем и их можно вытеснить?

Эта проблема лежит вне redux, разве нет? Редакс может эффективно управлять удалением данных, но алгоритм видимости не должен быть возложен на стейт

WeakMap

Подскажите пакет в npm для русификации других пакетов!

Эта проблема лежит вне redux, разве нет? Редакс может эффективно управлять удалением данных, но алгоритм видимости не должен быть возложен на стейт

ага, может быть либо вложенность 2, либо 100. Иначе прям никак - -

находил кто нибудь https://www.udemy.com/the-complete-react-native-and-redux-course/ где скачать? от Stephen Grider

Соотвественно возникает необходимость в понимании что сейчас не показывается и требуется стратегия вытеснения из кеша

"Проблем в IT две: инвалидация кэша и именование переменных"

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

Это же невероятно громадный объём какой-то