Эта статья была рецензирована Нильсоном Жаком , Крисом Перри и Томасом Греко . Спасибо всем рецензентам SitePoint за то, что сделали контент SitePoint как можно лучше!
На форумах SitePoint я наткнулся на тему, озаглавленную « Так много фреймворков», где Гвидо, растерянный из-за огромного количества доступных опций, спрашивал, какой фреймворк JavaScript ему следует принять, чтобы сделать его приложение более динамичным. Учитывая то, что я видел в отрасли и сам использовал ее, я заявил, что React уже выиграл войну на стороне клиента . Боевые слова, подобные этим, нуждаются в более подробном объяснении.
React — это не просто горячая новичок на блоке, а объединяющая парадигма. Он может служить фундаментальной технологией для веб-приложений, над которыми мы можем с уверенностью строить, зная, что в следующем месяце ее не заменит более горячая кузина. Давайте посмотрим на место React среди нынешних продуктов MVC-фреймворков, исследуя его сильные стороны и заканчивая прогнозом о том, куда пойдет развитие JavaScript в будущем.
Клиентский MVC
В течение последних нескольких лет многие умные люди пытались создать идеальную среду для создания одностраничных приложений — приложений, отображаемых на JavaScript, которые улучшили воспринимаемую производительность, мгновенно реагируя на ввод данных пользователем и изменения данных с течением времени. Статья Гильермо Рауха « Принципы многофункциональных веб-приложений» — одно из лучших обоснований того, почему это важно, и того, что мы должны учитывать при их создании.
Вы можете найти примеры того, как эти типы приложений создаются в TodoMVC , как следует из названия, они традиционно состоят из моделей, представлений и контроллеров.
Реакт входит слева от сцены
Когда React был впервые объявлен, это выглядело немного странно. Он фокусировался исключительно на слое View и не имел моделей или контроллеров. Примеры кода были написаны в странном синтаксисе под названием JSX, который для многих казался обратным шагом к старым дням, когда было принято смешивать HTML и JavaScript вместе.
Не было предоставлено никакой информации о том, как вы должны структурировать свое приложение, кроме того, что относится к иерархии компонентов — компонуемые куски пользовательского интерфейса, которые могут эффективно перерисовываться при изменении состояния. React занял несколько заметных позиций против популярных идей, которые существовали в этом пространстве, такие функции, как двусторонняя привязка данных и шаблоны, были взорваны как плохие идеи, которых лучше избегать.
Широкое Принятие
Реагируют быстро на достигнутую критическую массу. Трудно найти списки рассылки, конференции или встречи, связанные с JavaScript, которые не упоминают React в наши дни. Кажется, что все местные команды разработчиков в моем городе внедряют React, и в отличие от других популярных платформ, вердикт кажется единодушным — все, с кем я общался, рекламировали преимущества одностороннего потока данных, иерархии компонентов и простых явных визуализаций, делая задачу проще и код более предсказуемым.
Принятие React меня удивило из-за того, насколько неустойчива сценарий JavaScript. Мы редко так широко согласны с чем-либо. Есть карманы людей, лояльных к одной платформе, но большинство из нас перепрыгнуло с платформы на платформу, разочаровавшись с определенными шаблонами, которые вводят сложность и ошибки. Я еще не слышал ни об одном случае, когда люди уходили из React из-за этих разочарований, с тех пор как у jQuery не было такого явного победителя впереди.
У тебя была одна работа, одна работа.
Его ориентация на слой представления означает, что он значительно менее самоуверен, чем другие структуры, которые пытаются решить каждую проблему. Его тонкий интерфейс API означает, что на самом деле не так много, чтобы изучить, и он не требует больше, чем несколько страниц документации. Это очень помогает тем, кто учится, и упрощает разработку, так как у вас нет больших когнитивных издержек. Везде, где это возможно, React выбирает простые конструкции JavaScript и языковые функции, а не пользовательские API или языки шаблонов.
Этот дизайн также привлекателен для разработчиков JavaScript, которые, похоже, предпочитают специализированные библиотеки утилит, такие как Underscore и Moment, которые хорошо выполняют одну вещь, в значительной степени философию Unix . Хорошая работа также позволила заинтересованным в проекте людям внести свой вклад в экосистему React. В результате возникли такие проекты, как React Router , Redux и CSS Модули .
Реактивные компоненты просты
Компоненты отвечают за небольшие изолированные фрагменты пользовательского интерфейса, они принимают данные и последовательно отображают их каждый раз. Фронтальные разработчики, фоновые разработчики и дизайнеры могут легко понимать компоненты и вносить в них свой вклад, поскольку они выглядят как HTML, а минимальное использование API означает, что вы можете узнать все, что вам нужно знать о компонентах, за один день и сразу начать вносить свой вклад.
Сервер рендеринг HTML
React делает рендеринг на стороне сервера тривиальным, поскольку компоненты можно рассматривать как функции, которые принимают данные и возвращают HTML. Этот дизайн позволяет легко интегрировать рендеринг на стороне сервера в любой язык или среду программирования на стороне сервера.
В первые дни MVC на стороне клиента мы порвали сеть с такими вещами, как маршрутизация hashbang и огромное время загрузки, прежде чем что-либо появилось на экране. Мы также разбили сканеры поисковых систем, отобразив все с помощью JavaScript, когда страница загрузилась. С тех пор мы извлекли уроки из наших ошибок и снова серьезно относимся к этим основным принципам Интернета — URL-адресам, HTML-коду сервера и быстрому времени загрузки. Реакция сияет здесь, где другие рамки боролись.
Обновления DOM грязны
Магистраль была важной вехой для JavaScript. Как первая и наиболее заметная попытка довести MVC до клиентской части, она показала нам новый способ структурирования наших приложений. Первое, что он упомянул в своей документации, — это плохая идея поддерживать ваше состояние в DOM. Когда DOM остается источником правды, ваше приложение быстро становится хрупким и трудным для понимания. Становится невозможным узнать, какой фрагмент кода изменил какой элемент. Backbone поощряет идеал всегда повторного рендеринга представлений, основанных на текущем состоянии мира, React реализует эту же идею с помощью шаблона одностороннего потока данных.
Компоненты реагирования не определяют переход между состояниями. Вместо этого они явно отображают представление на основе своего текущего состояния, полностью устраняя эту задачу ручной настройки DOM. Его односторонний поток данных не позволяет DOM быть источником правды.
По общему признанию, это делает определенные задачи, такие как анимация, более трудными, потому что это те случаи, когда вы хотите определить переходы между состояниями. Однако в подавляющем большинстве случаев гораздо проще заботиться только о конечном состоянии процесса визуализации компонента.
Будущее
Популярность React будет расти, и мы увидим больше вспомогательных инструментов и проектов. По мере развития экосистемы вокруг React библиотека может измениться, но основные идеи одностороннего потока данных, иерархии компонентов, явного рендеринга и виртуального согласования DOM будут жить.
React Native показал, как можно переопределить слой простого вида для создания других типов пользовательского интерфейса. В отрасли произошел сдвиг в сторону этого шаблона построения пользовательского интерфейса, и он скоро исчезнет.
Короче говоря, React победил и будущее светлое.
Мысли?
Согласны ли вы с тем, что принципы React будут жить, или мы найдем лучшую идею в следующем месяце?
Вы начали использовать React? Что ты думаешь пока?
Обязательно дайте мне знать в комментариях ниже.