ф
Aleksandr Osipov
Вот смотрю и не пойму как это будет работать?
ниже объяснил
Size: a a a
2020 July 17
AO
типа возмент последнее значение с котоырм событие вызвано было?
AO
а все увидел, спасибо
c
Наверное правильнее было бы стор с счетчиком держать
fx.inFlight
2020 July 18
DS
Всем привет, имеет смысл создавать в каждой фиче файл например state.js для хранения там всех сторов данной фичи?
c
Всем привет, имеет смысл создавать в каждой фиче файл например state.js для хранения там всех сторов данной фичи?
нет
c
гораздо проще будет создавать сторы там где они нужны и логичны для чтения
DS
гораздо проще будет создавать сторы там где они нужны и логичны для чтения
понял, спасибо большое
🅅🄺
Всем привет, имеет смысл создавать в каждой фиче файл например state.js для хранения там всех сторов данной фичи?
так у каждой фичи может быть несколько моделей данных
я на модели разбиваю папку фичи и уже внутри каждой свой state, init, index
я на модели разбиваю папку фичи и уже внутри каждой свой state, init, index
ф
Всем привет, имеет смысл создавать в каждой фиче файл например state.js для хранения там всех сторов данной фичи?
Мне нравится такой подход: создавать юниты эффектора в одном файле, а их взаимодействия - в другом.
Выглядит это так:
model.js - интерфейс модели (сущности),
init.js - модель поведения (связи)
Удобно, когда в одном файле описано, что из себя представляет модель. Заглянув в этот файл, можно быстро получить представление о модели, её состояниях и методах, до погружения в бизнес-логику. Создавая юниты в одном файле, мы описываем интерфейс модели (как интерфейс объекта в типах).
Получается, что вся логика находится в одном файле (init), а создание сущностей мы выносим в отдельный (model), чтобы видеть структуру модели, т.е. что она из себя представляет. В итоге, интерфейс и поведение разделены.
Такой подход также позволяет импортить то, что тебе нужно, и не париться насчёт циклических зависимостей. Модели/подмодели могут перекрёстно зависеть друг от друга, это развязывает руки и упрощает работу - не нужно ломать голову каждый раз, что от чего должно зависеть, чтобы не было циклов.
Выглядит это так:
model.js - интерфейс модели (сущности),
init.js - модель поведения (связи)
Удобно, когда в одном файле описано, что из себя представляет модель. Заглянув в этот файл, можно быстро получить представление о модели, её состояниях и методах, до погружения в бизнес-логику. Создавая юниты в одном файле, мы описываем интерфейс модели (как интерфейс объекта в типах).
Получается, что вся логика находится в одном файле (init), а создание сущностей мы выносим в отдельный (model), чтобы видеть структуру модели, т.е. что она из себя представляет. В итоге, интерфейс и поведение разделены.
Такой подход также позволяет импортить то, что тебе нужно, и не париться насчёт циклических зависимостей. Модели/подмодели могут перекрёстно зависеть друг от друга, это развязывает руки и упрощает работу - не нужно ломать голову каждый раз, что от чего должно зависеть, чтобы не было циклов.
DS
Мне нравится такой подход: создавать юниты эффектора в одном файле, а их взаимодействия - в другом.
Выглядит это так:
model.js - интерфейс модели (сущности),
init.js - модель поведения (связи)
Удобно, когда в одном файле описано, что из себя представляет модель. Заглянув в этот файл, можно быстро получить представление о модели, её состояниях и методах, до погружения в бизнес-логику. Создавая юниты в одном файле, мы описываем интерфейс модели (как интерфейс объекта в типах).
Получается, что вся логика находится в одном файле (init), а создание сущностей мы выносим в отдельный (model), чтобы видеть структуру модели, т.е. что она из себя представляет. В итоге, интерфейс и поведение разделены.
Такой подход также позволяет импортить то, что тебе нужно, и не париться насчёт циклических зависимостей. Модели/подмодели могут перекрёстно зависеть друг от друга, это развязывает руки и упрощает работу - не нужно ломать голову каждый раз, что от чего должно зависеть, чтобы не было циклов.
Выглядит это так:
model.js - интерфейс модели (сущности),
init.js - модель поведения (связи)
Удобно, когда в одном файле описано, что из себя представляет модель. Заглянув в этот файл, можно быстро получить представление о модели, её состояниях и методах, до погружения в бизнес-логику. Создавая юниты в одном файле, мы описываем интерфейс модели (как интерфейс объекта в типах).
Получается, что вся логика находится в одном файле (init), а создание сущностей мы выносим в отдельный (model), чтобы видеть структуру модели, т.е. что она из себя представляет. В итоге, интерфейс и поведение разделены.
Такой подход также позволяет импортить то, что тебе нужно, и не париться насчёт циклических зависимостей. Модели/подмодели могут перекрёстно зависеть друг от друга, это развязывает руки и упрощает работу - не нужно ломать голову каждый раз, что от чего должно зависеть, чтобы не было циклов.
Спасибо, я понял. Обязательно попробую такой подход.
ф
В model у меня только создание юнитов! Там нет restore, createApi. Также нет .map и combine - они описываются через .on и sample (в init файле).
В init у меня взаимодействия сущностей друг с другом, .on, .use, sample, guard, то есть вся бизнес-логика модели. Из init ничего не экспортируется! В нём можно создавать вспомогательные юниты (для внутреннего использования) через .map, combine. Все init-ы импортируются в index файле на уровень выше либо в где-нибудь корне.
В init у меня взаимодействия сущностей друг с другом, .on, .use, sample, guard, то есть вся бизнес-логика модели. Из init ничего не экспортируется! В нём можно создавать вспомогательные юниты (для внутреннего использования) через .map, combine. Все init-ы импортируются в index файле на уровень выше либо в где-нибудь корне.
DS
В model у меня только создание юнитов! Там нет restore, createApi. Также нет .map и combine - они описываются через .on и sample (в init файле).
В init у меня взаимодействия сущностей друг с другом, .on, .use, sample, guard, то есть вся бизнес-логика модели. Из init ничего не экспортируется! В нём можно создавать вспомогательные юниты (для внутреннего использования) через .map, combine. Все init-ы импортируются в index файле на уровень выше либо в где-нибудь корне.
В init у меня взаимодействия сущностей друг с другом, .on, .use, sample, guard, то есть вся бизнес-логика модели. Из init ничего не экспортируется! В нём можно создавать вспомогательные юниты (для внутреннего использования) через .map, combine. Все init-ы импортируются в index файле на уровень выше либо в где-нибудь корне.
А как кстати называешь этот файл перекрестных зависимостей?
🦜
А как кстати называешь этот файл перекрестных зависимостей?
Я называю bridge
ф
А как кстати называешь этот файл перекрестных зависимостей?
нет такого файла
🦜
Но там в основном форварды ивентов публичных
DS
нет такого файла
Если будет 50 инитов, то все в корень импортим?
SS
SS
Здравствуйте, вот нормально создавать компоненты в реакте? Есть скрипт на ноде который следит за папкой, создает файлы и заполняет их
SS
Что можно убрать, добавить, извиняюсь за оффтоп