Size: a a a

2020 November 02

R

Rafael 🦠 in ☄️ effector
Rafael 🦠
в state
const $store3 = createStore<blabla>(null)

в init
const $rawStore3 = combine($store1, $store2, (store1, store2) => {})
$store3.on($rawStore3, (_, state) => state)
вот пример того, что это легко обходится
источник

AS

Anton Sozonov in ☄️ effector
Dmitriy Shuleshov
С инитом тебе запрещены методы апи в которых создание юнита и связи - это одно действие
ну вот Рафаэль предложил выход через промежуточный стор. Если есть решение красивее, то отлично
источник

DS

Dmitriy Shuleshov in ☄️ effector
Rafael 🦠
типо я не вижу в этом проблем
А кто видит? Я описал факт.
источник

🦜

🦜 in ☄️ effector
ivan posokhin
ребят, guard же принимает в source объектную и array формы? в доке не написано, но есть подозрение, что должны быть
если в типах нет, значит и в доке не будет
источник

🦜

🦜 in ☄️ effector
тут такой подход
источник

🦜

🦜 in ☄️ effector
хотя сама фича будет работать для non-ts
источник

ip

ivan posokhin in ☄️ effector
🦜
если в типах нет, значит и в доке не будет
так вроде ж можно, если я правильно понял там combine внутри работает https://github.com/effector/effector/blob/9aa6fe584cc0751c24167e2ae4cbfbe3e6d710b1/src/effector/guard.ts#L27
источник

R

Rafael 🦠 in ☄️ effector
Dmitriy Shuleshov
А кто видит? Я описал факт.
это факт должен вести к чему-то
источник

R

Rafael 🦠 in ☄️ effector
у него должно быть какое-то следствие
источник

R

Rafael 🦠 in ☄️ effector
я пока что не понимание, какое следствие идет из твоего факта
источник

R

Rafael 🦠 in ☄️ effector
да, дейсвительно в одно действие это сделать не получится, но мешает ли оно? не мешает
источник

DS

Dmitriy Shuleshov in ☄️ effector
Rafael 🦠
это факт должен вести к чему-то
Стараться использовать при в котором только создание связей, семпл, он и тд
источник

R

Rafael 🦠 in ☄️ effector
Dmitriy Shuleshov
Стараться использовать при в котором только создание связей, семпл, он и тд
а почему нужно стараться это делать?
источник

DS

Dmitriy Shuleshov in ☄️ effector
Rafael 🦠
а почему нужно стараться это делать?
Что б не создавать дополнительные сущности
источник

ф

фильтруй мысли... in ☄️ effector
Anton Sozonov
Привет. Есть стор $store3 = combine($store1, $store2, (store1, store2) => {})

Хочу разделить создание стора и его редюсер. Что то типа подхода, который Дима советует с файлом init.js
Есть ли какой то способ это сделать?
можно создать $store3 в отдельном файле, а combine в init заменить сэмплом:

sample({
 source: [$store1, $store2],
 fn: ([store1, store2]) => {}),
 target: $store3,
})
источник

R

Rafael 🦠 in ☄️ effector
Dmitriy Shuleshov
Что б не создавать дополнительные сущности
ну это выглядит, в данном случае, как преждевременная оптимизация
источник

DS

Dmitriy Shuleshov in ☄️ effector
Rafael 🦠
ну это выглядит, в данном случае, как преждевременная оптимизация
Дело не в перфомансе, а в неясности намерений
источник

DS

Dmitriy Shuleshov in ☄️ effector
Поэтому Руслан и советует семпл
источник

ф

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

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

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

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

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

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

R

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

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

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

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

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

В model у меня только создание…
аналогичного подхода придерживаюсь
источник