Kurzdor
я вот пробовал у вуя их vuex он мне понравился простотой
Ivan
Посмотри mobx
Ivan
Найди готовый пример, каких полно на гитхабе, посмотри как там сделано
⩔wein
если приложение совсем простое то в целом достаточно и контекста
Kurzdor
Можно еще reatom глянуть
про твой реатом в курсе, дело в том что нельзя тянуть не продакшн реди пакетов
artalar
👌
Ivan
Использовать контекст для запросов? Или для стейт менеджмента?
Daniil
Я аж проснулся
Kurzdor
ну если телочки могут в программирование — то не нужно быть гением
Igor
ну если телочки могут в программирование — то не нужно быть гением
то есть, член является определяющим в программировании?
Ivan
эм, очевидно для стейт менеджмента.
Вопрос был про организацию процессов взаимодействия с апи.. а про контекст для стейт-менеджмента промолчу, видимо у нас разное представление :) кому как удобней
Ivan
Бро, если у тебя по разработке вопрос - задавай здесь, не надо меня никуда приглашать :) если как к музыканту, то пиши в сообщество. То, что ты мне пишешь - это не прикольно, я не понимаю чего ты хочешь )
Ivan
Вопрос был про организацию процессов взаимодействия с апи.. а про контекст для стейт-менеджмента промолчу, видимо у нас разное представление :) кому как удобней
Взаимодействием с апи должна заниматься отдельная сущность. Она должна общаться только со стейт-менеджером. Как реализован стейт-менеджмент — не важно. Мой поинт в том, что не нужно делать запросы из компонентов — это чревато.
⩔wein
Вопрос был про организацию процессов взаимодействия с апи.. а про контекст для стейт-менеджмента промолчу, видимо у нас разное представление :) кому как удобней
Я вроде написал, что контекст допустимо использовать для небольших приложений, а не что я предлагаю это как основное решение всюду. Современный реакт-контекст вполне адекватный инструмент для этого, особенно совмещая с соответствующими хуками типа useReducer. Насчет взоимдействвия с апи - это не имеет значения какой у тебя стейт менеджмент по большому счету. Какая разница. Хоть контекст, хоть mobx хоть редакс. Ну ок, для редакса есть специальные тулзы которые обычно это организовывают, типа саги, но вотэвар
Kurzdor
нет просто глазком прокинулся по доке
Ivan
пример можно?
Все примеры в книжке «чистая архитектура». Правда, они на Java. В разных стейт-машинах есть свои архитектурные отграничения. В редаксе запросы можно отправлять только из мидлварей. Пример — документация по redux-saga. В мобыксе всё иначе, там в доке тоже можно найти примеры. Если что-то более экстравагантное — сам ищи)
Kurzdor
я короче решу брать ли редакс или мобкс и к редаксу что то еще
Ivan
redux, redux-act, reselect
А redux-act про что? Если в двух словах?
artalar
А redux-act про что? Если в двух словах?
хелпер для создания редусеров и экшен-криэйтеров + выводит автоматом типы из payload экшена в аргумент редусера
Kurzdor
redux, redux-act, reselect
А есть что то подобное на вьюэкс для реакта? Он очень хорош был. https://vuex.vuejs.org/
artalar
не знаю
artalar
reatom ооочень хороший))
Ivan
А кто админ тут
artalar
Ivan
Если уже используете, то оставайтесь
Ну я только-только развернул скелет нового проекта, ещё не поздно. До этого два года mobx’ом руки мозолил — познаю многообразие redux-хэлперов.
Sergey
А есть что то подобное на вьюэкс для реакта? Он очень хорош был. https://vuex.vuejs.org/
А что конкретно там нравится? Просто не довелось с ним поработать. Краем глаза только видел доку. Работал с Redux, Mobx, Effector, но выбрал Reatom для проекта (так, что даже контрибьютить начал 👀).
artalar
Загляну на огонёк, посмотрю на ваш реатом
https://soundcloud.com/5minreact/061-reatom-vs-redux
Kurzdor
А что конкретно там нравится? Просто не довелось с ним поработать. Краем глаза только видел доку. Работал с Redux, Mobx, Effector, но выбрал Reatom для проекта (так, что даже контрибьютить начал 👀).
Вообщем Есть State, Computed, Mutations, Actions Стейт к примеру firstName: 'Ivan', lastName: 'Kirk' Компьютед - fullName: () => firstName + ' ' + lastName Мутации - мутируем стейт, store.dispatch Экшны - ну тут обычно проводим апи запросы и работаем с стейтом через мутации, https://vuex.vuejs.org/guide/actions.html Модули еще, это на каждую фичу?: user/articles/news своя пачка из стейта, мцтаций, экшнов и тд
Sergey
Вообщем Есть State, Computed, Mutations, Actions Стейт к примеру firstName: 'Ivan', lastName: 'Kirk' Компьютед - fullName: () => firstName + ' ' + lastName Мутации - мутируем стейт, store.dispatch Экшны - ну тут обычно проводим апи запросы и работаем с стейтом через мутации, https://vuex.vuejs.org/guide/actions.html Модули еще, это на каждую фичу?: user/articles/news своя пачка из стейта, мцтаций, экшнов и тд
Ну тогда тебе однозначно стоит внимательно Reatom глянуть :) Единственно что мутации. В реатом используются имутабильный структуры (но если хочется, то можно immer добавить). Computed есть (combine + map) State есть (Atom + Store) Actions есть. В добавок атомы (части стора/модели) ты можешь подключать асихнронно (в зависимости от фичи). Не нужно всё подключать в корне.
howitworks
думаю че так ринулись продвигать ноунейм либу, а это контрибьютеры его ))
artalar
Атто
artalar
https://soundcloud.com/5minreact/061-reatom-vs-redux
ну уже не особо нонейм
howitworks
ну я не слушал/смотрел, но мне кажется и его ведущий здесь админ и ваш кореш ))
artalar
Не, ведущий вообще со стороны. Причем сам заинтересовался.
howitworks
ближе к мобх или redux-observable ?
Anonymous
а что за экшены генерирует redux?
artalar
ближе к мобх или redux-observable ?
Ближе к kefir.atom и effector, только без фокуса на сайд-эффектах, а на менеджменте computed’ов
⩔wein
Ближе к kefir.atom и effector, только без фокуса на сайд-эффектах, а на менеджменте computed’ов
зачем фокусироваться на менеджменте компьютед вальюс когда у нас есть мемоизация?
artalar
зачем фокусироваться на менеджменте компьютед вальюс когда у нас есть мемоизация?
Затем что мемоизация плохо скейлится по перфу + ее ручками нужно делать что не удобно
⩔wein
Затем что мемоизация плохо скейлится по перфу + ее ручками нужно делать что не удобно
не уверен насчет того почему мемоизация плохо скейлится. понятное дело что она не везде нужна и полезна и в некоторых случаях может быть минусом, но это к любому кэшированию относится
howitworks
я каэш не в теме, но это рыл удобнее всяких редухтеров ? export const $todosIdsVisible = declareAtom( 'todosIdsVisible', // name [], // initial state reduce => reduce( combine([$todosIds, $todosCompleted, $visibilityFilter]), (state, [ids, ByCompleted, filter]) => { switch (filter) { case VISIBILITY_FILTERS.COMPLETED: return ids.filter(id => ByCompleted[id]) case VISIBILITY_FILTERS.INCOMPLETE: return ids.filter(id => !ByCompleted[id]) case VISIBILITY_FILTERS.ALL: default: return ids } }, ), )
⩔wein
Потому что, именно в редаксе, всего одна очередь подписок
так, какая разница. js в любом случае однопоточен. кроме того редакс тут вообще не причем, мемоизация к редаксу отношения не имеет(и помоему и не должна).
howitworks
а ближе к западу его популизируете ?
⩔wein
Раскройте вопрос, я мб его не понял.
Ну, тут вопрос скорее к вам. В чем выражается фокус - какую проблему хотите решить и как.
artalar
а ближе к западу его популизируете ?
Будем, все на англ.Что бы релизнуться нужен небольшой рефакторинг, а на него нет времени, куча работы.
artalar
Ну, тут вопрос скорее к вам. В чем выражается фокус - какую проблему хотите решить и как.
Очень много проблем, все по разному, я его уже 2 года пишу, это 8+ реинкарнация (предыдущие не прод были, эта прод)… Недавно в Яндексе доклад трехчасовой читал про стейт-менеджеры, но успели только 2/3 разобрать из всех тем.
artalar
Я имею в виду конкретно относительно мемоизации/компьютед вальюс
Мемоизация в редаксе решает проблему ромбовидных зависимостей. Я ее в реатоме решаю пересортировкой графа при его (графа) инициализации.
artalar
Почему именно так? Потому что это требует больше времени на инициализации, зато меньше потом на обход (реакции на диспатч) - что важнее, я считаю
⩔wein
Пройтись по 2 подпискам или по 100.
Не очень понял. Зачем по ним идти. В редаксе нет как таковых подписок ни на что. Компоненты подписаны на реактовский контекст, там висит обьект с данными, обновляется кусок данных которые юзает компонент - он ререндерится. Или о каких подписках речь?
⩔wein
Почему ререндер только у тех у кого данные обновились, а не у всех?
Потому что mapStateToProps замапит в компонент только те значения, которые компонент использует и если поменяются какие-то соседние то на компоненте это никак не отразится?
Sergey
Не очень понял. Зачем по ним идти. В редаксе нет как таковых подписок ни на что. Компоненты подписаны на реактовский контекст, там висит обьект с данными, обновляется кусок данных которые юзает компонент - он ререндерится. Или о каких подписках речь?
Ну я говорил про кейс без React (про голый Redux или Reatom) Даже если ты используешь одну подписку, то изменение стейта тригерит у тебя всё. Например у тебя 30 копонентов, которым нужны данные из стора. У тебя есть инпут, который ты диспатчишь в стор (данное значение никаким боком не нужно этим 30 компонентам) Что в данном случае произойдёт?
⩔wein
Ну я говорил про кейс без React (про голый Redux или Reatom) Даже если ты используешь одну подписку, то изменение стейта тригерит у тебя всё. Например у тебя 30 копонентов, которым нужны данные из стора. У тебя есть инпут, который ты диспатчишь в стор (данное значение никаким боком не нужно этим 30 компонентам) Что в данном случае произойдёт?
Я понимаю что это абстрактный пример, но в реальности 1) Отправлять значения инпута в стор на лету по умолчанию плохая идея 2) Подключать к стору 30 компонентов сразу(и все из них примонтированы в один момент времени) - очень плохая идея. На практике в один момент времени у тебя будут примонтированы 2-3, ну может 5 следящих за стором компонентов, поэтому импакт изменений довольно не значителен
artalar
Сотня подписчиков - нормальная ситуация
⩔wein
Сотня подписчиков - нормальная ситуация
Нет, это не правильное использование редакса.