« Rev
@reactnative_ru   423
Fwd »


Dima
Ну например данных может не очень много, но бывают сценарии когда в одном объекте заполняется список других объектов, содержащих 7-8 полей и этот список может вырасти где то до 200 элеменнтов, может и больше
будет допустим 200кб, это еще ок. Плюс тут вопрос как персистить глобальный стейт. Он может быть ленивым (список подгружаться по мере скролла), другой вопрос что low level детали всего этого нужно самому делать
Dima
я просто сейчас тоже в раздумьях, в переписывании проекта где Realm использовался активно, но без его основных фишек
Dima
сейчас делаю экстремальную нагрузку, чтобы посмотреть что будет на старых андроидах когда много сериализации/десериализации, сложных селекторах и т.д.
Alexey
Да у меня вроде тоже без особых фишек. Я кстати тему про глобальный стейт вообще понять не могу) Читал про Redux, так и не понял его плюсы. В итоге юзаю mobx и для каждого экрана делаю свой MVVM, прекрасно работает и схожесть с нативом и нет заморочек с глобальным стейтом
Alexey
Может я чего не понимаю и в Redux-е реально есть кайф? Если кто знает, расскажите пожалуйста)
Dima
mobx тоже наверное норм. Тут скорее про то что легко отследить все изменения стейта в разных частях и договоренность где он меняется. В моем проекте в Realm писалось много где, очень сложно что-то либо менять. Т.к. там достаточно myObject.property = value сделать внутри .write().
Alexey
Ну просто это глобальное состояние по мне так нарушает SOLID, получается что все знают обо всех, это же вроде не клево)
Dima
а после того как изменил, нужно еще перерендерить, и нужно всех причастных для этого затронуть, а когда у тебя компонент просто функция от глобального стейта через коннектор, ты спокоен
Dima
они не знают, т.к. ты не пишешь globalState.some.nested.key, а используешь селектор условный getMyKey(globalState)
Dima
и так же не могут globalState.some.nested.key = 123 сделать, только вызывать экшен "измени-ка". В Realm большой соблазн на месте и поменять
Alexey
Ну все же Realm это база. То есть если надо сохранить данные надолго (после перезагрузки приложения) то стэйт уже не подойдет
Alexey
И вообще реалм у меня играет только роль хранилища
Alexey
Узнать бы как его еще тестировать можно, если вообще можо)
Aleksei
Ну просто это глобальное состояние по мне так нарушает SOLID, получается что все знают обо всех, это же вроде не клево)
просто надо стейт рассматривать не как сущность, а как интерфейс, там же просто pojo, тупо данные, нигде ниче не нарушается
Alexey
А кто нибудь пишет код в RN с закосом под Clean Architecture?
Aleksei
я кстати так и не понял что конкретно под clean architecture понимают, много читал но так и не понял)
Alexey
Ну разделение на слои (представление - юзкейсы - бизнесс логика, вроде так). Попытка абстрагировать слои различного уровня друг от друга. Допустим слой бизнесс логики сделать таким, чтобы он был полностью unit тестируемым. Убрать зависимость от выбранного способа хранения данны, от вида базы, ну и так далее
Alexey
когда на каждом слое представления используется своя независимая модель данных
Dima
Ну все же Realm это база. То есть если надо сохранить данные надолго (после перезагрузки приложения) то стэйт уже не подойдет
AsyncStorage сериализуется в файл, просто и понятно. Так что если стейт простой и небольшой, то можно убрать значительный оверхед на размер бинарников (а на андроиде еще и dex). Для 99% приложений хватает.
Aleksei
ну я всегда так делаю, у меня экшены в редаксе только сервисы и дергают где вся БЛ уже
Dima
например Realm сломал gradle для меня, ломал юнит-тесты, с обновлением минорной версии была проблема, в общем постоянно вылезает какой-нибудь косяк. Стоит того только если реально нужна локальная база, вот пытаюсь найти эту границу
Dima
опять же нет в Expo 🙂
Aleksei
Дим, а ты сериализуешь только при выходе или всегда?
Aleksei
интересен то кейс когда нужно всегда сохранять
Dima
всегда, с белым или черным списком
Dima
+ throttling
Aleksei
ключи типа выкидываешь?
Dima
ну чтобы не на каждый экшен дергать, а только на некоторые
Aleksei
а, понял)
Dima
Artem
Никто в react native не знает, что такое offline first приложения, и зачем бд в приложении. Забавно.
Dima
действительно забавно, бд - не обязательно sql интерфейс, это может быть key/value
Dima
и у меня как раз оффлайн first. Оптимистичные транзакции после которых стейт сохраняется
Alexey
Чо такое offline first, расскажите пожалуйста))
A
есть вопрос, который по зубам только гуру)
Artem
Категорично. Не расскажешь зачем бд в приложении?
Да легко :) сеть не всегда доступна, а оставлять юзера без данных нехорошо. Есть у нас какое-то приложения для управления задачами. Вы каждый раз будете в сеть стучать? Или в файл сериализовать? А если надо показать пользователю только часть задач?
A
клиент хочет вот так: - preprocessor ifdefs may be used - ifdef feature-wise, target customer build may choose features (e.g. #ifdef CAR_INSURANCE_DETAILS then show menu) кто-нить понимает как это можно сделать на уровне react-native , и как это вообще может выглядеть?
Artem
А если надо создавать задачи оффлайн и обращаться с ними как с полноценными созданными задачами?
Artem
ты кажется не понял. зачем именно бд? и чем файл плох?
И как запросы к данным в файл строить?
Artem
Или все сразу вытаскивать?
Artem
React native и так не шустряк, а так вообще загнётся
Aleksei
ну мы как бы именно об этом говорили. читать надо внимательнее
Aleksei
плохо конечно что кто то не может представить себе как хранить данные кроме бд и запросов
Aleksei
Ну, эм, расскажи, какие костыли можешь предложить :)
ты очевидно даже не знаешь что такое AsyncStorage
Artem
ты очевидно даже не знаешь что такое AsyncStorage
Key-value хранилище данных. Если у вас в приложениях все данные можно так однозначно туда запихнуть, то что ж. Печальные приложения :)
Aleksei
Key-value хранилище данных. Если у вас в приложениях все данные можно так однозначно туда запихнуть, то что ж. Печальные приложения :)
Да уж. Лучше не надо пытаться вставить свои пять копеек если не можешь. Может расскажешь на цифрах когда оно начнет тормозить и станет печальным?
Artem
Есть у тебя в AsyncStorage список объектов. Половина синхронизирована с сервером, другая нет. Как ты вытащишь только те, которые не синхронизированы, чтобы отправить на сервер?
Dan
что то типо того
Дата сервисы -> Глобальные сервисы -> Глобальные mobx сторы -> Маленькие mobx сторы -> Стейт роутов / компонент
Artem
Отлично будет :)
Aleksei
конечно. что с json никогда не работал?
Artem
конечно. что с json никогда не работал?
Работал. Только не знаю, почему ты не поймёшь, что на нормальных массивах данных десериализация всего и сразу - это колоссальный оверхед
Aleksei
у тебя есть база где хранятся объекты без сериализации? покажешь?
Aleksei
о, ну покажи как у тебя там без сериализации)
Artem
Она не десериализует все для выполнения запроса
Aleksei
и как у тебя там «объекты» хранятся
Artem
Она не десериализует все для выполнения запроса
Aleksei
скажи пожалуйста, ты писал на RN?
Dan
гайз, вы спорите за документоориентированные базы vs KV :)
Artem
скажи пожалуйста, ты писал на RN?
Скажи пожалуйста, ты приличные объёмы данных в hey-value пихал. Я, к счастью, пишу native приложения и такие костыли не изобретаю
Aleksei
потому что слышать «Она не десериализует все для выполнения запроса» довольно странно. Учитывая что в приложении ты просто один раз десериализуешь в память и все. А потом просто сохраняешь данные в AsyncStorage. Нет никаких «запросов», так как нет и базы
Artem
Хотя нет, когда-то пытался key-value использовать для бд. Было весело
Aleksei
А еще если бы ты внимательно читал, то увидел что мы изначально говорили о сериализации как о достаточном средстве для приложений где мало данных
Aleksei
Вот откуда вы такие лезете нативщики, лишь бы свои ненужные пять копеек вставить
Artem
Вот откуда вы такие лезете нативщики, лишь бы свои ненужные пять копеек вставить
«Ненужные» - не забывай свои корни, помни. Когда будете искать нативные плагины к этим вашим js-ам, подумайте об этом.
« Rev
@reactnative_ru   423
Fwd »