Использование редукции с локальной базой данных

У меня есть автономное веб-приложение React, где все данные хранятся локально в indexedDB. Нет другого сервера, кроме файлового хостинга для статических ресурсов. Я приближаюсь к тому моменту, когда начинаю изучать использование избыточности, но я пытаюсь понять компромиссы между перемещением большего количества данных в хранилище и продолжением использования БД. Каков идиоматический способ использования локальной базы данных с избыточностью?

В настоящее время мое приложение состоит из нескольких компонентов контейнера, каждый из которых извлекает данные из базы данных в componentWillMount. Один из вариантов интеграции избыточности — оставить его в основном таким же, с той лишь разницей, что состояние сохраняется в хранилище, а данные извлекаются с помощью действий и переходников.

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

Кажется, что было бы неразумно загружать буквально всю БД в хранилище, по крайней мере, в моем случае это было бы около 10 МБ данных, а может и больше. Таким образом, у меня всегда будут по крайней мере некоторые компоненты, которым нужно будет продолжать извлекать свои данные при монтировании. Но есть подмножество данных, которое является центральным для приложения, и можно утверждать, что таблица должна быть загружена полностью (вероятно, это будет от 5000 до 10000 объектов).

Каков идиоматический способ работы с локальным хранилищем и избыточностью? Я понимаю, что асинхронная выборка в componentWillMount не является идиоматической, если ее можно избежать. Даже в тех случаях, когда состояние достаточно мало, чтобы его можно было полностью загрузить в хранилище, стоит ли отказываться от преимуществ красивого эффективного интерфейса запросов?


Изменить: я должен упомянуть: я использую Dexie, это действительно замечательная библиотека для работы с индексированной БД. Он быстрый, имеет приятный интерфейс запросов, обрабатывает миграцию и т. д. Я бы очень хотел продолжать использовать Dexie, если только нет веских причин поступать иначе.

Для справки: вот обсуждение этой темы на github Dexie. Общая форма на вынос, то есть «это зависит». Не совсем тот ответ, который я искал, поэтому я надеюсь получить больше информации, если это возможно.


person vopilif    schedule 06.07.2017    source источник
comment
github.com/rt2zz/redux-persist может быть полезен для того, что вы пытаетесь сделать   -  person sss    schedule 07.07.2017


Ответы (2)


Отвечая на это сам с тем, что я обнаружил до сих пор. Если появится лучший ответ, я буду рад отметить его принятым.

TL;DR: Это действительно зависит. Идиоматический способ сделать что-то действительно состоит в том, чтобы помещать в состояние столько, сколько это имеет смысл. Тем не менее, асинхронная выборка данных из других источников не является чем-то необычным, когда это имеет смысл. В противном случае многие приложения были бы просто непрактичными.

Дэн Абрамов руководство по яйцеголовому (даже под названием «Создание приложений React с помощью Idiomatic Redux») предполагает хранение всего состояния в хранилище и его периодическое сохранение в виде одного гигантского блоба (или соответствующего фрагмента).

Это имеет то преимущество, что вы используете хранилище избыточности как обычно, а постоянство практически прозрачно. Если ваши данные достаточно малы, где это не проблема, это здорово.

Как отметил @seanyesmunt, существует redux-persist, который в основном делает более сложную версию этого.

Конечно, вскоре после этого он переписывает учебник. для получения данных из API. На этом этапе вы можете просто притвориться, что API — это IndexedDB, на самом деле это ничем не отличается. Вы теряете некоторые преимущества избыточности, не имея полностью детерминированного состояния в целом, но во многих случаях у вас нет выбора.

В итоге я сделал то же самое, что и пример кода Dexie Redux. По сути, использование переходников для асинхронной записи в БД при определенных действиях.

person vopilif    schedule 17.07.2017
comment
наличие всего состояния в хранилище и сохранение его в виде одного гигантского блоба. Это кажется довольно странным подходом. Не было бы лучше хранить данные в более удобной/нормализованной форме в вашей базе данных, чтобы другие приложения, помимо вашего приложения для реагирования, могли их использовать? - person dcp; 02.05.2018

EDIT 2020-12-18: я рекомендую использовать dexie-react -hooks и хук useLiveQuery(). Это удивительный опыт работы, который устраняет всю сложность, связанную с этим. См. также эту запись в блоге об этом.

Мой старый ответ был таким: этот вопрос представляет для меня большой интерес, так как я работал с React и dexie для последнего проекта, в котором я участвовал. Я лично изучаю, как graphql может решить этот сценарий, но я еще учусь. Я надеюсь предоставить пример graphql/dexie. Насколько я понимаю, graphql будет действовать как сервисный уровень, а его схема (базовое хранилище) будет использовать запросы dexie, необходимые для создания более плоских и упрощенных требований к данным graphql. Для начала я рассмотрю какой-нибудь готовый к использованию образец grapql от Apollo или Facebook, и я верю, что он будет прост в использовании. Обычно я не думаю, что он масштабируется, чтобы читать всю базу данных в память. И я считаю, что запуск приложения имеет решающее значение для конечных пользователей, поэтому я очень надеюсь найти идеальную архитектуру для этого. И в настоящее время я надеюсь на Graphql.

person David Fahlander    schedule 07.07.2017