Комментарии 9
Если ты искал способ упростить логику «запрос — результат — отображение» и при этом не хотел городить огород из
useState, useActionState может стать тем самым «Ах, вот оно!».
С 2017 года можно все делать намного лучше и проще, а главное супер гибко просто тупо используя MobX в связке с React'ом.
React по сей день в плане управлением состоянием это просто ничтожество. Смотреть на эти жалкие попытки добавления новых функций смешно)
Для тех кто использует MobX нет разницы какой версии react использовать 16,17,18,19.
Спасибо за комментарий!
Конечно, у MobX есть свои неоспоримые преимущества - он удобен для организации гибкого и реактивного стейт-менеджмента, особенно когда в приложении много взаимосвязанных состояний и сложная бизнес-логика. Однако у каждой задачи свои масштабы и особенности.
Локальные экшены и формы. Когда речь идёт об обработке единичного действия (отправка формы, загрузка файла и т. п.), не всегда хочется поднимать глобальное хранилище, прописывать сторы, экшены и т. д. проще зацепить локальный хук и закрыть задачу за пару строк. В таких случаях удобнее иметь что-то вроде
useActionState, которое интегрировано в экосистему React.Server Components призваны минимизировать клиентскую часть и ускорить загрузку. Некоторые фреймворки (например, Next.js) поддерживают это «из коробки».
useActionStateвстроен в эту концепцию, позволяя обрабатывать действия еще до гидратации.Никто не заставляет бросать MobX - в крупных проектах, где уже есть MobX, Redux, Zustand и пр., можно совмещать их с хуками. Всё зависит от того, какой подход более оптимален в конкретном месте приложения.
Так что выбор инструмента всегда сводится к балансированию между гибкостью, скоростью разработки и сложностью задачи. MobX отлично покрывает определённые сценарии, React-хуки - другие. Здорово, что у нас теперь есть несколько инструментов на выбор, а не «один-единственный фреймворк на все случаи жизни».
не всегда хочется поднимать глобальное хранилище
Зачем? Если нужно локальное, просто используйте локальное. Вот так:
const MyCompoent = observer((props: IMyCompoentProps) => {
const [state] = useState(() => MyCompoentLocalState(props));
state.props = props;
return <div>123</div>
});И все дела.
прописывать сторы, экшены и т. д.
Зачем эта грязь? Все автоматом делается.
class MyCompoentLocalState {
props: IMyCompoentProps = null;
constructor(props) {
makeAutoObservable(this);
this.props = props;
}
someFunction = async () => {
//...
}
someFunction2 = () => {
//...
}
}И все дела. Все максимально чисто и предельно структурировано и понятно, всем и всегда. Т.к. по сути это тупо нативный код.
Server Components призваны минимизировать клиентскую часть и ускорить загрузку.
Актуально исключительно в проектах где нужно SEO и то, только для страниц нужных для SEO. В остальных случаях бесполезно и пагубно влияет на производительность, особенно в плане нагрузки на сервера, они стоят денег. Плюс всё что закрыто авторизацией так же не нуждается в серверном рендеринге и SEO.
Писать реакт на классах норм?
Неплохой пример, спасибо, что поделились! Но, как и в любом обсуждении инструментов и подходов к архитектуре, всё упирается в задачу и контекст. Постараюсь пояснить, почему в статье речь шла именно о хуках и Server Components, а не о MobX.
Отсутствие необходимости в «глобальном сторе» ≠ отсутствие Mob. Вы правы в MobX никто не заставляет "тащить" глобальное хранилище. Можно завести локальный класс со makeAutoObservable. Но часто, когда люди говорят "не хочу поднимать глобальный стейт-менеджер", они имеют в виду "не хочу тащить дополнительную библиотеку и выделять под неё архитектурные паттерны". В React-проектах нередко принцип "взял хук и быстро сделал" срабатывает быстрее и понятнее (особенно если разработчики внутри команды не все знают/любят MobX).
Импорт дополнительных инструментов. Для кого-то MobX - уже привычная вещь и "ничего дополнительно тянуть" не надо. Для кого-то - наоборот, любое добавление библиотеки и написание классов/декораторов - overhead, если задачу можно решить встроенными средствами React. Согласитесь, если нужно просто отправить форму и показать лоадер - это решается одним хуком, без дополнительной конфигурации.
Server Components не только про SEO. Их суть - не столько в том, чтобы «прокачать» SEO (хотя это полезный бонус), сколько в разделении кода между клиентом и сервером, чтобы ускорять загрузку и держать часть логики на сервере (даже если контент защищён авторизацией). В Next.js 13+, например, часто используют серверные роуты и "серверные экшены", чтобы разгрузить клиентский бандл и эффективнее кешировать данные.
Например, если у вас тяжеленные запросы к базе и много кода для формирования HTML, это можно "снять" с клиента: пользователь быстрее видит результат, а JS-бандл уменьшается. Конечно, серверная инфраструктура тоже стоит денег, так что каждый проект выбирает, где и когда это оправданно. Но в целом RSC - это не просто "SSR ради SEO", а новый способ смешивать клиентский и серверный рендеринг, улучшая UX.
Так же у разных команд разные стили. MobX - отличный инструмент, особенно для крупных проектов, где нужно много реактивных сто̀ров с живой моделью данных. Но не все команды хотят или могут его использовать (например, из-за политики компании, из-за незнания инструмента, или просто потому что устраивает natively встроенная механика хуков).
В статье про useActionState речь шла о сугубо реактовом решении, которое встроено в официальный API. Для многих команд это решающий аргумент - они предпочитают официоз, чтобы не плодить разные библиотеки.
Но часто, когда люди говорят "не хочу поднимать глобальный стейт-менеджер", они имеют в виду "не хочу тащить дополнительную библиотеку и выделять под неё архитектурные паттерны".
Иными словами они говорят - я намеренно буду писать грязный и неудобный код, сталкиваться с ограничениями, вместо того, чтобы писать чистый, интуитивно понятный код. Молодцы эти люди, ничего не скажешь.
В React-проектах нередко принцип "взял хук и быстро сделал" срабатывает быстрее и понятнее (особенно если разработчики внутри команды не все знают/любят MobX).
Проектах? "Проекты" с таким подходом знаете кто пишет? Думаю и сами догадываетесь. Тем более MobX не надо знать, достаточно уделить 30 минут и всё станет предельно понятно для 99% случаев, в остальных 1% можно ещё 30 минут минут времени уделить и всё, вы знаток MobX. Чтобы писать makeAutoObservable в конструкторе класса и заворачивать компоненты в observer много ума и изучения не надо. 30 минут это прям с запасом. В остальных случая нужны только reaction , autorun , when ну и configure чтобы сделать автобатчинг по умолчанию и сделать enforceActions: "never".
Вот:
https://stackblitz.com/edit/vitejs-vite-dspjoj?file=src%2FApp.tsx&terminal=dev
Всё до безобразия просто, кинув тому, кто первый раз видит MobX этот пример, он через 5-10 минут уже может вполне клепать проекты используя его.
Server Components не только про SEO. Их суть - не столько в том, чтобы «прокачать» SEO (хотя это полезный бонус), сколько в разделении кода между клиентом и сервером, чтобы ускорять загрузку и держать часть логики на сервере (даже если контент защищён авторизацией). В Next.js 13+, например, часто используют серверные роуты и "серверные экшены", чтобы разгрузить клиентский бандл и эффективнее кешировать данные.
Да, все эти громкие заявления я 100 раз видел и видел все это многократно на практике, и практика показывает что никакого ускорения для пользователя нет, в лучшем случае скорость та же. А вот геморроя в разработке и ограничений это добавляет знатно. Итого, использовать это можно только в острой необходимости, а именно если нужно SEO. И то, есть механизмы лучше.
Но не все команды хотят или могут его использовать (например, из-за политики компании, из-за незнания инструмента, или просто потому что устраивает natively встроенная механика хуков).
Ну это абсурд. Взгляните на пример выше. 5-10 минут и вы знаете MobX. Ещё час и вы мастер, а просто разработав 1 проект с ним вы уже ас.
В статье про
useActionStateречь шла о сугубо реактовом решении, которое встроено в официальный API. Для многих команд это решающий аргумент - они предпочитают официоз, чтобы не плодить разные библиотеки.
Так оно кривое, как и все что связано с управлением состоянием встроенными в реакт способами. Если вы используете реакт и т.п., вы уже как вы говорите плодите библиотеки. Поэтому какая разница одной больше или одной меньше?
Преднамеренно стрелять себе в ноги, это конечно удел "великих" команд и компаний. Да, такие существуют(к сожалению), я знаю. Обязательно "берем" с них пример.
Есть люди которые питаются исключительно энергией солнца, они не хотят в своем желудки плодить еду, тем более разную. Их тоже будем рассматривать как аргументы в пользу того чтобы не есть?)
Спасибо за ваш развернутый комментарий! Видно, что вы отлично знакомы с MobX и ценно делитесь опытом 👍. Позвольте немного уточнить позицию, которую я хотел отразить в статье, и почему всё же имеет смысл рассматривать useActionState и подход с Server Components.
"Просто взять и выучить MobX" Соглашусь, MobX действительно можно достаточно быстро освоить для базовых сценариев. Тем не менее в реальных командах (особенно в больших проектах) выбор инструмента не всегда сводится к личному желанию или времени на обучение. Часто есть корпоративные стандарты, legacy-проекты, где нет возможности добавлять новые библиотеки, или коллеги, которые предпочитают оставаться в «официальной экосистеме React» без сторонних зависимостей. В таких ситуациях useActionState (и другие встроенные инструменты) могут быть более удобны — не потому что они лучше или хуже, а потому что они подходят под процессы и политику конкретной команды.
Использование штатного API (например, useState, useReducer, useActionState) - это не всегда "стрельба в ногу". Для небольших и средних задач без сложных взаимосвязей зачастую достаточно встроенных инструментов, и они позволяют быстро закрыть потребности. Когда же проект разрастается и возникает потребность в богатой реактивности, MobX (или другой стейт-менеджер) может отлично вписаться. Но далеко не всем нравится тянуть дополнительную абстракцию, особенно если задача элементарная и решается двумя строчками встроенного хука.
Да, все эти громкие заявления я 100 раз видел и видел все это многократно на практике, и практика показывает что никакого ускорения для пользователя нет, в лучшем случае скорость та же. А вот геморроя в разработке и ограничений это добавляет знатно. Итого, использовать это можно только в острой необходимости, а именно если нужно SEO. И то, есть механизмы лучше.
На практике всё зависит от архитектуры и конкретного проекта: для одного кейса Server Components могут не дать особого прироста, а для другого — значительно снизить время до первого контента или вес клиентского бандла.К примеру, если у вас большие объёмы данных, которые нужно рендерить только на сервере, и вы стремитесь разгрузить клиентскую часть, Server Components могут быть полезны. Как и любой инструмент, они не волшебная палочка, а один из вариантов решения задач.
Почему кто-то предпочитает официал?!
- Для многих команд важна единообразность стека: "чем меньше сторонних библиотек, тем проще поддерживать проект".
- Если React внедрён на уровне компании в десятках сервисов, использование сугубо React-инструментов (пусть даже кажущихся кому-то кривыми) даёт предсказуемость и стабильность кода при миграциях, обновлениях и обучении новых сотрудников.
- Команда React активно развивает Server Actions и Server Components, и есть предпосылки, что в будущем этот подход станет одним из основных. Освоить его уже сейчас - для кого-то стратегическое решение.
В конечном итоге, спор MobX vs React hooks vs что-то ещё упирается в то, какую задачу мы решаем и в каком контексте. MobX - отличный инструмент, дающий простую реактивность и масштабируемость. Но есть и контр-примеры: когда избыточно поднимать MobX, если нужно один раз отправить форму и показать лоадер.
Поэтому логика выбора зачастую такая:
Небольшой локальный функционал (один экшен, пара состояний) - React-хук: быстро, без сторонних зависимостей.
Крупная бизнес-логика, модель данных, много взаимосвязанных сущностей — MobX, Redux, Zustand и т. д.
Server Components - когда важны быстрая отрисовка, разделение кода между сервером и клиентом, а также использование серверных экшенов.
Я понимаю вашу точку зрения: MobX действительно способен на многое и при должном подходе упрощает множество аспектов разработки. Но в статье я хотел показать, что у самого React теперь тоже появились инструменты, которые могут закрывать определённые типовые сценарии без привлечения дополнительных библиотек. Это не значит, что MobX или любой другой менеджер состояния плохие - это лишь говорит о том, что выбор инструмента зависит от конкретных условий проекта, состава команды и технических ограничений.
Спасибо, что поделились своими мыслями - уверен, ваш взгляд на MobX поможет кому-то открыть для себя отличное решение, если оно подойдёт их проекту. А кому-то, наоборот, будет достаточно встроенных в React возможностей, чтобы не выходить за пределы привычной экосистемы.
Автор отлично изложил свои мысли
useActionState: новый герой в мире React