Size: a a a

2020 October 20

DS

Dmitriy Shuleshov in ☄️ effector
фильтруй мысли
я сейчас понял, что возвращать из либы ивенты/эффекты, созданные внутри, которые предназначены для того, чтобы их запускали - это плохо в принципе...

вместо этого нужно чтобы пользователь сам создал иаенты/эффекты, которые он хочет запускать, и передал их в либу
аргументы?
источник

AO

Aleksandr Osipov in ☄️ effector
например sample / guard имеют форму когда возвращают новый юнит
источник

AO

Aleksandr Osipov in ☄️ effector
и это удобно
источник

ф

фильтруй мысли... in ☄️ effector
Dmitriy Shuleshov
аргументы?
просто прими это или  проигнорируй)
источник

DS

Dmitriy Shuleshov in ☄️ effector
Aleksandr Osipov
например sample / guard имеют форму когда возвращают новый юнит
не для запуска пейлоада в граф
источник

AO

Aleksandr Osipov in ☄️ effector
фильтруй мысли
просто прими это или  проигнорируй)
инлайнить нельзя такие конструкции (но плюс или минус это - опять же спорно)
источник

DS

Dmitriy Shuleshov in ☄️ effector
фильтруй мысли
просто прими это или  проигнорируй)
😁
источник

ф

фильтруй мысли... in ☄️ effector
Dmitriy Shuleshov
аргументы?
просто я предпочитаю создавать ивенты явно, а не на лету
https://t.me/effector_ru/171965
Telegram
прими это in ☄️ effector
Мне нравится такой подход: создавать юниты эффектора в одном файле, а их взаимодействия - в другом.

Выглядит это так:
model.js - интерфейс модели (сущности),
init.js - модель поведения (связи)

Удобно, когда в одном файле описано, что из себя представляет модель. Заглянув в этот файл, можно  быстро получить представление о модели, её состояниях и методах, до погружения в бизнес-логику.  Создавая юниты в одном файле, мы описываем интерфейс модели (как интерфейс объекта в типах).

Получается, что вся логика  находится в одном файле (init), а создание сущностей мы выносим в отдельный (model), чтобы видеть структуру модели, т.е. что она из себя представляет. В итоге, интерфейс и поведение разделены.

Такой подход также позволяет импортить то, что тебе нужно, и не париться насчёт циклических зависимостей. Модели/подмодели могут перекрёстно зависеть друг от друга, это развязывает руки и упрощает работу - не нужно ломать голову каждый раз, что от чего должно зависеть, чтобы не было циклов.

В model у меня только создание…
источник

DS

Dmitriy Shuleshov in ☄️ effector
фильтруй мысли
просто я предпочитаю создавать ивенты явно, а не на лету
https://t.me/effector_ru/171965
Telegram
прими это in ☄️ effector
Мне нравится такой подход: создавать юниты эффектора в одном файле, а их взаимодействия - в другом.

Выглядит это так:
model.js - интерфейс модели (сущности),
init.js - модель поведения (связи)

Удобно, когда в одном файле описано, что из себя представляет модель. Заглянув в этот файл, можно  быстро получить представление о модели, её состояниях и методах, до погружения в бизнес-логику.  Создавая юниты в одном файле, мы описываем интерфейс модели (как интерфейс объекта в типах).

Получается, что вся логика  находится в одном файле (init), а создание сущностей мы выносим в отдельный (model), чтобы видеть структуру модели, т.е. что она из себя представляет. В итоге, интерфейс и поведение разделены.

Такой подход также позволяет импортить то, что тебе нужно, и не париться насчёт циклических зависимостей. Модели/подмодели могут перекрёстно зависеть друг от друга, это развязывает руки и упрощает работу - не нужно ломать голову каждый раз, что от чего должно зависеть, чтобы не было циклов.

В model у меня только создание…
я понял
источник

ф

фильтруй мысли... in ☄️ effector
я признаю, что могут существовать другие подходы
источник

AO

Aleksandr Osipov in ☄️ effector
фильтруй мысли
я признаю, что могут существовать другие подходы
ну так не интересно
источник

DS

Dmitriy Shuleshov in ☄️ effector
Aleksandr Osipov
например sample / guard имеют форму когда возвращают новый юнит
ивент из под криетора особенный
источник

ф

фильтруй мысли... in ☄️ effector
фильтруй мысли
просто я предпочитаю создавать ивенты явно, а не на лету
https://t.me/effector_ru/171965
Telegram
прими это in ☄️ effector
Мне нравится такой подход: создавать юниты эффектора в одном файле, а их взаимодействия - в другом.

Выглядит это так:
model.js - интерфейс модели (сущности),
init.js - модель поведения (связи)

Удобно, когда в одном файле описано, что из себя представляет модель. Заглянув в этот файл, можно  быстро получить представление о модели, её состояниях и методах, до погружения в бизнес-логику.  Создавая юниты в одном файле, мы описываем интерфейс модели (как интерфейс объекта в типах).

Получается, что вся логика  находится в одном файле (init), а создание сущностей мы выносим в отдельный (model), чтобы видеть структуру модели, т.е. что она из себя представляет. В итоге, интерфейс и поведение разделены.

Такой подход также позволяет импортить то, что тебе нужно, и не париться насчёт циклических зависимостей. Модели/подмодели могут перекрёстно зависеть друг от друга, это развязывает руки и упрощает работу - не нужно ломать голову каждый раз, что от чего должно зависеть, чтобы не было циклов.

В model у меня только создание…
хотя это не относится к вспомогательным ивентам 🤔, которые для внутреннего пользования и не экспортируются... явно создаются и экспортируются только ивенты описываемой модели
источник

AO

Aleksandr Osipov in ☄️ effector
Dmitriy Shuleshov
ивент из под криетора особенный
Это как?
источник

DS

Dmitriy Shuleshov in ☄️ effector
Aleksandr Osipov
Это как?
семантически
источник

AO

Aleksandr Osipov in ☄️ effector
Dmitriy Shuleshov
семантически
Не понимаю все равно, ивент как ивент же
источник

DS

Dmitriy Shuleshov in ☄️ effector
Ивент из под криетора - только через него должен заходить пейлоад в граф
источник

AO

Aleksandr Osipov in ☄️ effector
Ааа ты в плане что его не надо вызывать
источник

AO

Aleksandr Osipov in ☄️ effector
Aleksandr Osipov
Ааа ты в плане что его не надо вызывать
Если речь про merge/sample/guard
источник

AO

Aleksandr Osipov in ☄️ effector
Короче вопрос в направление движения ?
источник