%
ну у нас было время подумать да )
Size: a a a
2020 March 19
%
но! у нас нет бэкенда (та-да), то есть мы не валидируем состояние - оно единственное верное на устройстве пользвоателя
%
могу кинуть ссылку
VA
могу кинуть ссылку
Было бы здорово! Спасибо!
%
%
валидировать состояние я бы на вашем месте не стал, есть опыт работы с Graphql + Relay и очень положительный, когда стейт один единственный и он пришел из Graphql.
%
основные затыки это с валидацией состояния и его актуализацией
VA
Нам надо хранить довольно много пользовательских данных чтобы приложение работало в офлайне. При переходе в онлайн, данные синхронизируются с беком. Синк мы по сути сделали, так чтобы не бегать по всем данным. Поэтому с этим вроде проблем не должно быть. Меня больше волнует UI. Нет ли проблем в проверке всяких флагов, которые обычно очень близко в стейте и доступ к ним синхронный.
VP
У нас просто сейчас такая ситуация что приходится тащить довольно много данных и начались проблемы с памятью и персистом. Логично переместить большие данные в БД, но не очень хочется разделять логику работы с данными, поэтому думаем над тем чтобы перенести в бд весь стейт и работать с ними напрямую.
Рефакторинг очень большой, поэтому хотелось бы узнать заранее о подводных камнях.
Рефакторинг очень большой, поэтому хотелось бы узнать заранее о подводных камнях.
если я правильно понимаю, у вас redux + redux-persist.
а вы не пробовали хранилище персиста поменять? Мы в своё время съехали с async storage на realm причём в варианте когда отдельно от redux-persist остальное хранение организовали там же в realm.
99,9 % что что-то похожее провернуть можно, "горячие" данные + UI state в redux+persist, всё остальное в обход него в той же БД держать.
а вы не пробовали хранилище персиста поменять? Мы в своё время съехали с async storage на realm причём в варианте когда отдельно от redux-persist остальное хранение организовали там же в realm.
99,9 % что что-то похожее провернуть можно, "горячие" данные + UI state в redux+persist, всё остальное в обход него в той же БД держать.
%
Watermelon имеет sync и можно написать правила синхронизации со своим бэкендом
%
Но он на столько же хорош, на сколько неудобен
%
realm и firestore хороши если свой бэкенд тоже ходит в них, а не синхронизация между realm/firestore + postgres
VP
realm и firestore хороши если свой бэкенд тоже ходит в них, а не синхронизация между realm/firestore + postgres
да, синхронизация с бэком у нас своя была.
AE
firestore так себе история. Не берите ) Лучше свой бек
VA
если я правильно понимаю, у вас redux + redux-persist.
а вы не пробовали хранилище персиста поменять? Мы в своё время съехали с async storage на realm причём в варианте когда отдельно от redux-persist остальное хранение организовали там же в realm.
99,9 % что что-то похожее провернуть можно, "горячие" данные + UI state в redux+persist, всё остальное в обход него в той же БД держать.
а вы не пробовали хранилище персиста поменять? Мы в своё время съехали с async storage на realm причём в варианте когда отдельно от redux-persist остальное хранение организовали там же в realm.
99,9 % что что-то похожее провернуть можно, "горячие" данные + UI state в redux+persist, всё остальное в обход него в той же БД держать.
Да, мы уже поменяли хранилище, но это не решает большой объем данных в памяти, что крашит приложение на телефонах с небольшой оперативной памятью. Ну И время на запись персиста не маленькое, если быстро убить приложение, то часть данных теряется.
А по последнему. Вот как раз думаю чтобы не было отдельной логики в обход. Если есть сложности, то скорее всего так и придется часть в редаксе хранить, а часть в бд брать
А по последнему. Вот как раз думаю чтобы не было отдельной логики в обход. Если есть сложности, то скорее всего так и придется часть в редаксе хранить, а часть в бд брать
%
firestore так себе история. Не берите ) Лучше свой бек
он позволяет быстро проверять гипотезы и выпускать приложения с обновлениями в реальном времени, аналитикой и авторизацией почти во всех сервисах за 2-4 недели. Свой бэк так не позволяет + нужен бэкенд разработчик (накладненько). Потому если вам MVP - firebase один из лучших инструментов, если долго и хорошо, да еще и удобно - свой бэкенд.
AE
он позволяет быстро проверять гипотезы и выпускать приложения с обновлениями в реальном времени, аналитикой и авторизацией почти во всех сервисах за 2-4 недели. Свой бэк так не позволяет + нужен бэкенд разработчик (накладненько). Потому если вам MVP - firebase один из лучших инструментов, если долго и хорошо, да еще и удобно - свой бэкенд.
И быть готовым хотя бы морально переписать после проверки гипотезы
%
A
Как сделать редирект на другую страницу так, чтобы сработал ComponentDidMount ?
A
"react-navigation": "^4.0.10"