Есть два способа поддержки маршрутизации в одностраничных приложениях:

  • Хешированные пути URL - мы прерываем путь URL с помощью символа # (хэш), чтобы браузер понимал, что это всего лишь виртуальный фрагмент.
  • Обычные URL-пути (нехешированные URL-пути) - серверу необходимо перехватить запрос и вернуть index.html.

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

Совет: Делитесь своими повторно используемыми компонентами между проектами с помощью Bit (Github). Bit упрощает совместное использование, документирование и организацию независимых компонентов любого проекта .

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

Bit поддерживает Node, TypeScript, React, Vue, Angular и другие.

Обычные пути URL

По их внешнему виду можно определить, что это обычные URL-адреса.

https://mysite.com/dashboard
https://mysite.com/shopping-cart

Преимущества

  • Обычные URL-адреса выглядят красиво и аккуратно.
  • Эти типы URL-адресов имеют большее преимущество с точки зрения SEO.
  • Строительные леса веб-приложений с использованием таких фреймворков, как Angular, поддерживают это по умолчанию.
  • Современные серверы разработки (например, ng serve в Angular) также поддерживают это.

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

Вызовы

Когда мы рассматриваем обычные URL-адреса для одностраничных приложений, вам необходимо настроить свой веб-сервер для его поддержки.

  • Необходимо настроить веб-сервер для обслуживания index.html для путей маршрута SPA.
  • Поскольку вносить в белый список каждый путь маршрута SPA на веб-сервере непрактично, необходимо иметь отдельный шаблон для API, чтобы отличать их от маршрутов SPA (например, / api / *, выделенный для API).
  • Необходимо соблюдать особую осторожность при определении ссылок URL-пути в SPA, поскольку это может привести к полной перезагрузке страницы.
  • В некоторых случаях, например, при раздельном размещении внешнего и внутреннего интерфейса, вам понадобится шлюз для выполнения маршрутизации на основе путей на стороне сервера.

Хешированные пути URL

Хешированные URL-адреса будут иметь следующий формат. Часть, отделенная хешем, называется фрагментом или якорем.

https://mysite.com/#/dashboard
https://mysite.com/#/cart

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

Преимущества

  • Браузеры не рассматривают фрагмент пути после хеша как отдельную страницу. Такое поведение браузера идеально подходит для одностраничных приложений, поскольку при обновлении страницы будет перезагружен index.html.
  • Определение ссылок с хешем во внешнем интерфейсе безопасно, так как это не приведет к перезагрузке страницы.
  • Конфигурация сервера проста и позволяет легко различать запросы API и внешнего интерфейса (тем не менее, нам нужно спланировать пути к ресурсам внешнего интерфейса).

Недостатки

Когда дело доходит до хешированных URL-адресов, основным недостатком является его внешний вид.

  • Некоторые пользователи могут посчитать это необычным.
  • Не лучший вариант для SEO.

В противном случае это проще всего реализовать для SPA.

Обработка URL-путей в SPA

Сегодня почти все современные фреймворки SPA содержат модуль маршрутизации со встроенной поддержкой для обработки изменений URL или фрагментов.

В противном случае вам придется разработать собственное решение для отслеживания изменений URL-адресов в SPA. Чтобы реализовать собственный маршрутизатор, вы можете использовать следующие API-интерфейсы браузера.

  • API истории - дает прямой доступ к интерфейсу истории вашего браузера. Это позволяет выполнять манипуляции с URL без хешей. У него есть такие методы, как back(), forward(), которые позволяют переходить к предыдущим или следующим состояниям на основе истории просмотров.
  • AP Location I вместе с прослушивателем событий onHashChange - в этом методе браузер будет запускать onHashChange каждый раз, когда он видит изменение хэша в URL-адресе. Вы можете легко управлять изменениями хэша без связи с сервером, используя этот метод.

Резюме

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

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

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

Выбор остается за вами!

Учить больше



Использование объекта URL в JavaScript
Узнайте все, что нужно знать об объекте URL blog.bitsrc.io





Революция Micro Frontend с помощью Webpack 5, Module Federation и Bit
Посмотрите, как готовящийся к выпуску плагин Module Federation изменит работу микро-интерфейса blog.bitsrc.io





Маршрутизатор React против маршрутизатора Reach
Какую библиотеку маршрутизации React следует использовать? blog.bitsrc.io