AO
ну типа у тебя корневой эффект есть, который хендлит общие ощибки скажем и все такое, а есть конкретные эффекты в фитчах
Size: a a a
2020 October 06
yv
но ведь потом всё равно нужно будет мап+фильтр ставить, чтобы отсечь только нужные ошибки?
c
не, я хотел спросить кейс, не очень понятно зачем
кейс: я описываю себе слой апи, где каждый метод это эффект
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
const loadCardFx = borrow({ effect: api.loadCardFx })и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
FB
кейс: я описываю себе слой апи, где каждый метод это эффект
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
const loadCardFx = borrow({ effect: api.loadCardFx })и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
условно, forward c api.loadCardFx и forward c loadCardFx - разные форварды?
c
условно, forward c api.loadCardFx и forward c loadCardFx - разные форварды?
ну да
yv
кейс: я описываю себе слой апи, где каждый метод это эффект
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
const loadCardFx = borrow({ effect: api.loadCardFx })и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
примерно понял, но разве это не вызовет неконсистентное состояние потенциально? типа загрузил карточки в двух фичах, потом из одной обновил — на второй ничего не обновилось. если бы был один эффект — всё было бы синхронно.
L
кейс: я описываю себе слой апи, где каждый метод это эффект
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
const loadCardFx = borrow({ effect: api.loadCardFx })и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
Тоже самое можно ж через фабрку сделать ?
c
кейс: я описываю себе слой апи, где каждый метод это эффект
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
А в страницах хочу реагировать на эти методы
Но одни и те же методы могут дергать разные страницы в разных бизнес-процессах. А значит, статическая связка, при триггере запустит логику всех страниц связанных с этим эффектом.
Решается легко:
const loadCardFx = borrow({ effect: api.loadCardFx })и теперь юзаем loadCardFx в этой странце
и нет никаких пересечений
import * as api from 'api/cards'
const loadCardFx = borrow({ effect: api.loadCardFx })
api.loadCardFx.finally.watch(() => console.log("ORIGINAL"))
loadCardFx.finally(() => console.log("BORROWED"))
---
loadCardFx()
// BORROWED
// ORIGINAL
api.loadCardFx()
// ORIGINALc
Тоже самое можно ж через фабрку сделать ?
каждый раз создавать новый эффект через фабрику?
тогда потеряю возможность подписаться на оригинальный эффект, если уж прям нужно реагировать на каждый вызов, вне зависимости от места и процесса
тогда потеряю возможность подписаться на оригинальный эффект, если уж прям нужно реагировать на каждый вызов, вне зависимости от места и процесса
yv
borrow это референс в сторону раста, да? :)
c
примерно понял, но разве это не вызовет неконсистентное состояние потенциально? типа загрузил карточки в двух фичах, потом из одной обновил — на второй ничего не обновилось. если бы был один эффект — всё было бы синхронно.
так я не храню состояние в api
фичи получатся независимыми друг от друга
цель в том, чтобы одна не знала про процессы другой
фичи получатся независимыми друг от друга
цель в том, чтобы одна не знала про процессы другой
L
каждый раз создавать новый эффект через фабрику?
тогда потеряю возможность подписаться на оригинальный эффект, если уж прям нужно реагировать на каждый вызов, вне зависимости от места и процесса
тогда потеряю возможность подписаться на оригинальный эффект, если уж прям нужно реагировать на каждый вызов, вне зависимости от места и процесса
Я тогда не понял, зачем тебе ещё и подписка на оригинальный эффект ?
c
borrow это референс в сторону раста, да? :)
да
ф
prepend, работающий со любыми юнитами
const clock = prepend({
source: [$a, $b],
fn: ([a, b], c) => ({a, b, c}),
target,
})
const clock = prepend({
source: [$a, $b],
fn: ([a, b], c) => ({a, b, c}),
target,
})
я сейчас понял, что возвращать из либы ивенты/эффекты, созданные внутри, которые предназначены для того, чтобы их запускали - это плохо в принципе...
вместо этого нужно чтобы пользователь сам создал иаенты/эффекты, которые он хочет запускать, и передал их в либу
вместо этого нужно чтобы пользователь сам создал иаенты/эффекты, которые он хочет запускать, и передал их в либу
ф
Переслано от 🚀🔬 🚀🔬🚀🔬...
библиотека для эффектора должна давать возможность подключить уже существующие юниты, хотя бы в качестве альтернативы
c
Я тогда не понял, зачем тебе ещё и подписка на оригинальный эффект ?
например, отлавливать ошибки, кешировать и ещё что-то
у меня есть фича, которая кеширует карточки, которые загружаются
это нужно не для ответа сервера, а для показывания содержимого карточки и консистентного апдейта
а ещё это удобно если нужно разлогинить юзера по 401
и тому подобное
даже если не везде это нужно, получается в одних кейсах фабрика, в других обычный эффект
не круто. поэтому borrow решает
у меня есть фича, которая кеширует карточки, которые загружаются
это нужно не для ответа сервера, а для показывания содержимого карточки и консистентного апдейта
а ещё это удобно если нужно разлогинить юзера по 401
и тому подобное
даже если не везде это нужно, получается в одних кейсах фабрика, в других обычный эффект
не круто. поэтому borrow решает
c
я сейчас понял, что возвращать из либы ивенты/эффекты, созданные внутри, которые предназначены для того, чтобы их запускали - это плохо в принципе...
вместо этого нужно чтобы пользователь сам создал иаенты/эффекты, которые он хочет запускать, и передал их в либу
вместо этого нужно чтобы пользователь сам создал иаенты/эффекты, которые он хочет запускать, и передал их в либу
ты к borrow это пишешь? или просто?
L
например, отлавливать ошибки, кешировать и ещё что-то
у меня есть фича, которая кеширует карточки, которые загружаются
это нужно не для ответа сервера, а для показывания содержимого карточки и консистентного апдейта
а ещё это удобно если нужно разлогинить юзера по 401
и тому подобное
даже если не везде это нужно, получается в одних кейсах фабрика, в других обычный эффект
не круто. поэтому borrow решает
у меня есть фича, которая кеширует карточки, которые загружаются
это нужно не для ответа сервера, а для показывания содержимого карточки и консистентного апдейта
а ещё это удобно если нужно разлогинить юзера по 401
и тому подобное
даже если не везде это нужно, получается в одних кейсах фабрика, в других обычный эффект
не круто. поэтому borrow решает
Все я понял, это те же сервисы, только у них не асинк методы, а эффекты
ф
ты к borrow это пишешь? или просто?
не, просто смотрел твои rfc и мысль пришла
yv
У кого есть 5 минут, проглядите RFC в patronum.
https://github.com/effector/patronum/issues?q=is%3Aopen+is%3Aissue+label%3ARFC
Мб есть какие-то мысли/предложения/претензии к ним
https://github.com/effector/patronum/issues?q=is%3Aopen+is%3Aissue+label%3ARFC
Мб есть какие-то мысли/предложения/претензии к ним
ещё наличие postpone и delay не будет смущать? может в delay добавить отмену?