React — отличная библиотека. Это важно в веб-разработке, потому что он представил декларативные и реактивные шаблоны, изменение парадигмы, в котором все нуждались в то время. Тогда (6 или 7 лет назад) была проблема с движками рендеринга и реактивностью, и React решил ее довольно хорошо.
В качестве примечания, Ember ранее решил ту же проблему. Однако он был не таким производительным, и фреймворк был слишком самоуверенным, чтобы догнать то, как это сделал React.
использовать эффект (сделать беспорядок)
То, что произошло после того, как React стал популярным, было беспорядком.Это положило начало новой тенденции в сообществе, где все вращается вокруг шумихи, новизны и создания новых сдвигов парадигмы. Каждые несколько месяцев появлялись новые библиотеки, устанавливающие новые стандарты того, как мы должны писать веб-приложения React, и в то же время решающие проблемы, которые по большей части уже были решены.
Возьмем в качестве примера «управление государством». Поскольку в React отсутствует традиционная система внедрения зависимостей (DI достигается за счет композиции компонентов), сообществу пришлось решать эту проблему самостоятельно. Так оно и было. Снова и снова и снова. Каждый новый год приносил новый набор стандартов. React — это просто движок рендеринга, и в типичном веб-приложении вам нужно много библиотек для создания фреймворка для проекта — например, уровни данных, управление состоянием, маршрутизация, сборщики ресурсов и многое другое.
Экосистема, стоящая за React, давала вам слишком много вариантов такого рода, что приводило к фрагментации технологического стека и вызывало печально известную «усталость от JavaScript».
Одной из тенденций, которая также возникла, была «одержимость сравнением рамок». Фреймворки JS постоянно сравнивались по таким свойствам, как скорость рендеринга и объем памяти. В большинстве случаев это не имеет значения, потому что медленное приложение вызвано не медленным JS-фреймворком, а плохим кодом.
Как и любая другая тенденция, захватившая мир, эта зашла слишком далеко, нанеся ущерб новым поколениям веб-разработчиков. Мне интересно, как библиотека может быть наиболее важным навыком в резюме среднего веб-разработчика? Хуже того, это даже не библиотека, а модуль внутри этой библиотеки. Хуки React чаще упоминаются как «навыки», в отличие от некоторых реальных навыков, таких как рефакторинг кода или проверка кода.
Серьезно?! Когда мы перестали хвастаться важными вещами?
Почему бы вам не сказать мне, например, что вы знаете:
Как сделать простой и читаемый код
… не упомянув самую популярную библиотеку на Github, а показав мне один или два ваших лучших фрагмента.
Как управлять состоянием
… не упоминая популярную библиотеку управления состоянием (желательно заканчивающуюся на «X»), а объясняя мне, почему «данные должны снижаться, а действия должны повышаться». Или почему состояние должно быть изменено там, где оно было создано, а не глубже в иерархии компонентов.
Как протестировать свой код
… не говоря мне, что вы знаете Jest или QUnit, а объясняя, почему сложно автоматизировать сквозные тесты и почему минимально осмысленные тесты рендеринга — это 10% усилий и 90% пользы.
Как опубликовать свой код
… не упоминая, что вы используете CI/CD (как и любой другой проект сегодня, над которым работает более одного человека), но объясняя, что развертывание и выпуск должны быть разделены, поэтому вы должны кодировать новые вещи таким образом, чтобы они не возиться со старыми вещами и может быть включен удаленно.
Как писать рецензируемый код
… не упомянув, что вы «командный игрок», а сказав мне, что проверка кода так же сложна для рецензента и что вы знаете, как оптимизировать свои PR для удобочитаемости и ясности.
Как создать надежные стандарты проекта
…потому что, если вы не группа из одного человека, вы будете ненавидеть свою жизнь, если не будете следовать строгим стандартам и условностям в проекте. Вы должны сказать мне, что дать имя сложно, и чем шире область действия переменной, тем больше времени вы должны потратить на то, чтобы придумать для нее хорошее имя.
Как просматривать чужой код
… потому что проверка кода обеспечивает качество продукта, уменьшает количество ошибок и технических долгов, формирует общие знания команды и многое другое — но только в том случае, если она проводится тщательно. Проверка кода не должна проводиться только сверху вниз. Это отличный механизм обучения для менее опытных членов команды.
Как найти свой путь в любом JS-фреймворке
… потому что речь идет не о звездах GitHub, а об общих принципах, которые разделяют большинство современных JS-фреймворков. Узнав о плюсах и минусах других фреймворков, вы сможете лучше понять свой фреймворк.
Как создавать MVP
…потому что технология – это всего лишь инструмент для производства продуктов, а не сам процесс. Тратить время на оптимизацию процесса всегда лучше, чем тратить время на споры о технологиях.
Как оптимизировать: не рано и не поздно
…потому что в большинстве случаев оптимизация вообще не нужна.
Как программировать в паре
…потому что парное программирование, как и проверка кода, является наиболее важной практикой для обмена знаниями и создания сплоченности команды. Это также весело!
Как постоянно проводить рефакторинг
… потому что у каждого проекта есть технический долг, и вы должны перестать ныть по этому поводу и начать рефакторинг. Каждой новой функции должен предшествовать небольшой рефакторинг кода. Большой рефакторинг или переписывание никогда не заканчиваются хорошо.