Спасибо за ваш развернутый комментарий! Видно, что вы отлично знакомы с 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 возможностей, чтобы не выходить за пределы привычной экосистемы.
Спасибо за коментарий, отличное наблюдение. useDeferredValue помогает распределять приоритеты рендеринга, чтобы сохранить отзывчивость интерфейса (например, при вводе текста). Однако, как подчёркивает и документация, для полного раскрытия потенциала этого хука тяжёлый компонент желательно обернуть в React.memo. Без мемоизации он будет перерендериваться при каждом обновлении родителя, и все преимущество теряется. Поправлю пример в стате, чтобы сразу показать наглядное использование вместе с memo. Спасибо, что обратили на это внимание!
Спасибо за отзыв! Да, планирую сделать разбор и остальных новых хуков из React 19, чтобы охватить все интересные возможности (будет отдельная статья). А пока можете заглянуть в мою подробную статью о хуке useActionState: https://habr.com/ru/articles/870216/ - там тоже есть немало интересных идей по оптимизации и управлению состоянием. Спасибо, что читаете!
Неплохой пример, спасибо, что поделились! Но, как и в любом обсуждении инструментов и подходов к архитектуре, всё упирается в задачу и контекст. Постараюсь пояснить, почему в статье речь шла именно о хуках и 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. Для многих команд это решающий аргумент - они предпочитают официоз, чтобы не плодить разные библиотеки.
Спасибо за комментарий! Конечно, у MobX есть свои неоспоримые преимущества - он удобен для организации гибкого и реактивного стейт-менеджмента, особенно когда в приложении много взаимосвязанных состояний и сложная бизнес-логика. Однако у каждой задачи свои масштабы и особенности.
Локальные экшены и формы. Когда речь идёт об обработке единичного действия (отправка формы, загрузка файла и т. п.), не всегда хочется поднимать глобальное хранилище, прописывать сторы, экшены и т. д. проще зацепить локальный хук и закрыть задачу за пару строк. В таких случаях удобнее иметь что-то вроде useActionState, которое интегрировано в экосистему React.
Server Components призваны минимизировать клиентскую часть и ускорить загрузку. Некоторые фреймворки (например, Next.js) поддерживают это «из коробки». useActionState встроен в эту концепцию, позволяя обрабатывать действия еще до гидратации.
Никто не заставляет бросать MobX - в крупных проектах, где уже есть MobX, Redux, Zustand и пр., можно совмещать их с хуками. Всё зависит от того, какой подход более оптимален в конкретном месте приложения.
Так что выбор инструмента всегда сводится к балансированию между гибкостью, скоростью разработки и сложностью задачи. MobX отлично покрывает определённые сценарии, React-хуки - другие. Здорово, что у нас теперь есть несколько инструментов на выбор, а не «один-единственный фреймворк на все случаи жизни».
? в статье есть ссылки на примеры для разных framework-в. В нем 3 вкладки с графиком. на первой пример без без шины, на второй и третье с шиной с Observable и Promise соответственно.
привет! если честно, не видел этот пакет. Изначально создавал шину для Observable из RxJs для проекта на Angular. Я так понял в comlink нет этой поддержки. С Typescript он окей работает?
Спасибо за ваш развернутый комментарий! Видно, что вы отлично знакомы с MobX и ценно делитесь опытом 👍. Позвольте немного уточнить позицию, которую я хотел отразить в статье, и почему всё же имеет смысл рассматривать useActionState и подход с Server Components.
"Просто взять и выучить MobX" Соглашусь, MobX действительно можно достаточно быстро освоить для базовых сценариев. Тем не менее в реальных командах (особенно в больших проектах) выбор инструмента не всегда сводится к личному желанию или времени на обучение. Часто есть корпоративные стандарты, legacy-проекты, где нет возможности добавлять новые библиотеки, или коллеги, которые предпочитают оставаться в «официальной экосистеме React» без сторонних зависимостей. В таких ситуациях useActionState (и другие встроенные инструменты) могут быть более удобны — не потому что они лучше или хуже, а потому что они подходят под процессы и политику конкретной команды.
Использование штатного API (например,
useState,useReducer,useActionState) - это не всегда "стрельба в ногу". Для небольших и средних задач без сложных взаимосвязей зачастую достаточно встроенных инструментов, и они позволяют быстро закрыть потребности. Когда же проект разрастается и возникает потребность в богатой реактивности, MobX (или другой стейт-менеджер) может отлично вписаться. Но далеко не всем нравится тянуть дополнительную абстракцию, особенно если задача элементарная и решается двумя строчками встроенного хука.На практике всё зависит от архитектуры и конкретного проекта: для одного кейса 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 возможностей, чтобы не выходить за пределы привычной экосистемы.
Спасибо за коментарий, отличное наблюдение.
useDeferredValueпомогает распределять приоритеты рендеринга, чтобы сохранить отзывчивость интерфейса (например, при вводе текста). Однако, как подчёркивает и документация, для полного раскрытия потенциала этого хука тяжёлый компонент желательно обернуть вReact.memo. Без мемоизации он будет перерендериваться при каждом обновлении родителя, и все преимущество теряется. Поправлю пример в стате, чтобы сразу показать наглядное использование вместе сmemo.Спасибо, что обратили на это внимание!
Спасибо за отзыв!
Да, планирую сделать разбор и остальных новых хуков из React 19, чтобы охватить все интересные возможности (будет отдельная статья). А пока можете заглянуть в мою подробную статью о хуке useActionState: https://habr.com/ru/articles/870216/ - там тоже есть немало интересных идей по оптимизации и управлению состоянием. Спасибо, что читаете!
Неплохой пример, спасибо, что поделились! Но, как и в любом обсуждении инструментов и подходов к архитектуре, всё упирается в задачу и контекст. Постараюсь пояснить, почему в статье речь шла именно о хуках и 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. Для многих команд это решающий аргумент - они предпочитают официоз, чтобы не плодить разные библиотеки.Спасибо за комментарий!
Конечно, у MobX есть свои неоспоримые преимущества - он удобен для организации гибкого и реактивного стейт-менеджмента, особенно когда в приложении много взаимосвязанных состояний и сложная бизнес-логика. Однако у каждой задачи свои масштабы и особенности.
Локальные экшены и формы. Когда речь идёт об обработке единичного действия (отправка формы, загрузка файла и т. п.), не всегда хочется поднимать глобальное хранилище, прописывать сторы, экшены и т. д. проще зацепить локальный хук и закрыть задачу за пару строк. В таких случаях удобнее иметь что-то вроде
useActionState, которое интегрировано в экосистему React.Server Components призваны минимизировать клиентскую часть и ускорить загрузку. Некоторые фреймворки (например, Next.js) поддерживают это «из коробки».
useActionStateвстроен в эту концепцию, позволяя обрабатывать действия еще до гидратации.Никто не заставляет бросать MobX - в крупных проектах, где уже есть MobX, Redux, Zustand и пр., можно совмещать их с хуками. Всё зависит от того, какой подход более оптимален в конкретном месте приложения.
Так что выбор инструмента всегда сводится к балансированию между гибкостью, скоростью разработки и сложностью задачи. MobX отлично покрывает определённые сценарии, React-хуки - другие. Здорово, что у нас теперь есть несколько инструментов на выбор, а не «один-единственный фреймворк на все случаи жизни».
? в статье есть ссылки на примеры для разных framework-в. В нем 3 вкладки с графиком. на первой пример без без шины, на второй и третье с шиной с Observable и Promise соответственно.
привет! если честно, не видел этот пакет. Изначально создавал шину для Observable из RxJs для проекта на Angular. Я так понял в comlink нет этой поддержки. С Typescript он окей работает?