VI
Имею ввиду, что описывая .on(event) - все предельно прозрачно. Отдельный форвард меняющий стор - уже не очень.
Size: a a a
2020 March 25
VI
Или я не так суть понял?)
AV
Выглядит неочевидненько
+100500
Публичный ивент и никаких форвардов
Публичный ивент и никаких форвардов
VI
Alex Vodonaev
+100500
Публичный ивент и никаких форвардов
Публичный ивент и никаких форвардов
Ага
AV
А вот из ивент в ивент норм
AV
Alex Vodonaev
А вот из ивент в ивент норм
"при кроссфичных взаимодействиях"
TK
примерно правильно) но в моем случае, в фиче создаются спец ивенты и сторы под "форвард", и это часть интерфейса для форварда, и туда форвардятся данные тоже определенного интерфейса
получается фича в которую форвардят ничего не знает о том кто туда форвардит, она просто делает свою работу
это по идее не особо простой паттерн, и согласен что есть проблемы со сложностью связей, но есть и плюсы)
получается фича в которую форвардят ничего не знает о том кто туда форвардит, она просто делает свою работу
это по идее не особо простой паттерн, и согласен что есть проблемы со сложностью связей, но есть и плюсы)
AO
Если кому интересно, по исходному вопросу - написал используя .on и все красиво и лаконично смотрися, вариант с forward действительно неочевидный, видимо поэтому у меня и возник вопрос изначально
🦉
Aleksandr Osipov
Подскажите, forward из event в store же - нормальный способ обновить значение стора?
вот как раз для него пишу доку
лучше юзать store.on
лучше юзать store.on
D
Можно же сделать форвард в эвент и на эвент уже подписаться стором
VI
Alex Vodonaev
+100500
Публичный ивент и никаких форвардов
Публичный ивент и никаких форвардов
.
VK
больше не знаю, я в принципе только половину из списка знаю )
- zerobias/effector
- mobxjs/mobx
- reduxjs/redux
- Yomguithereal/baobab
- immerjs/immer
- davidkpiano/xstate
- cerebral/cerebral
- storeon/storeon
- artalar/reatom
и каким боком там immer затесался?
DS
Можно же сделать форвард в эвент и на эвент уже подписаться стором
апппха)
VR
и каким боком там immer затесался?
это не ко мне )
D
апппха)
Што?
TK
примерно правильно) но в моем случае, в фиче создаются спец ивенты и сторы под "форвард", и это часть интерфейса для форварда, и туда форвардятся данные тоже определенного интерфейса
получается фича в которую форвардят ничего не знает о том кто туда форвардит, она просто делает свою работу
это по идее не особо простой паттерн, и согласен что есть проблемы со сложностью связей, но есть и плюсы)
получается фича в которую форвардят ничего не знает о том кто туда форвардит, она просто делает свою работу
это по идее не особо простой паттерн, и согласен что есть проблемы со сложностью связей, но есть и плюсы)
но это почти чистый ioc
лучше обернуть этот интерфейс во что-то, и сделать что-то вроде
лучше обернуть этот интерфейс во что-то, и сделать что-то вроде
const IB = featureB.createInterface(
{
$someStoreB,
evSomeEventB
});
featureB = featureA.implementInterface(IB,
{ $someStoreA, someEventA });
featureA.forwardTo(featureB);
AV
Можно же сделать форвард в эвент и на эвент уже подписаться стором
У меня в фичах есть два стора - внутренний приватный стейт и map'нутый computed, который может выехать наружу, для чтения.
DS
Што?
думал рофл)
можно форвард в форвард в форвард в стор по апдейту которго запускаем ээфект)
можно форвард в форвард в форвард в стор по апдейту которго запускаем ээфект)
🦉
D
думал рофл)
можно форвард в форвард в форвард в стор по апдейту которго запускаем ээфект)
можно форвард в форвард в форвард в стор по апдейту которго запускаем ээфект)
Ну если в форварде трансформации происходят, то можно и так = )