Нещодавно я сів за пет-проєкт. Звичайна історія: була ідея, хотілося швидко накидати інтерфейс, перевірити гіпотезу.

Вибір пав на React — ніби ж знайомий інструмент, зручний, популярний. Але замість приємної розробки я знову опинився в лабіринті з хуків, ефектів і незрозумілих станів. І от я вже не роблю фічу, а пишу цю статтю.

За часів давніх богів

Колись я писав на AngularJS. І, як не дивно, згадую про це з теплом. Тоді Angular був ковтком свіжого повітря на фоні хаосу jQuery. Він давав відчуття, що у тебе є не просто бібліотека, а справжній фреймворк з правилами, структурою, архітектурою. Навіть якщо вона часом була дивна.

Так, там були свої приколи: two-way binding, директиви, олди знають, як працював $digest. Але це все одно було краще за той пекельний імперативний код на jQuery, де кожен новий фіча-реквест — це ще один дротик у стіну з тротилу.

React

React здавався ковтком свіжого повітря. Особливо на фоні Angular 2, який приніс TypeScript, RxJS і відчуття «переписали все, й забули спитати». React обіцяв простоту. Компоненти — це просто функції. Локальний стан. JSX — як на мене ще то дивацтво, але схожий на HTML.

Все звучало непогано. До моменту, коли треба було написати щось більше за TODO-лист.

Архітектура?

React не фреймворк. Це просто бібліотека для побудови UI. Все інше — якось ти давай сам.

Як керувати станом? Redux, Zustand, Jotai? Як фетчити дані? useEffect, SWR, React Query? А як будувати архітектуру?

У кожного розробника — свій рецепт. І це не завжди погано. Але це точно не просто.

useEffect

React каже нам розділяти ефекти від логіки. Але useEffect використовується майже для всього: фетчі, підписки, скрол, таймери, анмаунт. Один useEffect залежить від стану, який змінює інший useEffect. Іноді це перетворюється в карусель, яку вже не зупинити.

Навіть у пет-проєкті ловиш себе на думці: «А чому цей useEffect виконується двічі?» Потім гуглиш, читаєш, додаєш флаг, дебажиш, психуєш. І все заради одного простого запиту.

Глобальний стан

React Context, Redux, Zustand — всі обіцяють вирішити проблему спільного стану. Але знову все залежить від тебе. Немає єдиного підходу. Іноді здається, що кожен новий стор — це як нова версія глобальної змінної, тільки з гарними словами: селектор, ред’юсер, атом.

А якщо в тебе кілька useStore, useWhatever, useCustomHook, все це оновлює щось глобально — успіхів з трекінгом, хто на що впливає.

А може, ми не туди дивимось?

Останнім часом я почав сумніватися: може, проблема не в Redux, не в хуках, не в useEffect. Може, сама модель — компонентна архітектура з декларативним UI — не така вже й ідеальна? Може, ми просто звикли жити з хаосом, бо альтернативи здавались ще страшнішими?

React — це еволюція. Але не факт, що фінальна форма. Йому вже понад 10 років. І він досі з нами, бо дає свободу. Проблема в тому, що свобода — це і відповідальність. А отже, й біль.

І все ж…

Це не хейт. Це не спроба сказати: «React — поганий». Ні. Це роздуми вголос.

Якщо React здається складним — це не ваша провина. Це не тому, що ви щось не зрозуміли. Це тому, що React справді складний. І що далі — то більше патернів, шарів абстракції й компромісів.

Можливо, ми просто втомились і хочемо чогось… простішого?

P.S.

Я не знаю, що буде далі. Може, Svelte? Solid? Може, щось зовсім нове?

Але одне знаю точно: кожен проєкт на React нагадує мені, що простота — це не відсутність інструментів. Це коли не треба пояснювати, чому все працює саме так.