Всегда не понимал зачем в одном компоненте делают два совершенно разных: dropdown и multidropdown. Они же совершенно по разному себя ведут, принимают разные данные на входе и при этом наврядли надо будет на форме переключать из мультиселекта в синглеслект. В этой статье не критично. Тут полезные приемы описаны чтобы это реализовать, но зачем это в реальности делать - не понятно.
Но можно было просто стандартизировать топики в MQTT. Тогда бы задача решалась очень просто.
Ведь уже написано много ПО для MQTT, которое, даже с учетом более общего назначения, было бы полезно и в умном доме - тот же nodeRed, библиотеки для разных языков программирования и платформ. А так скорее всего понадобится разрабоатывать аналогичные ПО и для Matter.
Интересно. Только не понятно что не хватает в уже существующем стандарте mqtt? В связке с zigbee вполне достаточно стандартов чтобы реализовать умный дом.
Хотя... единственно что не хватает - это связь голосового ассистента с mqtt.
Лично я свалил с абсолютного позиционирования из-за бесконечных проблем с z-index.
Как только начинается position: relative, то он внезапно становится поверх обычных элементов и создает свой контекст наложения, потом появляются z-index-ы, потом приходится вручную продумывать и конфигурировать какой элемент над каким находится. Вот тогда и начинается ужас.
Намного проще отдать эти расчеты браузеру просто расположив элементы в правильном месте в DOM дереве.
До флексов и гридов от абсолютного позиционирования нельзя было уйти, но после их появелния у меня лично сомненией не возникло - не хочется повторять негативный опыт с z-index.
Ну и не знаю как сейчас, но года 4 назад были жуткие тормоза из-за "position: relative" на мобильніх устройствах и переписывали тормозные участки на флексы.
Кстати по этому поводу заметил один недочет - собеседники не смотрят тебе в глаза когда с тобой разговаривают, т.к. расположение вебкамеры не совпадает с расположением картинки собеседника.
MVC и MVVM - первое что я попробовал когда ещё был студентом. Clean Architecture - тоже ещё один из вариантов набора слоев. Вы хотите сказать что я должен следовать именно этим подходам и не пытаться шагнуть в сторону?
Подозреваю, что мы вкладываем разный смысл в слово "слои", но хотелось бы все-таки больше конкретики, что вам не понравилось в статье?
А пока отвечу так:
А вы не пробовали разобраться полноценно в client-side архитектурах? Читая такие комментарии понимаешь, почему фронтендеры других client-side программистов(mobx) всерьёз не воспринимают. Разберитесь с FLUX, иммутабельностью, принципом единого источника истины, попробуйте однонаправленный поток данных и будет вам озарение и счастье) найдите например разницу ещё между css, jsx, js - будут слои и приложения любой сложности будут разрабатываться на изи)
FLUX с Redux или React hooks вообще божественно заходят.
Так же я не понимаю зачем строить эту отдельную иерархию акторов
Это, наверно, основная проблемма моей статьи — в том что я очень вскольз упамянул для чего это нужно и в каких ситуациях применяется. Думал это вынести в отдельную статью. Но попытаюсь объяснить тут.
Возьмем, например, ModalXActor — это призрак компонента ModalXComponent.
Причина 1. Разделили мы их потому что они будут состоять из разных блоков. Имеется ввиду не просто то что у актора будут блоки бизнесс логики, а у компонента будут блоки UI. Имеется ввиду, что они прям вообще не будут совпадать.
const ModalXActor = () => ghosts(
// загрузка в state.Book.
// Подписан на флаг "saving", по которому делает сохранение
ghost(BookActor),
// загрузка истории изменений книги в state.ChangesHistory
ghost(ChangesHistoryActor),
// загрузка коментариев и добавление новых в state.Comments
ghost(CommentsActor),
)
const ModalXComponent = () => <>
// выводит заголовок книги из state.Book
<Header>
<TabMenu> // диспатчит в state.tabs текущий выбраный таб
// выводит авторов книги из state.Book
// + историю изменений из state.ChangesHistory
{state.tabs.activetab === 'authors' && <TabBook>}
// выводит первую страницу из state.Book
// + историю изменений из state.ChangesHistory
{state.tabs.activetab === 'firstpage' && <TabBookFirstPage>}
<SaveButton> // диспатчит в state.Book флаг "saving = true" (см. BookActor)
</>
const TabBookFirstPage = () => <>
<FirstPage> // выводит первую страницу из state.Book)
<ChangesHistory> // выводит историю изменений из state.ChangesHistory
<Comments> // выводит историю изменений из state.Comments
</>
Как видите смысл появляется когда у нас два визуально разных таба и каждому нужен доступ к одному и тому-же стейту. Или наоборот одна кнопка «Save», а отпраивть на сохранение надо два разных стейта.
Причина 2. Мы можем переключатся между акторами ModalXActor и ModalYActor в фоне, и только когда данные будут готовы — начать переключаться между ModalXComponent в ModalYComponent. Либо паралельно и независимо от акторов анимировать переключение UI.
Причина 3. Мы можем легко сделать мобильную версию сайта. Это Вам не выдумывать как хакнуть стилями видимость компонентов адаптивной версткой — достаточно просто поменять компоненты в UI слое. Все что компоненты будут делать — это брать состояние со стора и диспатчить екшены. Логику переписывать не надо, т.к. скорее всего набор действий не будет отличатся и если и будет то только в меньшую сторону.
Может даже получится оставить бизнесс логику без изменений, а UI подставить для React Native.
На мой взгляд модель которая у вас получилась недотягивает до Actor model.
Я и не стремился реализовать именно эту модель (как минимум выдержать соответствие всем словам в определении).
Скорее наоборот, была идея и максимальным соответствующе слово, которое подошло — это Actor. Потому как, если, как вы заметили, включить фантазию на максимум, и «сообщение» приравнять к «информация» или «событие», то через общий стор можно и отправлять информацию и получать информацию/событие. А внутреннее состояние — не уверен что это вообще принципиально — useState я действительно не разу там не применил, но можно, например, контекст функции в useEffect считать внутренним состоянием.
Может показаться что я натянул сову на глобус, но это как раз тот случай когда сова хорошо на него налезла.
Actors are a sequence of functions which are called each time your store’s state change, with one important exception: they aren’t called in response to actions dispatched from other actors.
Акторы это последовательность функций, которые вызываются каждый раз когда изменяется состояние, с одним исключением — они не вызываются на действия задиспаченые другими акторами
Но в чем-то Вы тоже правы и может быть нужно другое название. Уже точно не помню, видимо поэтому год назад я назвал это «Призраком». Но мне показалось аудитории «Актор» будет более понятен.
Вроде и есть что вам ответить, но я почитал ваш троллинг в других статьях, и у меня пропало желание тратить время на общение с человеком, который всех во круг себя считает идиотами.
Ну почти. Отличие лишь в том, что хук не может участвовать в условных операторах, а актор (как и компонент) - может. Кроме того актора можно обернуть в React.memo.
Но замечание хорошее. Бизнес логику можно описывать в хуках, но до тех пор, пока не надо делать сложную композицию с условными вложениями друг в друга.
Я бы не был таким категоричным. На MobX перешли те, чьи взгляды совпали со взглядами создателей MobX. Я сознательно выбрал redux, так как для меня самым приоритетным условием есть хранение состояния в одном месте. На втором месте - простой просмотр и анализ этого состояния.
Если это единственная претензия к статье, тогда норм. Я думал, что что-то не так с моими знаниями в области редакса. Добавлю в заголовок слово "редакс", чтобы небыло намека в агитации перехода на редакс.
Да, неочень я выразился. Я имел ввиду библиотеки, которые вносят дополнительный опыт использования, который можно избежать используя уже подключенные библиотеки.
Переименование "компонент" на "актор" не идет в сравнение с добавлением новой библиотеки. Единственное соглашение - это не использовать jsx (то есть ничего не рендерить), а остальная теория и соглашения должны быть уже знакомы.
логично, что всю бизнес-логику (и синхронную, и асинхронную) мы выносим в Thunk (или Saga), а в Redux оставляем только состояние
Имеется ввиду, что нет смысла прогонять простое действие через thunk, если его можно сразу обработать в редюсере. И эти простые действия в моем понимании - это тоже бизнесс логика
Посыл в том что вместо добавления +1 библиотеки (например thunk) достаточно использовать useEffect, который уже есть в реактею. Просто этот useEffect надо вызывать не в UI слое, а в отдельном слое бизнесс логики
PS: извените не заметил контекст вашего вопроса, и ответил не на то
Посмотрел. Идея статьи в том чтобы не увеличивать базу знаний проекта. Зачем мне добавлять еще одну библиотеку, если для этого достаточно реакта с хуками?
Всегда не понимал зачем в одном компоненте делают два совершенно разных: dropdown и multidropdown. Они же совершенно по разному себя ведут, принимают разные данные на входе и при этом наврядли надо будет на форме переключать из мультиселекта в синглеслект.
В этой статье не критично. Тут полезные приемы описаны чтобы это реализовать, но зачем это в реальности делать - не понятно.
Спасибо за пояснения. Стало немного понятнее.
Но можно было просто стандартизировать топики в MQTT. Тогда бы задача решалась очень просто.
Ведь уже написано много ПО для MQTT, которое, даже с учетом более общего назначения, было бы полезно и в умном доме - тот же nodeRed, библиотеки для разных языков программирования и платформ. А так скорее всего понадобится разрабоатывать аналогичные ПО и для Matter.
Интересно. Только не понятно что не хватает в уже существующем стандарте mqtt? В связке с zigbee вполне достаточно стандартов чтобы реализовать умный дом.
Хотя... единственно что не хватает - это связь голосового ассистента с mqtt.
мне кстати запись
неочень нравится и действительно не очень понятна
Я у себя делаю именованный grid-area:
Сразу понятно что в этом элементе будут слои расположенные друг над другом.
Лично я свалил с абсолютного позиционирования из-за бесконечных проблем с z-index.
Как только начинается position: relative, то он внезапно становится поверх обычных элементов и создает свой контекст наложения, потом появляются z-index-ы, потом приходится вручную продумывать и конфигурировать какой элемент над каким находится. Вот тогда и начинается ужас.
Намного проще отдать эти расчеты браузеру просто расположив элементы в правильном месте в DOM дереве.
До флексов и гридов от абсолютного позиционирования нельзя было уйти, но после их появелния у меня лично сомненией не возникло - не хочется повторять негативный опыт с z-index.
Ну и не знаю как сейчас, но года 4 назад были жуткие тормоза из-за "position: relative" на мобильніх устройствах и переписывали тормозные участки на флексы.
Может это дело привычки, но помоему
выглядит гараздо понятнее, чем заклинание:
При этом в первом случае у меня остался неисползуемый "transform", который я могу использовать например для анимации.
Кстати по этому поводу заметил один недочет - собеседники не смотрят тебе в глаза когда с тобой разговаривают, т.к. расположение вебкамеры не совпадает с расположением картинки собеседника.
MVC и MVVM - первое что я попробовал когда ещё был студентом. Clean Architecture - тоже ещё один из вариантов набора слоев. Вы хотите сказать что я должен следовать именно этим подходам и не пытаться шагнуть в сторону?
Подозреваю, что мы вкладываем разный смысл в слово "слои", но хотелось бы все-таки больше конкретики, что вам не понравилось в статье?
А пока отвечу так:
А вы не пробовали разобраться полноценно в client-side архитектурах? Читая такие комментарии понимаешь, почему фронтендеры других client-side программистов(mobx) всерьёз не воспринимают. Разберитесь с FLUX, иммутабельностью, принципом единого источника истины, попробуйте однонаправленный поток данных и будет вам озарение и счастье) найдите например разницу ещё между css, jsx, js - будут слои и приложения любой сложности будут разрабатываться на изи)
FLUX с Redux или React hooks вообще божественно заходят.
Возьмем, например, ModalXActor — это призрак компонента ModalXComponent.
Причина 1. Разделили мы их потому что они будут состоять из разных блоков. Имеется ввиду не просто то что у актора будут блоки бизнесс логики, а у компонента будут блоки UI. Имеется ввиду, что они прям вообще не будут совпадать.
Как видите смысл появляется когда у нас два визуально разных таба и каждому нужен доступ к одному и тому-же стейту. Или наоборот одна кнопка «Save», а отпраивть на сохранение надо два разных стейта.
Причина 2. Мы можем переключатся между акторами ModalXActor и ModalYActor в фоне, и только когда данные будут готовы — начать переключаться между ModalXComponent в ModalYComponent. Либо паралельно и независимо от акторов анимировать переключение UI.
Причина 3. Мы можем легко сделать мобильную версию сайта. Это Вам не выдумывать как хакнуть стилями видимость компонентов адаптивной версткой — достаточно просто поменять компоненты в UI слое. Все что компоненты будут делать — это брать состояние со стора и диспатчить екшены. Логику переписывать не надо, т.к. скорее всего набор действий не будет отличатся и если и будет то только в меньшую сторону.
Может даже получится оставить бизнесс логику без изменений, а UI подставить для React Native.
Я и не стремился реализовать именно эту модель (как минимум выдержать соответствие всем словам в определении).
Скорее наоборот, была идея и максимальным соответствующе слово, которое подошло — это Actor. Потому как, если, как вы заметили, включить фантазию на максимум, и «сообщение» приравнять к «информация» или «событие», то через общий стор можно и отправлять информацию и получать информацию/событие. А внутреннее состояние — не уверен что это вообще принципиально — useState я действительно не разу там не применил, но можно, например, контекст функции в useEffect считать внутренним состоянием.
Может показаться что я натянул сову на глобус, но это как раз тот случай когда сова хорошо на него налезла.
Вот, например, одна из статей, которая меня к этому подтолкнула:
Join The Dark Side Of The Flux: Responding to Actions with Actors
Там это так описывалось:
Но в чем-то Вы тоже правы и может быть нужно другое название. Уже точно не помню, видимо поэтому год назад я назвал это «Призраком». Но мне показалось аудитории «Актор» будет более понятен.
Извините, но вы как-то неадекватно общаетесь.
Вроде и есть что вам ответить, но я почитал ваш троллинг в других статьях, и у меня пропало желание тратить время на общение с человеком, который всех во круг себя считает идиотами.
Ну почти. Отличие лишь в том, что хук не может участвовать в условных операторах, а актор (как и компонент) - может. Кроме того актора можно обернуть в React.memo.
Но замечание хорошее. Бизнес логику можно описывать в хуках, но до тех пор, пока не надо делать сложную композицию с условными вложениями друг в друга.
Я бы не был таким категоричным. На MobX перешли те, чьи взгляды совпали со взглядами создателей MobX.
Я сознательно выбрал redux, так как для меня самым приоритетным условием есть хранение состояния в одном месте. На втором месте - простой просмотр и анализ этого состояния.
Если это единственная претензия к статье, тогда норм. Я думал, что что-то не так с моими знаниями в области редакса.
Добавлю в заголовок слово "редакс", чтобы небыло намека в агитации перехода на редакс.
да
Тем что вносит значительно меньше дополнительного опыта
Да, неочень я выразился. Я имел ввиду библиотеки, которые вносят дополнительный опыт использования, который можно избежать используя уже подключенные библиотеки.
Переименование "компонент" на "актор" не идет в сравнение с добавлением новой библиотеки. Единственное соглашение - это не использовать jsx (то есть ничего не рендерить), а остальная теория и соглашения должны быть уже знакомы.
Имеется ввиду, что нет смысла прогонять простое действие через thunk, если его можно сразу обработать в редюсере. И эти простые действия в моем понимании - это тоже бизнесс логика
Посыл в том что вместо добавления +1 библиотеки (например thunk) достаточно использовать useEffect, который уже есть в реактею. Просто этот useEffect надо вызывать не в UI слое, а в отдельном слое бизнесс логики
PS: извените не заметил контекст вашего вопроса, и ответил не на то
Посмотрел. Идея статьи в том чтобы не увеличивать базу знаний проекта. Зачем мне добавлять еще одну библиотеку, если для этого достаточно реакта с хуками?