Size: a a a

2020 July 30

ф

фильтруй мысли... in ☄️ effector
сторы, ивенты, эффекты
источник

B

Bogdan in ☄️ effector
фильтруй мысли
model - это интерфейс
импортить из других фич там можно?
источник

ф

фильтруй мысли... in ☄️ effector
Bogdan
импортить из других фич там можно?
Telegram
doasync in ☄️ effector
Мне нравится такой подход: создавать юниты эффектора в одном файле, а их взаимодействия - в другом.

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

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

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

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

c⁣

createStore<🦉>... in ☄️ effector
Dmitriy Shuleshov
Остается только вьюха, но это не от хорошей жизни, просто выбора нет
да есть выбор
источник

c⁣

createStore<🦉>... in ☄️ effector
фильтруй мысли
Telegram
doasync in ☄️ effector
Мне нравится такой подход: создавать юниты эффектора в одном файле, а их взаимодействия - в другом.

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

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

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

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

c⁣

createStore<🦉>... in ☄️ effector
я уж предпочту фичи связывать через специальный файл зависимостей
источник

DS

Dmitriy Shuleshov in ☄️ effector
Dmitriy Shuleshov
Поясню кейс как я понял.

Есть две фичи и мне нужно скомбайненый стор во вьюхе из двух фич.

Где его создавать?
источник

c⁣

createStore<🦉>... in ☄️ effector
Dmitriy Shuleshov
Поясню кейс как я понял.

Есть две фичи и мне нужно скомбайненый стор во вьюхе из двух фич.

Где его создавать?
в модели вьюхи
источник

ф

фильтруй мысли... in ☄️ effector
createStore<🦉> ⁣
а меня раздражает такое
а я кайфую)
источник

c⁣

createStore<🦉>... in ☄️ effector
¯\_(ツ)_/¯
источник

c⁣

createStore<🦉>... in ☄️ effector
со временем придешь
источник

B

Bogdan in ☄️ effector
фильтруй мысли
Telegram
doasync in ☄️ effector
Мне нравится такой подход: создавать юниты эффектора в одном файле, а их взаимодействия - в другом.

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

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

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

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

AI

Arthur Irgashev in ☄️ effector
фильтруй мысли
Мне нравится такой подход: создавать юниты эффектора в одном файле, а их взаимодействия - в другом.

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

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

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

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

ф

фильтруй мысли... in ☄️ effector
Arthur Irgashev
не нравится в этом подходе то, что нужно импортить эти init файлы
мне тоже не очень нравится
источник

ф

фильтруй мысли... in ☄️ effector
но лучше так
источник

YL

Yan👀 Lobaty in ☄️ effector
Dmitriy Shuleshov
Поясню кейс как я понял.

Есть две фичи и мне нужно скомбайненый стор во вьюхе из двух фич.

Где его создавать?
вьюха использует два стора и ей обязательно комбайнить их?)
источник

YL

Yan👀 Lobaty in ☄️ effector
пускай лучше автор проблемы скажет)
источник

ф

фильтруй мысли... in ☄️ effector
Bogdan
Чето я не понял. А перекрестно зависеть это разве не циклическая зависимость в чистом виде?
таком подход гарантирует отсутствие циклических зависимостей
источник

B

Bogdan in ☄️ effector
Yan👀 Lobaty
вьюха использует два стора и ей обязательно комбайнить их?)
Ну может и не обязательно. А зачем вообще тогда нужен combine? В такой организации он не нужен?
источник

YL

Yan👀 Lobaty in ☄️ effector
Bogdan
Ну может и не обязательно. А зачем вообще тогда нужен combine? В такой организации он не нужен?
ну получается что так
но в теории можно о многом рассуждать)
источник