🚀🚀
ну в принципе композиция сущностей так и работает, если удобно сделать метод attachToUrl то почему бы и нет
Size: a a a
2020 August 10
꧁岡
ну вот так
꧁岡
просто дублирую код по факту
TP
...так камень не продашь
Либо я не во все вчитался что было до этого)
꧁岡
ну в принципе композиция сущностей так и работает, если удобно сделать метод attachToUrl то почему бы и нет
окс
🚀🚀
Async / await based functions can initially seem confusing when starting with actions. Because lexically they appear to synchronous functions, it gives the impression that @action applies to the entire function. Which is of course not the case, as async / await is just syntactic sugar around a promise based process. As a result, @action only applies to the code block until the first await. And after each await a new asynchronous function is started, so after each await, state modifying code should be wrapped as action. This is where runInAction comes in handy again
кстати поэтому эффекты это отдельные сущности — без этого не получилось бы в итоге сохранять асинхронный контекст как тут) https://t.me/effector_tips_ru/37
Б
Забавно, что каждый раз, когда в этом чате появляются сторонники mobx, дальше синхронных изменений стейта примеры не уходят. Видимо никогда не хочется вспоминать про runInAction после первого await в асинхронной функции для каждой мутации :(
Зачем мне запускать runInAction? Я честно говоря уже не помню что это такое так как никогда не юзал с mobx-ом. Если речь о батчинге то во первых это относится к решению тормозов а не к удобству и требуется лишь когда появляется боттлнек а во вторых батчинг можно добавить другим способом и не нужно будет писать runInAction после каждого await.
🦜
тут можно хелпер сделать
꧁岡
ага
s
Зачем мне запускать runInAction? Я честно говоря уже не помню что это такое так как никогда не юзал с mobx-ом. Если речь о батчинге то во первых это относится к решению тормозов а не к удобству и требуется лишь когда появляется боттлнек а во вторых батчинг можно добавить другим способом и не нужно будет писать runInAction после каждого await.
Я не знаю зачем вам запускать runInAction, но это кусок документации. Полагаю, что автоматический трекинг мутаций перестает быть автоматическим в асинхронных функциях.
s
Зачем мне запускать runInAction? Я честно говоря уже не помню что это такое так как никогда не юзал с mobx-ом. Если речь о батчинге то во первых это относится к решению тормозов а не к удобству и требуется лишь когда появляется боттлнек а во вторых батчинг можно добавить другим способом и не нужно будет писать runInAction после каждого await.
Тормоза - последнее, что будет меня интересовать, кстати.
Я хочу удобно, потому что в 90% случаев тормозить не будет.
Я хочу удобно, потому что в 90% случаев тормозить не будет.
꧁岡
꧁岡
꧁岡
NF
Забавно, что каждый раз, когда в этом чате появляются сторонники mobx, дальше синхронных изменений стейта примеры не уходят. Видимо никогда не хочется вспоминать про runInAction после первого await в асинхронной функции для каждой мутации :(
в чем проблема писать на генераторах, у них такой проблемы нет)
🦜
норм, но я бы объединил такие эффекты отделив пустыми строками сверху и снизу
꧁岡
я ща просто с редакса код переписываю, пока не до форматирования)
s
в чем проблема писать на генераторах, у них такой проблемы нет)
В чем проблема использовать effector, у него такой проблемы нет)
Придумать альтернативных способов написания кода можно сколько угодно.
Асинхронные функции - это удобно. Использовать генераторы, чтобы угодить стейт менеджеру - ну такое
Придумать альтернативных способов написания кода можно сколько угодно.
Асинхронные функции - это удобно. Использовать генераторы, чтобы угодить стейт менеджеру - ну такое
Б
Я не знаю зачем вам запускать runInAction, но это кусок документации. Полагаю, что автоматический трекинг мутаций перестает быть автоматическим в асинхронных функциях.
нет конечно, это просто способ вызвать обновление компонентов только после того как отработает коллбек-функция в runInAction а иначе нужные компоненты будут обновляться после каждого изменения переменных (и если переменная меняется несколько раз то компонент несколько раз обновится). Я кстати против такого поведения по умоланию в mobx и поэтому всегда юзаю простой враппер (над дефолтным observer которым оборачивают компоненты) который батчит все обновления на следующий тик жс, и в результате мне никогда не нужно писать runInAction
NF
нет конечно, это просто способ вызвать обновление компонентов только после того как отработает коллбек-функция в runInAction а иначе нужные компоненты будут обновляться после каждого изменения переменных (и если переменная меняется несколько раз то компонент несколько раз обновится). Я кстати против такого поведения по умоланию в mobx и поэтому всегда юзаю простой враппер (над дефолтным observer которым оборачивают компоненты) который батчит все обновления на следующий тик жс, и в результате мне никогда не нужно писать runInAction
истинный бэкендер сохраняет мутированные сущности автоматически после завершения запроса😄