Как интегрировать Redux с очень большими наборами данных и IndexedDB

У меня есть приложение, которое использует sync API для получения своих данных и требует хранения всех данных локально. Сам набор данных очень велик, и я не хочу хранить его в памяти, так как он может содержать тысячи записей. Поскольку я не думаю, что фактическая структура данных имеет значение, позвольте предположить, что я создаю почтовый клиент, который должен быть доступен в автономном режиме, и что я хочу, чтобы мой механизм хранения был IndexedDB (который является асинхронным).

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

Однако это означало бы, что мне нужно поставить под угрозу 2 вещи:

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

Есть ли какие-либо рекомендации по использованию сокращений с свойствами состояния не в памяти? То, что мне больше всего сложно оборачивать, заключается в том, что redux использует синхронные API-интерфейсы, поэтому я не могу заменить свой объект состояния объектом состояния async (если я полностью не удалю редукцию и не заменим его собственной, асинхронной реализацией и коннектором).

Я не мог найти ответ с помощью Google, но если у вас уже есть хорошие ресурсы по этому вопросу, я бы тоже хотел отметить.

UPDATE: На вопрос ответили, но он хотел дать лучшее объяснение тому, как я его реализовал, если кто-то столкнется с ним:

Основная идея состоит в том, чтобы поддерживать списки изменений как клиента, так и сервера с помощью просто сокращающих редукторов и использовать соединитель для прослушивания этих списков изменений для обновления IDB, а также для обновления сервера с изменениями клиента:

Когда клиент вносит изменения, используйте редукторы для обновления списка изменений клиента.
Когда сервер отправляет обновления, используйте редукторы для обновления списка изменений сервера.
Коннектор прослушивает сохранение, а при обновлении состояния обновляет IDB. Также поддерживайте внутренний список элементов, которые были изменены.
При обновлении сервера используйте список измененных элементов, чтобы вывести дельта из IDB и отправить серверу.
При доступе к данным используйте обычные действия, чтобы вытащить из IDB (например, с помощью сокращения),

Единственное предостережение в этом подходе состоит в том, что, поскольку реальное состояние хранится в IDB, поэтому мы теряем часть значения одного объекта состояния (а также более сложного состояния перемотки/перемотки вперед)

Ответ 1

Я думаю, что ваша первая догадка правильная. Если (!) Вы не можете хранить все в магазине, вы должны хранить меньше в магазине. Но я считаю, что я могу сделать это решение намного лучше:

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

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

Вы можете сохранить свою логику в сокращении. Просто создавайте действия, как обычно, для действий пользователя и изменений данных, получения необходимых данных и их обработки. Интерфейс по-прежнему полностью определяется пользовательскими данными, потому что у вас всегда есть информация в магазине, которая необходима, чтобы ПОЛУЧИТЬ К остальной части, когда это необходимо. Это немного конденсировано, т.е. е. вы сохраняете только общее количество сообщений или идентификаторов почтового ящика до тех пор, пока пользователь не перейдет к нему.