Какой инструментарий для разработки на TypeScript+React актуален на момент лета 2021?

Question

[Wylaroren]

Писал приложения на React примерно год. Язык был JavaScript (в смысле не TypeScript), использовал Redux.

Начиная с лета 2019 полностью переключился на TypeScript и Vue, но такие факты как задержка релиза Vue 3 на пару лет (статьи о том, что он якобы реализован не имеют отношения к реальности) вызывали разочарования как у меня, так и во многих компаниях, а потому я возвращаюсь на React, только теперь писать приложения буду уже на TypeScript.

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

1. Аналоги vue-properties-decorators

Поддержка ООП-синтаксиса в React есть их коробки, но есть ли библиотеки наподобие vue-property-decorator, ещё более упрощающие работу с классами, состоянием и свойствами?

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

2. Аналоги для vuex-module-decorators для Redux или замена Redux

Когда использовал чистый Redux, то процентов 50 времени уходило на рутину по созданию файлов, объявлению экшенов, немутирующему обновлению состояния, привязки и так далее. Когда я перешёл на Vue+Vuex, да ещё и стал использовать vuex-module-decorators, это было нечто великолепное - рутины стало в РАЗЫ меньше!

С использованием динамических модулей можно вообще хранить классы где угодно и эффект такой, как будто модуль полностью независим от stor-a (полезно для случаев, когда создаётся какой-нибудь компонент и в одной папке сложены его разметка, стили, vue-компонент и сервисный класс, реализованный с использованием vuex-module-decorators).

Есть ли инструменты, которые облегчат работу с Redux на уровне vuex-module-decorators?
Или может, мне лучше взглянуть в сторону аналогов Redux, например Mobx?

Напоследок, попрошу Вас дать порекомендовать любые библиотеки для React, от использования которых Вы получили положительные впечатления - посмотрю их все.

Comments

[Александр]

только если они действительно дают много того, чего не могут дать классы

а как Вам возможность автоматического срабатывания некоторой логики, которая может следить сразу за несколькими переменными?

[Wylaroren]

Александр, Благодарю Вас за комментарий? Звучит как концепция Watcher-ов. Во Vue это из коробки. И что, в React, самом популярном фреймворке в мире, нет никакого другого элегантного решения, кроме как хуки, чтобы выполнить определённую функцию при изменении конкретной переменной? Как же это задачу решали во времена, когда хуков не было? (Сам, если честно, не помню).

[Александр]

Wylaroren, вручную вызывали методы.

[Василий Банников]

Я могу ошибаться, но с позиции моего текущего опыта мне показалось, что своим существованием хуки обязаны начинающим разработчикам, которые не хотят изучать ООП

Звучит как

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

Мне интереснее узнать, что такого можно сделать в компонентах-классах, чего нельзя сделать в функциональных компонентах.

[Василий Банников]

Когда использовал чистый Redux, то процентов 50 времени уходило на рутину по созданию файлов, объявлению экшенов, немутирующему обновлению состояния, привязки и так далее

Попробуй тогда MobX или effector

[Wylaroren]

Василий Банников, Да может и всё можно сделать в функциональных компонентах. Я не готов вести холивар по поводу "какая парадигма программирования лучше - функциональная и объектно-ориментированная". Субъективно могу сказать, что попробовал обе, причём сначала функциональную, но когда стал въезжать в концепцию ООП, то понял, насколько это величайшее изобретение. С тех пор большую часть кода я пишу через классы и полностью доволен. Из мнения других специалистов могу процитировать одного из авторов книги "Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию", который говорил, что использование ООП вместе шаблонами проектирования даёт наиболее лёгкие в поддержке приложения.

Так что субъективно для меня переход на функциональный стиль - это в некотором роде "откат назад".

[Антон Швец]

Wylaroren, ничто не мешает использовать паттерны и при работе с функциональными компонентами.
Хуки позволяют удобно выносить логику и делать элегантные решения. И для реакта они выглядят более естественно.
Правда это не потому что ООП с классами это плохо, это потому что в реакте оно реализовано очень неудобно, di в конструкторе не сделать, композиция только через замыкания.
На данный момент я бы классы в реакте не использовал.

