Освоив хуки, многие React-разработчики испытали эйфорию, наконец-то получив простой и удобный инструментарий, позволяющий реализовывать задачи существенно меньшим количеством кода. Но значит ли это, что предложенные из коробки стандартные хуки useState и useReducer — это все, что нам нужно для управления состоянием?

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

Сейчас уже мало кто пишет на Perl'е, но известная максима Ларри Уолла "Keep simple things easy and hard thing possible" стала общепринятой формулой эффективной технологии. Ее можно трактовать в аспекте не только сложности задач, но и подхода: идеальная технология должна, с одной стороны, позволять быструю разработку средних и малых приложений(в т.ч. "write-only"), с другой — предоставлять инструменты для вдумчивого девелопмента сложных приложений, где на первое место ставиться надежность, поддерживаемость и структурированность. Или даже, переводя в человеческую плоскость: быть доступной для джунов, и в то же время удовлетворять запросы синьйоров.

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

"Вы будто бы храните все столы в одной комнате, а стулья — в другой"
— Юха Паананен, творец библиотеки Bacon.js, о Редаксе

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

Mrr — функционально-реактивная библиотека для React'а (извиняюсь за мнимую тавтологию).

При слове «реактивность» обычно вспоминают Rx.js, как эталонный образец FRP. Однако серия последних статей на эту тему на Хабре([1], [2], [3]) показала громоздкость решений на Rx, которые на несложных примерах проигрывали в ясности и простоте почти любому другому подходу. Rx велик и могуч, и прекрасно подходит для решения проблем, в которых абстракция потока напрашивается сама собой (на практике это преимущественно координация асинхронных задач). Но стали бы вы писать, к примеру, простую синхронную валидацию формы на Rx? Сэкономил бы он ваше время, по сравнению с обычными императивными подходами?

mrr — это попытка доказать, что ФРП может быть удобным и эффективным решением не только в специфических «потоковых» проблемах, но и в самых обычных рутинных задачах фронтенда.