Почему react приложения такие сложные?

На неделе прочитал статью, суть которой заключалась в следующем: «я бэкенд разработчик, мне поручили сделать кнопку на реакте, почему так сложно».

Такие статьи изначально строятся на неправильном тезисе — когнитивном искажении, что то, что кажется простым снаружи является таким и внутри. В жизни обычно всё устроено наоборот.

Так в современных приложениях пока пользователь тыкает кнопочки, между клиентом и сервером ходят данные, части интерфейса блокируются, другие обновляются, рисуются сложные анимации. Со стороны пользователя это кажется естественным и самим собой разумеющимся, но все эти вещи кто‑то запрограммировал.

Но что является основной причиной сложности react приложений? Является ли она следствием только лишь сложности самих требований, предъявляемых к приложению? Или есть что‑то ещё?

Сам по себе react предлагает простую и красивую концепцию, когда разработчик описывает состояние, его изменение, и как на основе состояния нарисовать сам интерфейс. Явное выделение этих абстракций — это реально огромное достижение относительно подхода, когда отдельные кусочки интерфейса мутируются в событиях, возникающих при работе с приложением.

И всё было бы просто, если описанных абстракций было бы достаточно. Но реальные react приложения работают с backend сервером. И если погрузиться в детали, то становится ясно, что это реально нетривиальная задача.

Получается, что приложение должно работать с данными, получение и изменение которых является асинхронным.

Теперь наши функции, которые запрашивают данные с сервера и кладут их в переменную, вероятно, будут работать неправильно. Так как переменная одна, а функция может быть запущена несколько раз, возможна ситуация, когда более старый вызов закончится последним и затрет более новые данные. Сценарии с несколькими вызовами постоянно возникают при работе пользователя — люди переключают вкладки, страницы таблицы или пункты меню. Нашему мозгу сложно работать с кодом, где, условно говоря, что‑то выполняется параллельно, но при этом используются общие переменные.

Следующая проблема — это то, что получаемые данные должны иметь глобальный характер. То есть понятно, что это поможет избежать избыточных запросов, но более важно то, что не возникнет ситуации, когда данные в одной части интерфейса будут противоречить другой. Ведь в приложении параллельно ведут работу несколько пользователей, и данные имеют свойство меняться без нашего ведома.

Это приводит к мысли о создании сущности, которая будет хранить, можно сказать, снимок данных с нашего сервера. Множество компонентов в любой момент могут попросить её получить нужные данные, что опять выливается во множество, условно говоря, одновременно идущих операций с разделяемыми переменными.

Но это только верхнеуровневое описание, которое касается получения данных, но есть ведь ещё и их изменение... Так глобальное хранение потребует ещё и очистки, а после того, как поменялись данные на сервере, нужно предусмотреть и соответствующее обновление в интерфейсе. Сама природа проблем тут будет соответствовать той, что была описана раннее, но это не делает обозначенные задачи проще.

И получается, что сложность кроется не в react'е, а в самой архитектуре, когда есть живущее без перезагрузок frontend приложение, бэк и асинхронное взаимодействие между ними. И да, раньше, когда странички отрисовывались по запросу на сервере, такой проблемы не было. Так как по сути программисты просто писали императивный код — брали нужные данные, заполняли ими шаблон и отдавали пользователю страницу. И приложения на react'е стали такими же простыми, если бы на любой запрос интерфейс бы полностью блокировался, или запросы стали бы синхронными.

И ситуация с так называемым зоопарком технологий в react приложениях растёт из описанной проблемы. Пока у нас есть только react и какая‑нибудь библиотека компонентов всё просто, но когда начинается организация взаимодействия с бэкенд сервером, и правда оказывается, что из коробки в react'е не предусмотрено решение озвученных вопросов, и разработчики начинают обращаться к различным библиотекам.

И по сути всё это время пока мы писали свои приложения, параллельно шла эволюция понимания, а вместе с ним и библиотек. Поэтому и получился такой зоопарк.

Текущее поколение — react‑query, useSWR, RTK Query — это реально огромный шаг вперёд. Теперь frontend приложения стало писать проще, но, несмотря на очень хорошие абстракции, вряд ли возможно скрыть за ними всю сложность. Да и в любом случае реальная жизнь любит подкинуть задач, когда приходится глубоко погружаться в данную проблематику.