[Василий Банников]

Wylaroren, такое ощущение, что в реакте ни ООП ни ФП нет в полноценном виде, так что тут и негде спорить, что лучше.
От ООП там нет абстракций. наследования, полиморфизма, а от ФП там нет композиции чистых функций, каррирования, и ленивых вычислений.

[Wylaroren]

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

[Wylaroren]

Антон Швец, Ну вот, это уже аргументированный ответ! Благодарю Вас.

[Wylaroren]

Василий Банников, Ну что ж, я думаю надо просто всё это попробовать. В конце концов, React - это просто средство для отображения в браузере и обработки действий пользователей в браузере, а остальной служебный функционал вне зоны ответственности React-а.

[Михаил Кочетков]

Если говорить простым языком, то парадигмы ООП и ФП в React, как и в самом JS/TS живут бок о бок и отлично себя показывают. Правильно использовать молотки для гвоздей, а отвертки для саморезов. Тут такая же ситуация. В функциональном стиле гораздо проще работать с иммутабельностью, которой в React достаточно. Например, у вас есть данные (props) на вход. С помощью useMemo на основании определенных пропсов рассчитываются какие-либо следствия. Затем они отображаются. Получается некий pipeline преобразования props -> data -> render.
С точки зрения возможностей, то же можно сделать и в ООП, но само ООП больше заточено на мутабельную парадигму. Так зачем забивать саморезы молотком? Это возможно, но не нужно. ООП прекрасно нашло себе место на сервисном уровне реакт приложений. Там можно и DI себе организовать, и с декораторами поработать, и разделить бизнес логику, обернув ее в нужные шаблоны проектирования. В общем, чем бы дитя не тешилось.
В своей практике обычно использую связку React + React Query для визуализации. tsyringe и Mobx для организации сервисного уровня приложения. Mobx-State-Tree для описания и работы с моделями данных.

А касательно камней в огород Angular: стандартизация и строгость - это хорошо. Плохо, когда этого нет. Для того же существуют линтеры, форматеры, TypeScript, Golang и т. д. Когда проект становится сложным(архитектурно) и объемным в условиях бизнеса, необходимо внедрять много уровней контроля и стандартизации, чтобы кодовая база не превратилась в ад. Каждый разработчик зачастую пишет так, как ему хочется. Если на проекте несколько таких человек, то проект быстро превратится в картину абстракционистов. Один пишет в ООП парадигме, другой в ФП. Одному нравится Redux, другому Mobx, а третий вообще хочет использовать Effector. Тот еще цирк с конями. Angular же в свою очередь из коробки дает инструкцию как и что правильно делать (я не адепт ангуляра, люблю React, но хорошему фреймворку всегда готов отдать дань уважения). Любой новый разработчик на таком строгом проекте быстро вольется в стиль разработки команды. На таком проекте будет легко поддерживать чистоту кода, поскольку никто не изобретает велосипеды и все пользуются одинаковыми молотками. Задачи можно будет частично перекладывать с человека на человека и так далее. Это все уменьшает затраты на развитие и поддержку проекта. А чем меньше затрат - тем лучше для бизнеса) Стоит помнить, что за любым мало мальски серьезным проектом стоит бизнес. Все остальное в свободное время на личном сервере. Если что-то не приносит денег - этим не будут заниматься. Если что-то поглощает больше денег, чем нужно - от этого избавляются)

Поэтому "Чистая архитектура" это классно, но только в книжках) На практике все намного сложнее. Да и брать крупный фреймворк, а затем осуждать его за чистую архитектуру тоже неправильно. Большинство из них активно используют эту парадигму для развязывая связей внутри себя. Это позволяет им быть коммерчески независимыми в случае непредвиденных ситуаций. Это сложный и дорогой процесс, но он необходим, чтобы Вы, как конечный разработчик, могли малыми усилиями творить большие и сложные проекты)