c
Все я понял, это те же сервисы, только у них не асинк методы, а эффекты
ага
и можно занимать метод, а не использовать напрямую
и можно занимать метод, а не использовать напрямую
Size: a a a
2020 October 06
yv
ещё наличие postpone и delay не будет смущать? может в delay добавить отмену?
тем более если у postpone параметр delay, а у delay параметр timeout
c
ещё наличие postpone и delay не будет смущать? может в delay добавить отмену?
я чет не подумал об этом
предлагаешь добавить в delay параметры target и abort?
предлагаешь добавить в delay параметры target и abort?
yv
я чет не подумал об этом
предлагаешь добавить в delay параметры target и abort?
предлагаешь добавить в delay параметры target и abort?
ну мне кажется это будет логичнее, чем два способа отложить выполнение
c
записал, спасибо
yv
borrow вероятно можно расширить на евенты. не знаю, будет ли это полезно, правда)
yv
или я запутался
🚀🚀
кейс: я описываю себе слой апи, где каждый метод это эффект
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
const loadCardFx = borrow({ effect: api.loadCardFx })и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
можно просто апдейтнуть attach)
🚀🚀
но только если сначала решить как это описывать в документации
🚀🚀
так как метод получается разносторонним)
NK
effector patronum v0.109
- Теперь все методы имеют тесты на работу в fork, а значит поддерживают SSR
- Метод spread имеет типизацию и также покрыт тестами
- В методе combineEvents исправлена ошибка типизации
На шаг ближе к v1.0
- Теперь все методы имеют тесты на работу в fork, а значит поддерживают SSR
- Метод spread имеет типизацию и также покрыт тестами
- В методе combineEvents исправлена ошибка типизации
На шаг ближе к v1.0
c
можно просто апдейтнуть attach)
можно
но как обрабатывать такой кейс?
attach({ effect, source })
но как обрабатывать такой кейс?
attach({ effect, source })
🚀🚀
так он и сейчас есть, эта запись означает вызов effect с значением из source в params
🚀🚀
так как обратное (подключить source и не заюзать его) не имеет смысла
c
так он и сейчас есть, эта запись означает вызов effect с значением из source в params
о
вон как
вон как
🚀🚀
о
вон как
вон как
c
ну тогда есть смысл attach({ effect })
тогда такой же borrow смысл не будет иметь
и можно упростить
тогда такой же borrow смысл не будет иметь
и можно упростить
🚀🚀
есть только одна проблема, может сломаться тайпскрипт))
c
но только если сначала решить как это описывать в документации
можно описать мотивацию появления
c
кейс: я описываю себе слой апи, где каждый метод это эффект
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
const loadCardFx = borrow({ effect: api.loadCardFx })и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
вот такую