ф
он может принимать в себя домен
$inFlight = inFlight({ domain })Size: a a a
2020 September 21
V
я закинул в patronum метод inFlight
он может принимать в себя домен
он может принимать в себя домен
Интересно... Я пока это прямо в домене в onCreateEffect...
DS
фига пасиба)
c
Интересно... Я пока это прямо в домене в onCreateEffect...
Вот можешь заменить на однострочник
NT
такой апи пока обдумывается)
🙃
2020 September 22
V
Что лучше?
const derived = createStore<T>(...).on(source, mapper);или
const derived = source.map(mapper);
V
особенно в контексте эффектов...
createStore().on(effect.doneData) или effect.doneData.map?c
Что лучше?
const derived = createStore<T>(...).on(source, mapper);или
const derived = source.map(mapper);
Второе
c
Явно отслеживается намерение автора. Если видишь первый вариант, сразу настораживаешься и ищешь причину почему так сделано
V
кто-то в этом чате подсказал мне первое 😂
c
особенно в контексте эффектов...
createStore().on(effect.doneData) или effect.doneData.map?Так это разное назначение. Первое это самостоятельный стор, реагирующий на эффект. Второе это явно следствие эффекта, и там будет ивент
V
но если мне не нужно в этот конкретный стор кидать эвенты, то мап лучше всего, получается...
V
т.е. это просто derived data
V
она всегда зависит от родительского стора
c
но если мне не нужно в этот конкретный стор кидать эвенты, то мап лучше всего, получается...
А если нужно, то необходимо четко продумать область ответственности
V
логично..
V
но по факту я же могу делать и
store.map().on тоже... т.е. разницы нет??V
я еще пока только вкуриваюсь, поэтому меня конфузят разные вещи.
c
но по факту я же могу делать и
store.map().on тоже... т.е. разницы нет??Можешь, но не стоит. В сср данные дерайвед стора не передаются на клиент. А значит можно потерять данные
V
хм... пока что с SSR совсем не заморачивался, так что приму как данность