За роки моєї кар'єри я часто стикався (як і більшість з вас, я впевнений) з викликом збереження постійного стану на стороні клієнта, одночасно синхронізуючи його з даними з API. Коли React ще використовував Class Components, концепція Context була для мене досить новою, і я пережив один з найгірших перших досвідів з нею.
Тоді я був Junior Developer і мало цікавився фронтендом — я займався цим, щоб заробити на життя. Коли мій Tech Lead оголосив, що ми почнемо використовувати Context, я швидко пробігся по документації React. До того моменту ми кожного разу отримували дані безпосередньо з API (чи можна собі уявити таке сьогодні?). Тому Context API сприймався як «бюджетне» рішення.
Коли настав день рефакторингу нашого коду, я отримав велике здивування: ми будемо використовувати Redux Thunk. Redux був (і, можливо, досі є) кращим за простий React Context, оскільки дає більше контролю над тим, що потрібно перерендерювати, коли контекст оновлюється. Теоретично, він забезпечував кращу організацію в цілому. Але Redux приніс купу нових понять — Reducers (Редюсери), Actions (Дії), Store (Сховище), View (Подання) — і, чесно кажучи, нічого з цього не «клікало» в моїй голові.
Тоді я попросив допомоги у свого менеджера і дізнався гірку правду: мій менеджер теж не міг повністю пояснити Redux! Вони вирішили використовувати його, бо побачили відео на YouTube про це. Дивіться, нічого поганого в тому, щоб брати нові інструменти з інтернету, але є проблема, коли ви не спробували це на маленькому особистому проєкті, перш ніж вирішити зробити це стандартом у компанії.
Після того досвіду я вирішив більше не використовувати Redux у своїх проєктах. Чи був я неправий? Мабуть. Але ось що я зрозумів за десяток років як фронтенд-розробник: інколи розробники ускладнюють речі, щоб заспокоїти себе, що вони не є самозванцями.
Такий підхід призвів до багатьох проблем у проєктах, над якими я працював, особливо коли мова йшла про Context. На щастя, такі інструменти, як Zustand, зробили все набагато простіше, пропонуючи легкий та швидкий спосіб управління контекстом. Але все ще існує величезний розрив в розумінні серед спільноти — багато хто насправді не розуміє, як працюють Context чи State (стан).
Я став великим прихильником написання простого коду. Навіть з новими можливостями React та React Compiler, я не бачу, щоб екосистема React ставала простішою. Швидше, це протилежне. Тому я перейшов до використання Qwik як основного фреймворку. Його простота та вбудовані рішення роблять створення складних SaaS-продуктів легким завданням.
Qwik заохочує ставити собі такі питання:
- «Чи справді мені потрібно, щоб це було реактивним?»
- «Чи насправді потрібно спостерігати за цим Signal (станом) для чогось?»
З таким підходом ви природно починаєте писати компоненти з меншим маніпулюванням станом і контекстом, використовуючи їх тільки коли це абсолютно необхідно. Це не тільки робить ваші додатки більш ефективними, але й набагато простішими для підтримки.
Ось приклад: я працював над дашбордом для Next.js, де команда обгорнула весь додаток у UserContext. Але більшість сторінок були публічними, тому для їх перегляду не потрібно було бути в системі. Навіщо взагалі додавати UserContext до цих сторінок?
Я думаю, що інколи треба сповільнити темп — більше читати і менше писати. Перед тим, як використовувати Context чи State, зупиніться і подумайте, чому вам це насправді потрібно. Звісно, це лише моя особиста думка на основі власного досвіду, тож не сприймайте це як єдину правильну істину. Але якщо це відгукується — чудово, а якщо ні — це теж нормально!
Перекладено з: The Context / State Hell, and why we do not talk enough about it?