Я как раз и старался в статье описать, почему применили именно такой подход :)
По сути, это и есть "брейкпойнты и фиксированные раскладки". Но брейкпойнты в рамках компонента, а не в рамках приложения. Подобные технологии часто применяют в других платформах, где компонент - что-то более фундаментальное, чем в вебе (тут слишком принято через css дотягиваться "куда угодно" в архитектуре). В качестве яркого примера - flutter, где виджет явно адаптируется под "выделенное" ему место.
Если мы попробуем сделать это на каком-то другом уровне (например, когда колонка размера X, применяем стиль Y к кнопке "написать письмо"), то получим плохо поддерживаемые селекторы в css на родительский класс + компонент, и кнопку, которую очень дорого будет просто передвинуть на другое место в интерфейсе. Да что там, даже для того чтобы добавить ей отступы - может понадобиться менять брейкпойнты.
Плюс, когда Container Queries таки выпустят - переход на них с такого подхода будет организовать очень даже просто. Они реализуют такую же возможность. Правда, когда писался этот код (статью выпускали не сразу), они были только в состоянии intent-to-prototype. А вот сейчас, даже когда реализации ещё нет ни в одном браузере, уже постепенно появляются полифиллы.
Что касается mobx — тут есть одно большое "но". Примеры-то на react…
Что означает что вы грузите react. И хоть сам react может заманчиво прикидываться 7-килобайтной библиотекой, примерно как redux, но это не так :) https://bundlephobia.com/result?p=react-dom@17.0.1
Т.е. выигрыш будет мизерным по сравнению с размером ui-фреймворка. Если проект реально маленький (и планируется его оставить таким) и время загрузки важно — можно взять vue/svelte.
Если же нет — качественный код лучше чем быстрый. Оптимизировать всегда успеете, обещаю :)
По второму пункту (рантайм-перформансу) — скажу честно, пока проект маленький, вы этого просто не заметите.
Но когда подрастет — накопится.
У redux тут есть известные боттлнеки и правда, когда в connect привязано слишком много компонентов.
Насчет effector — не возьмусь говорить, тк пока не понятно как выглядит "хорошая архитектура" на этом стейт-менеджере. Пока никто не возьмет его в продакшен-проект крупного масштаба, авторы библиотеки и дальше смогут говорить что перформанс хорош)
А у mobx тут всё хорошо. Всё в итоге сводится к тому что точечные обновления куда эффективнее чем обновлять целое поддерево компонентов.
"Плюсы" по сравнению с mobx
Нет надобности создавать отдельные классы-модели, прописывать им интерфейсы. Создали хранилище, создали событие, подписали событие на хранилище — готово!
Откровенно не понимаю что имеется в виду.
Да, пожалуй, если вы пишете на чистом js — можно ничего не писать и кидаться объектами без сигнатуры. Но интерфейс же например для юзера описан даже в статье. Просто в mobx он был бы например вероятно описан в классе. Не вижу тут разницы в boilerplatе.
А если речь о том что тут 2 стора вместо 2 свойств на классе — то это явно вкусовщина. Ну было бы не 2 переменные а 2 свойства, количество кода бы не изменилось, просто название писать в другом месте.
При грамотно созданных моделях в компоненте не нужно страдать и отслеживать все свои телодвижения по обновлению хранилища. Подключили его в компонент — он всегда актуален и перерисовывается при каждом обновлении хранилища. Никаких тебе Mobx-овых @action, @computed и прочей ручной настройки
Так в mobx тоже же нет ручной настройки в компоненте. @action, @computed — это про модель. И это не ручная настройка, это тот же самый бойлерплейт.
А в mobx@6 реально уже есть makeAutoObservable, т.е. декораторы можно и не писать.
Да и в целом в проекте я использовала версию Effector 21.5.0. То есть ребята мажорно обновляли свой проект 20 раз. Это очень существенно!
Это не то что бы хорошо) Мажорная версия по определению — версия ломающая обратную совместимость.
Т.е. ребята за такой короткий срок сломали обратную совместимость 2 десятка раз. Тот же реакт развился колоссально, за очень долгий срок, и имеет всего 17 мажоров.
Если же выпускать по 2 мажора в месяц — обновление зависимостей для пользователей твоей библиотеки превратится в ад.
Итого
Если дать выжимку ощущения от статьи — кажется что все "недостатки" mobx (кроме может быть размера, но про то что это вряд ли важно в данном конкретном случае я написал выше) — очень субъективные негативные впечатления, вызванные совершенно другими вещами (aka непонимание какую логику в mobx надо уносить в модель и как), а не реальные проблемы фреймворка.
Вероятно то что mobx дает возможность писать "честные" классы, сбило автора с пути и заставило думать что в mobx принято делать действия в компонентах, но это не так. В целом правильный пример работы, например, со статусом запроса в mobx куда ближе к тому что есть в effector (записываем текущий статус в observable поле модели, в компоненте используем только его, не используем промис, не делаем запрос из модели).
Что касается того примеров effector в статье — он кажется слишком громоздким чтобы быть user-friendly. Уменьшение boilerplate-кода со стороны незаметно, а вот выросшая сложность чтения кода — да.
Судя по всему библиотека стремится предоставить утилиты на все случаи жизни, но при этом к сожалению забывает что главное в коде — читаемость, а не размер.
Я как раз и старался в статье описать, почему применили именно такой подход :)
По сути, это и есть "брейкпойнты и фиксированные раскладки". Но брейкпойнты в рамках компонента, а не в рамках приложения. Подобные технологии часто применяют в других платформах, где компонент - что-то более фундаментальное, чем в вебе (тут слишком принято через css дотягиваться "куда угодно" в архитектуре). В качестве яркого примера - flutter, где виджет явно адаптируется под "выделенное" ему место.
Если мы попробуем сделать это на каком-то другом уровне (например, когда колонка размера X, применяем стиль Y к кнопке "написать письмо"), то получим плохо поддерживаемые селекторы в css на родительский класс + компонент, и кнопку, которую очень дорого будет просто передвинуть на другое место в интерфейсе. Да что там, даже для того чтобы добавить ей отступы - может понадобиться менять брейкпойнты.
Плюс, когда Container Queries таки выпустят - переход на них с такого подхода будет организовать очень даже просто. Они реализуют такую же возможность. Правда, когда писался этот код (статью выпускали не сразу), они были только в состоянии intent-to-prototype. А вот сейчас, даже когда реализации ещё нет ни в одном браузере, уже постепенно появляются полифиллы.
Двоякие впечатления от статьи, с одной стороны написано очень приятно, с другой — с посылом я полностью не согласен)
Так что хочется дать конструктивный фидбек без негатива. Давайте по пунктам, что имхо не так.
Производительность.
"Производительность" библиотеки это по факту 2 вещи:
По первому пункту (размеру) эффектор выигрывает. Но только у mobx.
Приведенный размер правда неверный — https://bundlephobia.com/result?p=effector@21.7.5
Но и правда разница с mobx в 2 с лишним раза — https://bundlephobia.com/result?p=mobx@6.0.4
А вот redux меньше — https://bundlephobia.com/result?p=redux@4.0.5
Что касается mobx — тут есть одно большое "но". Примеры-то на react…
Что означает что вы грузите react. И хоть сам react может заманчиво прикидываться 7-килобайтной библиотекой, примерно как redux, но это не так :)
https://bundlephobia.com/result?p=react-dom@17.0.1
Т.е. выигрыш будет мизерным по сравнению с размером ui-фреймворка. Если проект реально маленький (и планируется его оставить таким) и время загрузки важно — можно взять vue/svelte.
Если же нет — качественный код лучше чем быстрый. Оптимизировать всегда успеете, обещаю :)
По второму пункту (рантайм-перформансу) — скажу честно, пока проект маленький, вы этого просто не заметите.
Но когда подрастет — накопится.
У redux тут есть известные боттлнеки и правда, когда в connect привязано слишком много компонентов.
Насчет effector — не возьмусь говорить, тк пока не понятно как выглядит "хорошая архитектура" на этом стейт-менеджере. Пока никто не возьмет его в продакшен-проект крупного масштаба, авторы библиотеки и дальше смогут говорить что перформанс хорош)
А у mobx тут всё хорошо. Всё в итоге сводится к тому что точечные обновления куда эффективнее чем обновлять целое поддерево компонентов.
"Плюсы" по сравнению с mobx
Откровенно не понимаю что имеется в виду.
Да, пожалуй, если вы пишете на чистом js — можно ничего не писать и кидаться объектами без сигнатуры. Но интерфейс же например для юзера описан даже в статье. Просто в mobx он был бы например вероятно описан в классе. Не вижу тут разницы в boilerplatе.
А если речь о том что тут 2 стора вместо 2 свойств на классе — то это явно вкусовщина. Ну было бы не 2 переменные а 2 свойства, количество кода бы не изменилось, просто название писать в другом месте.
Так в mobx тоже же нет ручной настройки в компоненте.
@action,@computed— это про модель. И это не ручная настройка, это тот же самый бойлерплейт.А в mobx@6 реально уже есть makeAutoObservable, т.е. декораторы можно и не писать.
Это не то что бы хорошо) Мажорная версия по определению — версия ломающая обратную совместимость.
Т.е. ребята за такой короткий срок сломали обратную совместимость 2 десятка раз. Тот же реакт развился колоссально, за очень долгий срок, и имеет всего 17 мажоров.
Если же выпускать по 2 мажора в месяц — обновление зависимостей для пользователей твоей библиотеки превратится в ад.
Итого
Если дать выжимку ощущения от статьи — кажется что все "недостатки" mobx (кроме может быть размера, но про то что это вряд ли важно в данном конкретном случае я написал выше) — очень субъективные негативные впечатления, вызванные совершенно другими вещами (aka непонимание какую логику в mobx надо уносить в модель и как), а не реальные проблемы фреймворка.
Вероятно то что mobx дает возможность писать "честные" классы, сбило автора с пути и заставило думать что в mobx принято делать действия в компонентах, но это не так. В целом правильный пример работы, например, со статусом запроса в mobx куда ближе к тому что есть в effector (записываем текущий статус в observable поле модели, в компоненте используем только его, не используем промис, не делаем запрос из модели).
Что касается того примеров effector в статье — он кажется слишком громоздким чтобы быть user-friendly. Уменьшение boilerplate-кода со стороны незаметно, а вот выросшая сложность чтения кода — да.
Судя по всему библиотека стремится предоставить утилиты на все случаи жизни, но при этом к сожалению забывает что главное в коде — читаемость, а не размер.