Шон Райнхарт

Если вы хотите создать современное веб-приложение, одностраничное приложение (SPA) может быть разумным шагом. По мере того, как пользователи знакомятся с SPA через свои социальные платформы (например, Facebook, Twitter) и приложения для повышения производительности (например, Gmail, Trello), они начинают ожидать такой же быстрой, плавной и последовательной работы от каждого веб-приложения, которое они используют, даже внутреннего. корпоративные. Если вы не уверены, что вам нужно одностраничное приложение, мы рассмотрим некоторые причины и преимущества в нашей предыдущей записи в блоге.

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

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

Какой фреймворк мне следует использовать?

Прежде чем вы сможете приступить к созданию красивого нового одностраничного приложения, вам нужно решить, из чего его создавать. Самые популярные варианты — React, Angular и Vue. Есть довольно много других, многие из которых имеют свои собственные нишевые цели, но каждая из этих больших троек имеет большие, активно растущие экосистемы, и каждая из них достаточно масштабируема. Теперь я хочу отметить важную вещь: это не все одно и то же.

Для контекста: библиотека — это то, что вы используете из своего кода, вызывая его по мере необходимости. Фреймворк, с другой стороны, обеспечивает основу или «фрейм» для вашего приложения и будет вызывать ваш код, выражая свое собственное мнение о вашем коде и о нем, прежде чем производить вывод.

  • React сам по себе является только библиотекой представлений (а не полной структурой), и он опирается на другие вспомогательные библиотеки для создания полноценного SPA. Команда React предоставляет или рекомендует множество дополнительных пакетов для поддержки чистой интеграции и максимальной совместимости, но они по-прежнему являются отдельными библиотеками. Эта гибкость позволяет невероятному множеству библиотек, управляемых сообществом, действительно сиять и ускорять развитие экосистемы.
  • Angular — это полноценный фреймворк со всеми прибамбасами. Вы можете добавить дополнительные вспомогательные библиотеки или сторонние надстройки, но в основных пакетах Angular есть все, что вам нужно для многих SPA от простого до среднего уровня сложности. Он прошел через ряд итераций и стал надежной, производительной, проверенной в боевых условиях структурой.
  • Vue находится где-то посередине, позиционируя себя как прогрессивный фреймворк: это означает, что вы можете включать нужные вам элементы по мере необходимости (аналогично Angular). Основная библиотека ориентирована только на уровень представления, но с современными инструментами и дополнительными библиотеками вы можете создавать большие и сложные SPA (похожие на React).

Если у вашей команды уже есть приличный опыт использования конкретной экосистемы SPA, используйте ее. Часто лучше использовать и совершенствовать существующий набор навыков, чем начинать новую кривую обучения, если нет веских причин для изменений (например, потребность в гибкости React вместо жесткости Angular).

Если вы еще не остановились на одном из них, потратьте немного времени заранее, чтобы решить, что лучше всего подходит для вашего проекта. Многие навыки концептуального уровня, полученные в одной экосистеме SPA, будут передаваться из одной в другую с вариациями синтаксиса, поэтому не чувствуйте себя чрезмерно обязанным использовать один и тот же стек в каждом проекте. У каждого есть свои плюсы и минусы, и, в конце концов, SPA представляют собой набор основных строительных блоков Интернета (HTML, JavaScript и CSS). Каждая ситуация будет отличаться, и вам нужно выбрать то, что больше всего подходит для ваших требований.

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

С чего начать писать код?

После того, как вы определились со стеком, на самом деле лучше всего начать с инструмента интерфейса командной строки (CLI), который создаст для вас новое приложение (например, create-react-app, angular-cli, vue-cli). Они обеспечивают быстрый способ запуска нового приложения путем создания некоторых базовых страниц с включенными значениями по умолчанию и подключенными инструментами упаковки/связывания. предварительно подключите некоторые компоненты для вас (например, маршрутизацию на стороне клиента). Многие инструменты CLI содержат полезные команды для создания новых компонентов, которые могут сэкономить время при работе с шаблонным кодом.

Если вы также создаете серверную часть (и заинтересованы в использовании .NET), используйте шаблоны SPA SDK dotnet. Они сделают еще один шаг вперед и предоставят вам подготовленную серверную часть, интегрируют SPA и сделают еще более предварительную настройку, и это так же просто, как установить последний SDK, а затем ввести dotnet new react из командной строки. (Слишком легко, правда?)

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

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

Как выбрать дополнительные библиотеки?

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

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

Если в вашем совместно используемом коде ничего нет, просмотрите ваш `package.json` и отсканируйте его на наличие чего-либо, что может включать работающее решение (например, не добавляйте библиотеку компонентов с множественным выбором, если ваш существующий компонент выбора может разрешить мультивыбор уже — реальная история). Часто есть функции или пакеты, о которых вы, возможно, не знали или помните, что они уже были доступны вам.

