Подскажите, как правильно организовать структуру хранение данных в Mobx.
Например, демострационный ToDo.
Что есть на Rest сервере:
1) tasks
2) projects
3) Каждая таска связана с проектом (project_id).
Если рассматривать ситуацию, в которой к одному серверу стучатся браузерное приложение и мобильное приложение (React Native + MobX) - то есть важно синхронизация данных и алгоритм обновления данных (когда загружать и синхронизировать на клиенте, как синхронизировать, если клиент хранить данные одного пользователя, а сервер данные всех пользоавателей, когда отправлять для синхронизации на сервере).
И собственно интересует, как правильно хранить связи таблиц в MobX?
Мне хорошо понятен принцип хранения данных и их использование на бэке c Postgres.
Но как я понимаю, на клиенте ситуация другая, потому что там нужно хранить данные для офлайн доступа + как то их синхронизировать.
Просто на заметку, все вами перечисленное, никакого отношения к mobx не имеет. mobx это всего-лишь навсего слой для работы с данными. Ему безразлично как вы их получите и преобразуете их.
twoone, Понял. Тогда вопрос в том, как хранить данные в Realm, чтобы потом их синхронизировать с сервером?
Особенно интересует вопрос работы оффлайн и привязка элементов по id. Id, который клинтом генерируется или от сервера? Если от сервера, то что делать при оффлайн?
egorkozelskij, я никогда не пользовался Realm, поэтому сказать не могу. Кроме того, я слышал, что существуют удаленные стейт-манагеры созданные на redux. То есть, обычный redux предполагает синхронизацию данных между разными компонентами на клиенте, а та библиотека рассматривает клиенты, как компоненты.
Если писать подобное самому, то использовать сокеты. Синхронизация должна быть завязана на времени. id генерирует только сервер. При создании объекта в оффлайне нужно обертывать его в объект имеющий собственный уникальный идентификатор и говорящий что он временный. Тогда сервер добавит записи в БД и вернет с его помощью id и время обратно. а там синхронизировать. Как-то так. Все зависит от предполагаемой частоты обновления с разных устройст. Если предполагается очень часто, то вообще всю логику нужно на сервере держать.
Простой