c
договоренностей по поводу именования доменов пока нет
Ага. Но я скорее про назначение домена. А не семантику именования
Size: a a a
2020 June 09
c
У меня каждая фича в проекте это домен, который создан от домена app
А
🦄
у .on merge срабатывает автоматически если передан массив
TS не будет ругаться?
P
Ага. Но я скорее про назначение домена. А не семантику именования
назначения домена - реализация Laravel Echo на эффекторе
c
У меня каждая фича в проекте это домен, который создан от домена app
Это имеет практическую ценность?
P
Это имеет практическую ценность?
пока только на app домен есть хуки
P
но они могут и появится в рамках фичи
P
Плюс для HMR полезно clearNode
🚀🚀
Оооо я пропустил это
да не, мы его даже обсуждали, это просто крайне редкий кейс вне библиотек и довольно полезный внутри них)
идея в том что все входящие поля становятся заведомо сторами, позволяя работать с ними дальше унифицированно, ну и для того чтобы это было полезно нужно, в первую очередь, достаточное количество таких функций самих по себе))
идея в том что все входящие поля становятся заведомо сторами, позволяя работать с ними дальше унифицированно, ну и для того чтобы это было полезно нужно, в первую очередь, достаточное количество таких функций самих по себе))
P
Но HMR у меня нету )
DS
Но HMR у меня нету )
крикнул))
P
почему?
P
с ним больше проблем чем пользы кмк
DS
Плюс для HMR полезно clearNode
ну после этого и этого)
DS
с ним больше проблем чем пользы кмк
Почему?
🚀🚀
TS не будет ругаться?
нет, всё ок, на любую новую фичу при релизе сразу пишется тест типов, гарантирующий надёжность его типизации https://github.com/zerobias/effector/blob/master/src/types/__tests__/effector/store.test.js#L323
P
HMR полезен когда компоненты редактируешь
P
Если стор создан рядом с компонентом, можно ресетить
🚀🚀
с ним больше проблем чем пользы кмк
++
P
А когда работаешь с логикой, проще написать все, потом тестить