Одностраничные приложения (SPA) 🚀 набирают обороты. Не только средние, но и крупные компании, такие как Facebook, YouTube, Upwork, AWS и т. Д., Перешли от многостраничных приложений (MPA) к SPA.

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

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

Давайте рассмотрим некоторые проблемы по очереди и способы их решения.

1. Поисковая оптимизация (SEO)

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

Что делать, если вы хотите разработать свой следующий веб-сайт с помощью фреймворка SPA и одновременно нуждаетесь в SEO. Это не так уж и сложно, поскольку некоторые платформы поддерживают SSR и предлагают готовые решения для SSR.

Вы можете прочитать подробности по ссылкам ниже:

2. jQuery

Большинство разработчиков, имеющих опыт классической веб-разработки или использующих jQuery в одном из своих проектов, будут использовать jQuery для управления DOM, выполнения запроса AJAX и т. Д. Это может показаться прямым подходом, но в мире одностраничных приложений jQuery считается анти-шаблоном.

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

Например, используя fetch вместо $ .ajax, который поставляется предварительно упакованным в современном браузере, или библиотеку axios npm, которая также позволяет отменять запрос и довольно легкий вес.

Давайте будем честными, все должно закончиться, и если вам не нужно поддерживать очень старый браузер, нет смысла использовать его для современных браузеров. Эти API-интерфейсы, предлагаемые браузером, бесплатны, отсутствие дополнительной загрузки скриптов также означает более быстрое время загрузки.

3. Пакеты CSS и JS

По мере того как размер нашего приложения увеличивается, увеличивается размер файлов JS и CSS, загрузка такого приложения потребует времени, минификация и конкатенация CSS и Пакеты JS помогут значительно уменьшить размер этих ресурсов.

Поскольку одностраничное приложение быстро развивается и изменения вносятся быстро, оно требует обновления ресурсов на сервере, как только они будут развернуты. В разных приложениях используются разные стратегии кэширования, что помогает, когда пользователи повторно посещают приложение, ресурсы загружаются из кеша, что экономит время и пропускную способность для пользователя. Но кеширование этих ресурсов создает другую проблему: если в вашем JS есть ошибка, и вы внесли исправление, она может не попасть в клиент даже после развертывания, поскольку кешированная версия предоставляется пользователю браузером. Чтобы справиться с этим, необходимо использовать хешированное именование ресурсов, которое помогает в очистке кеша. Например, вместо названия вашего app.bundle.js вы можете назвать его app. [Hash] .bundle.js и продолжать изменять хеш-значение каждый раз, когда вы создаете новый build, такие сборщики, как W ebpack, предоставляют эту стратегию «из коробки», так что вам действительно не нужно ничего делать самостоятельно.

4. Аналитика

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

5. Ленивая загрузка

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

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

6. Маршрутизация

Маршрутизация - это способ перемещаться между страницами вашего приложения.

Есть 2 типа стратегий маршрутизации

а. Маршрутизация на основе хэша:

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

https://www.example.com/#/user/1

Часть после хэша (/ user / 1) является только клиентской стороной, и при изменении этой части перезагрузки не происходит. Поскольку манипуляции с маршрутами полностью выполняются на стороне клиента внутри JS-скрипта, для того, чтобы позволить браузеру переходить назад и вперед по истории, необходимо вручную обрабатывать на стороне клиента, что, конечно, требует некоторой работы.

б. Маршрутизация с принудительной отправкой:

Существует новый API истории HTML5, который используется для управления историей стека истории приложения. У нас есть, например, window.history.back () для перемещения на шаг назад или window.history.forward () для перехода вперед. Этот API предоставляет множество методов "из коробки". И это действительно здорово, но в нем есть свои проблемы.

Давайте проанализируем URL www.example.com , когда пользователи вводят его в своем браузере, он возвращает index.html и сайт загружается отлично. Теперь пользователь переходит к www.example.com/user/1 и открывает представление с деталями пользователя 1. Проблема в том, что если пользователь перезагружает веб-сайт, сервер будет искать www.example.com/user/1/index.html , которого не существует. . Поскольку браузер возвращает index.html только для www.example.com, который является корневым. И 404 для www.example.com/user/1, потому что каталог user / 1 не существует на сервере и, следовательно, не имеет собственного index.html.

Чтобы решить эту проблему, вам нужно вернуть index.html для всех входящих запросов на сервер. Он больше не будет возвращать 404 для www.example.com/user/1.

Это решает нашу проблему, но вернет index.html для несуществующего маршрута в приложении. Вы можете либо жить с этим, либо добавить настраиваемую обработку маршрутов на сервере, например. добавить конфигурацию для маршрутов в APACHE и т. д., это уродливый способ, но все же помогает.

Вывод

Ключевой вывод из этой статьи заключается в том, что фреймворки SPA, как и любые другие фреймворки, будь то Backend или Frontend, имеют свои собственные проблемы. Но эти проблемы никогда не останутся там навсегда, поскольку они всегда работают над поиском решений для подобных проблем.

- Это все, ребята. Спасибо за чтение. 🎉

Если у вас есть предложения или комментарии, оставьте их под статьей.