Если у вас действительно ничего нет, спросите себя…

Есть ли для этого официальный пакет?
 Под официальным я подразумеваю то, что было создано специально для вашего стека его создателями или рекомендовано ими. Angular включает в себя множество функций по умолчанию, но команда Angular также опубликовала ряд дополнительных пакетов, которые тесно интегрируются с основной структурой лучше, чем сторонние пакеты. С другой стороны, React (будучи библиотекой) указывает или рекомендует ряд хорошо поддерживаемых пакетов сообщества, таких как `react-router`.

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

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

Потратив немного времени на просмотр репозитория, вы можете многое сказать о том, насколько хорошо поддерживается пакет. Если коммита не было в течение трех лет, он мог быть заброшен. Или, может быть, у него много недавних коммитов, но все они связаны с безопасностью, и в их README указано, что проект скоро станет устаревшим. В обоих случаях вы захотите найти альтернативные решения.

Как часто он выпускается?
 Это связано с последним вопросом, но может играть более конкретную роль в поддержании вашего проекта в актуальном состоянии. У большинства хорошо поддерживаемых проектов будет регулярная частота выпуска или некоторый уровень дорожной карты, которой они следуют, чтобы отслеживать, что входит в следующую версию. Глядя на то, как часто выпускается пакет, вы можете понять, насколько вы «застряли» на соответствующем наборе зависимостей. Если вы включаете пакет, который редко выпускается (даже если он прилично поддерживается), но другие библиотеки, которые вы включаете, имеют связанные зависимости, вы не сможете обновить ни одну из них до следующего выпуска. Это один из самых больших компромиссов при добавлении новых пакетов.

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

Использовали ли мы это раньше?
Это больше для тех случаев, когда вы сократили количество вариантов. Если у вас налажены хорошие внутренние каналы связи, стоит связаться с другими командами в организации, чтобы узнать, пользовались ли они рассматриваемой библиотекой/библиотеками. Кто-то, кто был там и использовал его, может поделиться своим мнением и некоторыми знаниями из первых рук о любых ловушках, с которыми он мог столкнуться, или может быть в восторге от того, насколько это потрясающе.

Итак, есть ли другие инструменты для рассмотрения?

Да… да есть.

Согласованность кодовой базы — одна из лучших вещей, которые может иметь разработчик. Согласованность помогает сохранять код читабельным и, следовательно, понятным, что упрощает переход от одной части кода к другой во время разработки. К счастью для нас, есть много инструментов, которые помогают. Инструменты форматирования (например, Prettier) помогают поддерживать единообразие стилей во всем коде, автоматически применяя настроенные стили при сохранении изменений, а инструменты анализа (например, ESLint) могут помочь предотвратить другие несоответствия и даже выявить некоторые небольшие ошибки с помощью статического анализа.

Во время разработки (особенно во внешнем интерфейсе) вам придется пересобрать приложение, чтобы проверить свои изменения. Инструменты горячей перезагрузки (например, react-hot-loader) позволяют просматривать изменения в работающем внешнем коде без перезагрузки приложения. Это может ускорить ваш рабочий процесс и ускорить создание красивых пользовательских интерфейсов.

Модульные тесты — это хорошо для серверного кода. Естественно, это также очень полезно при создании СПА. Здесь я очень рекомендую Jest. Это невероятная среда тестирования переднего плана, которая выполняет как модульное, так и компонентное тестирование моментальных снимков, и она работает практически с любым стеком javascript, который вы можете использовать. Большим преимуществом модульных тестов JS является то, что вы тестируете лежащий в основе код и бизнес-логику, а не только визуализированный вывод (как при использовании инструмента автоматизации браузера, такого как Selenium). Затем, когда у вас есть более совершенные компоненты, тесты моментальных снимков дают вам полную картину изменений пользовательского интерфейса, чтобы помочь убедиться, что пользовательский интерфейс остается согласованным или есть веская причина для изменения. Внедрение этих типов тестов поможет вашим командам вносить более обдуманные и продуманные изменения.

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

Теперь иди и строй!

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

Использование CLI-инструмента, безусловно, является рекомендуемым подходом, и его использование не только ускорит работу, но и гарантирует, что большая часть конфигурации позаботится о вас и будет изолирована от непреднамеренных изменений. Объединив этот базовый стек с интеллектуальными вспомогательными библиотеками и позаботившись о том, чтобы сделать процесс разработки плавным, вы можете создать невероятный пользовательский интерфейс с вашими SPA.

Современные веб-приложения побуждают пользователей ожидать новейших и лучших…

… так почему бы не дать им это и немного повеселиться, пока вы этим занимаетесь.

Первоначально опубликовано на https://headspring.com 10 сентября 2019 г.