Одностраничное приложение javascript - IT Справочник
Llscompany.ru

IT Справочник
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Одностраничное приложение javascript

Создаем одностраничный сайт SPA. Разбираемся с History API

Одностраничные сайты или Single Page Applications (SPA) — это круто. Главный их профит в том, что SPA быстрее и отзывчивее на действия пользователей. Достигается это за счет переноса логики работы на клиентскую сторону и активного взаимодействия с сервером посредством ajax.

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

Зачем это надо и как это сделать, приложив немного усилий? Об этом ниже. Поехали.

Итак, зачем это баловство?

Самое главное — это скорость работы.

Конечно, при разработке одностраничного сайта-визитки мы столкнемся с некоторыми проблемами:

  • 1. Как подступиться, с чего начать?
  • 2. Как разобраться с историей браузера, с History API?
  • 3. Какой фреймворк или библиотеку изучить: ангуляр, реакт? А мы ни одного не знаем.
  • 4. Как заставить поисковики индексировать одностраничный сайт?

Ответы на эти вопросы:

  • 1. Разберемся в этой же статье, на примере простого сайта
  • 2. Тоже расскажу ниже, это десяток строк кода
  • 3. Никакой, обойдемся нативным javascript-ом и jQuery в качестве помощника
  • 4. Про поисковики будет следующая статья из этой серии

Почему без ангуляра-реакта?
Конечно же, это очень нужные темы, рекомендую их изучать. Но для нашего примера они не понадобятся, нам достаточно обладать минимальными знаниями javascript-a.

Одностраничники — это тема не одной статьи. Это будет целый проект, серия статей минимум из трех штук. И затрагиваться в нем будут самые разные темы. Но уточню. Мы будем строить не сложную админку со взаимодействием с сервером посредством REST API (по крайней мере, в самом начале). В первых уроках наш одностраничный сайт будет обычной визиткой из десятка страниц. Но сайт будет работать без перезагрузки страниц и радовать наших пользователей скоростью и отзывчивостью интерфейса.

Идея сайта, как он устроен

Возьмем самый обычный корпоративный сайт: главная страница, раздел «О проекте», контакты и блог. В разделе «Блог» будет несколько ссылок на внутренние страницы. На каждой странице забьем какой-нибудь контент и вставим немного перекрестных ссылок.

На каждой странице сайта, как правило, есть повторяющийся контент. У нас это будет шапка и меню. И есть основное содержимое страницы, которое меняется. Мы сделаем так: загрузим страницу всего один раз, а потом кликая по ссылкам, будем динамически подгружать нужное содержимое аяксом. При этом мы будем менять заголовок страницы во вкладке браузера, url в адресной строке и запоминать историю в браузере, чтобы работала навигация через кнопки Назад/Вперед браузера.

Контент для каждой отдельной странице будет храниться в отдельном html-файле.

Можете сразу посмотреть, что у нас в итоге получится — Демо-сайт

Структура сайта и подготовительные работы

Структура файлов-папок такова. В корне проекта файл index.php и .htaccess. Почему именно php, а не html, расскажу позже. В папке css лежат стили в файле main.css. В папке js — библиотека jquery.js и главный файл приложения main.js. В папке pages лежат html-файлы с содержимым сайта — на каждую страницу по одному файлу.

Готовим контент

Я сделаю демо-сайт на примере своего проекта webdevkin. Набор страниц будет таким:

  • — main — Главная
  • — about — О проекте
  • — blog — Блог

  • — shop — Интернет-магазины
  • — frontend — Фронтенд
  • — mysql — База данных MySql
  • — widgets — Встраиваемые виджеты

Соответственно, в папке pages будут лежать 9 html-файлов. Всю разметку для контента найдете в исходниках. Для примера приведу содержимое только одного файла — simpple.html

Как видно, никаких head, body, html, script здесь нет — только разметка, относящаяся к конкретной странице.

index.php и .htaccess

Почему не index.html?
Дело в том, что на нашем сайте будет одна-единственная физическая страница — index. Но нас интересуют и такие адреса, как site.ru/about, site.ru/contacts и прочее. Но страниц about и contacts в корне нашего сайта нет. Папка pages с набором html-файлов — это не полноценные страницы, а просто куски html-кода, которые встраиваются внутрь общего каркаса.

Поэтому, чтобы при обращении к site.ru/about не посыпались 500, 403 и еще бог знает какие ошибки, мы должны все входящие запросы на сайт перенаправлять на index.php, который уже и будет эти запросы разруливать. Впрочем, пока что index.php у нас — это обычная html-разметка без единой строчки php-кода (но это только пока). А в .htaccess мы пропишем следующее. Возвращаться к нему придется редко.

В тему
Однажды я писал статью про Простой RESTful-сервис на нативном PHP. Там Вы найдете немного больше информации про такой способ перенаправления запросов.

html-код будет у нас очень простым. В head подключаются стили css/main.css. В подвале 2 js-файла: js/jquery.js и js/main.js. А в body будет следующее:

Сначала выводим меню. Дальше идет заголовок страницы. И ниже пустой div с id=content (не обращайте внимания на style=»» — парсер когда-нибудь выбесит и я его заменю). В #content будут подгружаться динамически содержимое страниц из файлов pages/*.html. Пока ничего интересного.

Только обратите внимание на атрибуты data-menu и data-link=»ajax» у ссылок. Они введены для того, чтобы отличать ссылки-навигации от обычных внешних ссылок, которые на нашем сайте тоже будут. data-link=»ajax» означает, что при клике по этой ссылке мы перехватим стандартное поведение браузера и возьмем работу со ссылкой в свои руки. А data-menu означает, какой пункт главного меню будет выделен при клике на оную ссылку. Здесь data-menu дублируется с атрибутом href, но возможны и другие варианты. Например, когда мы залезем в раздел frontend блога, то мы укажем data-menu=»blog».

2 примера для наглядности:

Это ссылка на страницу site.ru/simpple, при переходе на которую содержимое страницы подгрузится из папки pages/simpple.html, и при этом будет выделен пункт главного меню «simpple»

А это обычная внешняя ссылка, кликнув на которую мы отправимся на внешний ресурс.

Стили main.css

Быстро пролистаем и скопипастим самое скучное — файл css/main.css.

А вот теперь самое интересное — javascript-код, который превратит наш набор отдельных файлов в одностраничный сайт.

javascript. Общий код и конфиги

Зададим каркас js-кода.

Мы имеем отдельный модуль app, который при загрузке страницы запускает свою функцию init. В ней навешиваем обработчики событий и выполняем еще некоторый код. Также видим 2 объекта: config и ui. В ui будут закэшированы все dom-элементы, которые понадобятся нам в работе.

$menu нам нужно, чтобы выделять отдельные пункты меню, $pageTitle будем менять динамически при переходе между страницами, а в $content будет подгружаться содержимое файлов pages/*.html

А вот config выглядит интереснее.

siteTitle: ‘Webdevkin SPA’ — заголовок сайта, используется в нескольких местах.
mainPage: ‘main’ — указываем стартовую страницу сайта, ту, которая откроется при заходе на site.ru. Сейчас это главная страница main, но Вам запросто может прийти в голову поставить стартовую, например, «О проекте» — about.

Самое важное во всем конфиге — это объект pages. Каждое поле объекта описывает одну страницу сайта. Сейчас нам понадобятся только 2 пункта: заголовок страницы и меню, к которому оная страница относится. Ключи объекта, то есть страницы, совпадают с названиями файлов в pages/*.html и атрибутами href во внутренних ссылках.

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

Подгрузка контента с помощью ajax. History API

Пойдем по порядку. Займемся функцией init, в которой есть привязывание нужных событий _bindHandlers

В первой строке мы отлавливаем клики на внутренние ссылки a[data-link=»ajax»] и отправляем их в функцию _navigate. Теперь мы окончательно убедились, что нужны отдельные атрибуты data-link=»ajax» 🙂

Далее window.onpopstate = _popState;
Из документации.
Событие popstate отсылается объекту window каждый раз, когда активная запись истории меняется между двумя записями истории для одного и того же документа.
Проще говоря, это срабатывание кнопок Назад/Вперед в браузере. Как мы видим, нативное поведение браузера тоже нужно перехватывать. Поэтому мы отдадим управление функции _popState.

Для лучшего восприятия приведу код сразу для обеих функций

При явном клике по ссылке _navigate мы останавливаем всплытие события клика и отменяем дефолтное поведение браузера (переход по ссылке). Затем мы определяем страницу, которую мы хотим загрузить (понимаем по атрибуту href), и вызываем новую функцию _loadPage. Она и сделает всю основную работу по загрузке контента, изменению заголовка и прочее-прочее. И в конце через history.pushState добавляем новую запись в истории браузера. Да, мы сами, явным образом создаем историю браузера. Тогда, когда считаем нужным. И сохраняем данные о загружаемой странице в объект . Эти данные нам пригодятся в следующей функции _popState.

В _popState идея аналогична: ищем нужную страницу и запускаем ту же _loadPage.

e.state && e.state.page — вытаскивает нам страницу из объекта истории, которую мы предусмотрительно записали в _navigate. Если же объект e.state недоступен (например, когда мы первый раз зашли на сайт site.ru и еще не успели побродить по нему), то берем страницу, указанную главной в нашем конфиге — config.mainPage.
По совести говоря, функция history.pushState и тот факт, что в window.onpopstate доступен объект e.state с данными, записанными в pushState, — это все, что нам достаточно знать о History API. Для более любопытных товарищей, не сомневаюсь, что гугление поможет найти и другие хорошие способы работы с историей браузера.

Мы же глубокими изысканиями заниматься не будем, а напишем код главной функции _loadPage

Выглядит он вполне заурядно. Сначала формируем url, то есть путь, по которому мы загрузим html для страницы. Потом вытаскиваем из конфига заголовок страницы и пункт меню, подлежащий выделению. Далее получаем html-содержимое страницы через банальный jQuery.get и выполняем еще ряд нехитрых действий.

а) Обновляем заголовок страницы
б) В 2 строки выделяем нужный пункт меню
в) Меняем заголовок уже на самой странице, в html-коде
г) Загружаем собственно html-содержимое страницы, полученное из url

Почти все! Остался маленький момент. Если мы сейчас перейдем, например, на страницу site.ru/blog и обновим ее, то загрузится не блог, а пустая страница. Потому что при инициализации мы _loadPage не вызываем. Чтобы это исправить, нам нужно дописать пару строк в функцию init, которая в итоге будет выглядеть так

Вот теперь точно все!

Подведем итоги и напомним ссылки

Итак, мы написали простой, но вполне рабочий одностраничный сайт, а также немного узнали, как работает History API. Честно говоря, чувствую себя режиссером плохого фильма, когда 80% времени ведут к какой-то грандиозной развязке, а в конце все оказывается намного проще, чем ожидалось.

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

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

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

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

Одностраничные приложения

Одностраничные приложения становятся всё популярнее, поскольку спрос на высоко отзывчивые приложения растёт. Мы могли бы для их создания использовать Ajax и Javascript, но применим Angular в качестве структурного фреймворка для динамических веб-приложений, эффективный и простой в использовании, как его описали люди которые его сделали.

Мы собираемся создать простое приложение, в котором будет только главная страница, страница «О нас» и страница с датой. При этом сделаем так, чтобы не нужно было обновлять страницу для просмотра изменений, все они должны отображаться сразу.

Мы будем использовать:

Приступая к работе

Чтобы приступить к проекту вы должны скачать Bootstrap, а также Bower (здесь вы найдёте необходимую информацию как это сделать).

Для начала создадим папку с именем SinglePageApp (можно назвать её как пожелаете) и внутри неё HTML-файл с именем index.html и JavaScript-файл с именем app.js.

Настройка AngularJS

Попросим Bower установить пакет Angular, выполнив эту команду в терминале (убедитесь, что вы находитесь в папке проекта):

Тогда, вновь используя Bower, мы устанавливаем пакет Angular-Route, выполнив:

После выполнения этих команд вы заметите, что в папке нашего проекта добавилась папка bower_components, внутри которой находятся две папки, одна с именем angular, а другая angular-route. Мы воспользуемся ими позже. Затем открываем app.js и пишем код JavaScript для создания модуля Angular и добавляем к нему зависимость ngRoute . Это должно выглядеть так:

Настало время определить маршруты с помощью функции config() , предоставленной angular.module. Прямо под кодом для модуля, в файле app.js мы вставляем этот код:

Мы внедрили $routeProvider в качестве параметра функции. Теперь when() для $routeProvider может применяться для настройки маршрутов. Эта функция принимает два параметра: название маршрута и объект, который содержит различные детали для маршрута. Мы будем использовать только два из этих свойств: templateURL — указывает относительное положение файла представления, начиная с index.html; и контроллер, связанный с этим представлением.

Мы достигли точки, где должны создать контроллеры для различных представлений. Сначала мы создаём папку с именем controllers в папке js и внутри неё создаём файл JavaScript с именем controllers.js, в который помещаем этот фрагмент кода:

Не забудьте про controllers.js в файле index.html. Вы даже можете разместить этот код в файле app.js, но это не рекомендуется, поскольку может снизить читабельность кода и в более тяжёлых приложениях усложнить материал.

HTML-разметка нашего приложения

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

Теперь установим скрипты Bootstrap, Angular и Angular-Route путём добавления этого кода после тега
:

Кроме того, мы добавляем файл app.js, так как он содержит модуль и другие необходимые вещи, так:

Вы можете разместить всё это в разделе , прямо перед тегом

Архитектура одностраничного JavaScript веб-приложения?

Как должно быть структурировано сложное одностраничное веб-приложение JS на стороне клиента? В частности, мне интересно, как чисто структурировать приложение с точки зрения его объектов модели, компонентов UI, любых контроллеров и объектов, обрабатывающих персистентность сервера.

Поначалу мне показалось, что у него припадок. Но с компонентами UI, вложенными на различных глубинах (каждый со своим собственным способом действия / реакции на данные модели, и каждый генерирует события, которые они сами могут или не могут обрабатывать непосредственно), не похоже, что MVC может быть чисто применен. (Но, пожалуйста, поправьте меня, если это не так.) —

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

14 Ответов

MVC архитектура PureMVC/JS является самой элегантной IMO. Я многому у него научился. Я также нашел Scalable JavaScript Application Architecture by Nicholas Zakas полезным в исследовании вариантов архитектуры на стороне клиента.

  1. Я обнаружил, что просмотр, фокусировка и управление вводом-это области, которые требуют особого внимания в одностраничных веб-приложениях
  2. Я также счел полезным абстрагировать библиотеку JS, оставив дверь открытой, чтобы изменить мнение о том, что вы используете, или смешать & матч, если возникнет необходимость.

Презентация Николаса Закаса, которой поделился Дин, — это очень хорошее место для начала. Я тоже некоторое время пытался ответить на тот же вопрос. Сделав пару крупномасштабных продуктов Javascript, я подумал о совместном использовании полученных знаний в качестве эталонной архитектуры на случай, если она кому-то понадобится. Взгляните на:

В нем рассматриваются общие проблемы развития Javascript, такие как:

  • Структурирование решения
  • Создание сложной иерархии модулей
  • Автономные компоненты UI
  • Межмодульная связь на основе событий
  • Маршрутизация, История, Закладки
  • модульное тестирование
  • Локализация
  • Генерация Документов

Как я строю приложения:

  • ExtJS framework, одностраничное приложение, каждый компонент определен в отдельном файле JS, загружается по требованию
  • Каждый компонент связывается со своим собственным выделенным веб-сервисом (иногда более одного), получая данные в ExtJS хранилища или специальные структуры данных
  • Рендеринг использует стандартные компоненты ExtJS, поэтому я могу привязывать магазины к сеткам, загружать формы из записей, .

Просто выберите фреймворк javascript и следуйте его рекомендациям. Мои любимые-это ExtJS и GWT, но YMMV.

Сделайте NOT рулон вашего собственного решения для этого. Усилия, необходимые для дублирования того, что делают современные фреймворки javascript, слишком велики. Всегда быстрее адаптировать что-то существующее, чем строить все это с нуля.

Ответ — использование слова ‘complex’ в самом вопросе. Таким образом, общая тенденция будет заключаться в том, чтобы искать комплексное решение с самого начала.

Ответ — Все, что неизвестно или частично понято. Пример: теория гравитации даже сегодня является COMPLEX для меня, но не для сэра Исаака Ньютона, который открыл ее в 1655 году.

Ответ — понимание и простота.

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

Ответ — Потому Что,

— >SPA-это не какая-то новая базовая технология, для которой нам нужно заново изобрести колесо для многих вещей, которые мы делаем в разработке приложений.

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

— >Это довольно недавно выявленный шаблон дизайна, поэтому понимание SPA как Шаблона дизайна проходит долгий путь в принятии обоснованных решений об архитектуре SPA.

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

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

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

Источник данных: модели / коллекции моделей

Разметка для представления данных: Шаблоны

Взаимодействие с приложением: события

Захват состояния и навигация: маршрутизация

Утилиты, виджеты и плагины: библиотеки

Дайте мне знать, если это поможет в любом случае и удачи с вашей архитектурой SPA !!

Лучше всего посмотреть на примеры использования других фреймворков:

TodoMVC витрины много-много SPA рамок.

Вы можете использовать javascript MVC framework http://javascriptmvc.com/

Веб-приложение, над которым я сейчас работаю, использует JQuery, и я бы не рекомендовал его для любого большого одностраничного веб-приложения. Большинство фреймворков, например Dojo, yahoo, google и другие, используют пространства имен в своих библиотеках, но JQuery этого не делает, и это является существенным недостатком.

Если ваш веб-сайт будет небольшим, то JQuery будет в порядке, но если вы собираетесь построить большой сайт, то я бы рекомендовал посмотреть все доступные фреймворки Javascript и решить, какой из них больше всего соответствует вашим потребностям.

И я бы рекомендовал применить шаблон MVC к вашему javascript/html и, вероятно, большую часть вашей объектной модели для javascript можно было бы сделать как json, который вы фактически возвращаете с сервера через ajax, а javascirpt использует json для визуализации html.

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

Я использую Samm.js в нескольких одностраничных приложениях с большим успехом

Альтернатива: взгляните на ItsNat

Думайте в JavaScript, но кодируйте то же самое в Java в сервере с тем же DOM APIs, в сервере намного проще управлять вашим приложением без пользовательского клиента/мостов, потому что UI и данные находятся вместе.

Проверьте http://bennadel.com/projects/cormvc-jquery-framework.htm Бен довольно острый, и если вы покопаетесь в его блоге, у него есть несколько хороших постов о том, как CorMVC собирается вместе и почему.

NikaFramework позволяет создать одностраничное приложение. Также позволяет записывать HTML , CSS ( SASS), JavaScript в отдельные файлы и bundle их в один выходной файл в конце концов.

Я бы рекомендовал исследовать Йомена . Это позволит вам использовать существующий «best practice» для вашего нового проекта.

если вы решите использовать Angular.js, есть генератор Yeoman, который дает вам структуру для маршрутизации, просмотров, сервисов и т. д. Кроме того, вы можете протестировать, минимизировать свой код и т. д.

Если вы решили использовать магистраль, проверьте этот генератор

Похожие вопросы:

Я хотел понять общую архитектуру для разработки одностраничного приложения (в основном через JavaScript) Допустим, у меня есть страница входа (Usernam/Password), и при успешной аутентификации мне.

Мне нужна помощь, я новичок для SOA(сервис-ориентированная архитектура) как начать строить SOA для веб-приложения? я пробовал exproled, я до сих пор не могу найти, Как построить SOA и использовать.

Какая архитектура веб-приложения хорошо работает при получении / отправке SMS текстовых сообщений? Под архитектурой я подразумеваю конкретную архитектуру, а не общую, такую как MVC. Фон: я создаю.

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

У меня есть веб-приложение, работающее под Apache Wicket (a Java ee MVC framework). На данный момент это веб-сайт. Я думаю об архитектуре, которую можно использовать для создания мобильных.

Мы разрабатываем одностраничное веб-приложение с angular js. Наша проблема заключается в том, что при навигации по различным URLS все больше и больше java скриптов было добавлено в память браузера.

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

Поэтому я начал разработку одностраничного веб-приложения с использованием AngularJS. Чтобы дать вам представление о размере этого приложения, оно будет иметь около 20-30 APIs и 100 конечных точек.

У меня есть одностраничное веб-приложение, которое просто имеет index.html в качестве страницы входа для приложения, все остальные URLs и экраны загружаются на основе скриптов extjs. Я добавил код.

У меня есть вопрос, связанный с Ruby по Rails соглашению об именовании. Я пытаюсь создать одностраничный сайт. Как лучше всего называть главный контроллер одностраничного приложения в Ruby на Rails?

Что такое SPA или одностраничный портал

В этой статье речь пойдет о Single Page Application (SPA). Будут рассмотрены плюсы и минусы web-приложения построенного по принципам одностраничного сайта (SPA)

Что такое SPA

Single Page Application – сокращенно SPA, в переводе на русский язык означает “Приложение одной страницы”. Другими словами SPA – это web-приложение, размещенное на одной web-странице, которая для обеспечения работы загружает весь необходимый код вместе с загрузкой самой страницы. Приложение такого типа появились сравнительно недавно, с началом эры HTML5 и SPA является типичным представителем приложений на HTML5.

Как мы знаем, HTML5 это нечто иное как HTML + CSS3 + JavaScript + [несколько новых тегов]. Таким образом, SPA — это приложения написанные на языке JavaScript. И, следовательно, немного перефразировав предыдущие определение получаем:

“SPA – это web-приложение, размещенное на одной странице, которая для обеспечения работы загружает все javascript-файлы (модули, виджиты, контролы и т.д.) , а также файлы CSS вместе с загрузкой самой страницы.”

Если приложение достаточно сложное и содержит богатый функционал, как например, система электронного документооборота, то количество файлов со скриптами может достигать нескольких сотен, а то и тысяч. А “…загрузка всех скриптов…” никоим образом не означает, что при загрузке сайта будут загружены сразу все сотни и тысячи файлов со скриптами. Для решения проблемы загрузки большого количества скриптов в SPA призван API под названием AMD. AMD реализует возможность загрузки скриптов по требованию. То есть, если для “главной станицы” одностраничного портала потребовалось 3 скрипта, они будут загружены стразу перед стартом программы. А если пользователь кликнул на другую страницу одностраничного портала, например, “О программе”, то принцип AMD загрузит модуль (скрипт + разметка) только перед тем как перейти на эту страницу.

Получается немного скомкано: “Одна страница.. другая станица, третья страница… одностраничный портал”. Расставим все точки над “Ё”. Страница сайта, на котором размещены все ссылки на все CSS, и ссылки на скрипты, необходимые для работы SPA мы назовем “Web-страница”. Файл с такой странице обычно называется “index.html” (в ASP.NET MVC может быть index.cshtml или index.vbhtml или даже index.aspx) А страницы, которые переключает пользователь внутри одностраничного портала назовем “модули”.

Давайте рассмотрим плюсы и минуты данного подхода. Зачем всё это нужно и почему SPA так популярен?

SPA: Плюсы

Первым плюсом стоит отметить тот факт, что приложения на SPA отлично работают на устройствах как стационарных, так и мобильных. “Большие” компьютеры, планшеты, смартфоны, и, в конце-концов, простые телефоны (некоторые) могут беспрепятственно работать с сайтами построенных по принципу SPA. Итак, первый “плюс” – работа на большом количестве устройств , а значит, создав одно приложение, вы получаете гораздо большую аудиторию пользователей нежели при использовании стандартного подхода.

Далее второй “плюс” – богатый пользовательский интерфейс , так называемый User Experience. Так как web-страница одна, построить богатый, насыщенный пользовательский интерфейс гораздо проще. Проще хранить информацию о сеансе, управлять состояниями представлений (views) и управлять анимацией (в некоторых случаях).

Третий “плюс” – SPA существенно (в разы) сокращает так называемые “хождения по кругу”, то есть загрузку одного и того же контента снова и снова . Если ваш портал (сайт) использует шаблон, то вместе с основным содержанием какой-либо страницы посетитель сайта обязательно загружает разметку шаблона. Да, кэширование данных на данном этапе развития WWW достигло высочайших результатов, но если нечего кэшировать, то и время, и ресурсы на это не тратятся.

SPA: Минусы

Если вы программируете на C#, то единственным минусом SPA является необходимость изучения JavaScript. Во всяком случае, других глобальных проблем мне выяснить не удалось.

Составляющие SPA

Принципы любого фреймворка (о них поговорим позже), который реализует парадигму SPA должны придерживаться следующих понятий и определений:

  • SPA поддерживает клиентскую навигации. Все “хождения” пользователя по модулям-страницам однозначно фиксируются в истории навигации, причем навигация при этом является “глубокой”, то есть если пользователь скопирует и откроет ссылку на внутреннюю модуль-страницу в другом браузере или окне, он попадет на соответствующую страницу.
  • SPA размещается на одной web-странице, значит всё необходимое для работы сайта (портала) скрипты и стили должны быть определены в одном месте проекта – на единственной web-странице.
  • SPA хранит постоянно состояние (важные переменные) работы клиента (клиентского скрипта) в кэше браузера или в Web Storage.
  • SPA загружает все скрипты требующиеся для старта приложения при инициализации web-страницы.
  • SPA постепенно подгружает модули по требованию.

Шаблоны SPA (SPA templates)

Как вы уже наверное догадались, SPA – это абстрактное понятие. Это принцип архитектуры приложения. Давайте поговорим с чего начать при разработке сайта по принципам SPA.

Существует большое количество базовых библиотек (фреймворк – от английского слова framework – “основа, структура, каркас”), которые реализуют принцип Single Page Application. Что дают эти фреймворки:

  • обеспечивают базовые принципы для SPA разработки, минимизируя трудозатраты на решение универсальных задач (смотри раздел “Составляющие SPA);
  • фреймворки созданы сообществом разработчиков, а значит используют опыт создания сайтов множества программистов;
  • фреймворки являются отправной точкой для создания структуры на основе Single Page Application.

Так как я уже много лет работаю на платформе NET, то я буду рассматривать шаблоны Single Page Application на основе ASP.NET. Давайте рассмотрим следующую сравнительную таблицу.

Сравнение возможностей шаблонов SPA

В таблице приведены наиболее распространённые шаблоны для как основа построения Single Page Application приложения. Обратите внимание, синим фоном выделены базовые кирпичики для построения полноценного фреймворка, таких как DurandalJS и HotTowel, которые выделены зеленым цветом.

Итак, следуя данным предоставленных в таблице вы можете создать Single Page Application приложение используя “голый” ASP.NET и KnockoutJS. Однако, реализацию работы с данными (DAL) вам придется писать самостоятельно, впрочем, как и управление навигацией и историей навигации в том числе.

С другой стороны, вы в праве выбрать Ember или BreezeJS, или даже AngularJS от Google как основу своего сайта или даже как основу своего собственного фреймворка, факт остается фактом, недостающие принципы составляющие концепцию SPA вам придется реализовывать самостоятельно.

Альтернативой предыдущему решению может послужить выбор уже готового полноценного фреймворка (помечены в таблице зеленым фоном). У каждого варианта существуют свои “плюсы” и “минусы”.

Заключение

Примеров приложений построенных по принципам Single Page Application очень много. Одним из самых мощных и общеизвестных является GMail – почтовый сервис компании Google.

Я же хочу привести, как пример, сервис чтения RSS-каналов SilverReader по одной простой причине: этот сервис сделан с использованием фреймворка DurandalJS. И именно этот фреймворк я использовал для построения своего сайта “Что значит имя”.

Как написать одностраничное приложение (SPA) с использованием Vue.js


Одностраничные приложения (SPA) имеют мнжество преимуществ, таких как скорость, по-настоящему хороший UX, и полный контроль HTML-разметки. Становится всё больше и больше сайтов SPA; всё больше инструментов, которые упрощают процесс разработки SPA. Вы, вероятно уже читали о молодом и перспективном фреймворке Vue.js. Предлагаю вам глубже погрузиться в Vue и на конкретном примере разобраться с простым SPA.
Мы напишем клиент-серверное приложение простейшего блога. Приложение будет отображать список записей а также полный текст каждой отдельной записи. И само собой, всё это будет происходить без перезагрузки страницы.
Ознакомившись с примером этого приложения, вы научитесь извлекать данные в Vue, создавать роуты и разберётесь с интересной особенностью Vue — однофайловыми компонентами.

Бэкенд

В этом руководстве мы в основном сосредоточимся на фронтенде на Vue. Размышлять о написании REST бэкенда мы не будем. Для примера будет использоваться сервис jsonplaceholder.typicode.com предостовляющий заглушку в виде REST API.

Фронтенд

Инструменты

Начать работу с Vue очень просто. С использованием правильных инструментов это ещё проще. Рекомендую взглянуть на проект vue-awesome, который содержит список инструментов, компонентов, библиотек и плагинов на все случаи жизни.

Vue-cli

При создании нового проекта рекомендуется воспользоваться Vue-cli. Так можно создавать проекты с использованием официальных шаблонных проектов Vue, или одного из множества шаблонных проектов с открытым исходным кодом, и, конечно же, вы можете создать свой собственный и использовать его в любом месте.
Итак, для начала установим vue-cli в качестве глобального пакета:

Затем проинициализируем проект с выбранным шаблоном; для нашего примера более чем достаточно использовать webpack-simple.

Далее перейдём в папку vue-spa и запустим npm install в терминале. После установки всех пакетов, мы можем запустить наше приложение в режиме разработки.

Эта команда автоматически запустит наш проект на локальном dev-сервере webpack. В браузере появится наше простейшее приложение Vue. Конечно оно выглядит совсем не так, как бы нам хотелось, и годится лишь в качестве отправной точки для начала чего-то большего. Чтобы продолжить работу, предлагаю сначала ознакомиться со структурой нашего шаблона.

Шаблон webpack-simple

Внутри шаблон webpack-simple имеет следующую структуру:

Файл index.html содержит простую разметку HTML с единственным элементом “app” в body. Он будет заменён на DOM, сгенерированный vue. По этой причине тэг body не рекомендуется использовать в качестве корневого элемента.
В папке src лежит файл main.js, который содержит точку входа webpack. Компоненты Vue импортируются там же. Ещё там описан корневой экземпляр Vue, который пока что имеет два свойства. Свойство ‘el’ обеспечивает экземпляру Vue связь с указанным DOM элементом. Ещё одно — функция отрисовки, генерирующая DOM из App.vue. В общем, это все, что нам нужно знать о структуре шаблона webpack-simple, не так много, не так ли? Основная часть нашего приложения будет запрограммирована в App.vue. Расширение .vue определяет файл как однофайловый компонент vue. Это одна из особенностей Vue с которой мы сейчас познакомимся поближе.

Однофайловые компоненты


Каждый файл *.vue состоит из блоков трёх типов: ,

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

В настоящий момент нам абсолютно нечего отображать в нашей навигационной панели, поэтому давайте получим данные с сервера. Для этого я выбрал Axios — простой в использовании HTTP-клиент. Вы также можете использовать любой удобный для вас способ, например, Vue-ресурс или собственную выборку или даже jQuery Ajax.

Шаг 2

Затем импортируем его в компонент App и определим метод getAllPosts() который будет делать запрос к серверу и присваивать его свойству posts. Вызываем метод в хуке created(), который будет вызываться после создания экземпляра Vue и после установки настроек обращения к данным.

А теперь отобразим все заголовки записей в боковой панели.

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

Шаг 3

Для этого воспользуемся официальной Vue библиотекой vue-router. Как уже понятно из названия, библиотека позволяет настраивать роутинг для нашего приложения.
Установим библиотеку:

Для настройки роутинга вернёмся к файлу main.js. Здесь мы определим настройки роутинга и добавим их в наш экземпляр Vue.

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

Этот путь содержит динамический сегмент :id который указывает на конкретный пост. При этом у нас есть доступ к этому сегменту в компоненте Post через this.$route.params.id. Однако использование $route в нашем компоненте закрепит жесткую связь с роутом, что в свою очередь ограничивает гибкость компонента, поскольку он может использоваться только на определенных URL-адресах. Вместо этого мы можем использовать опцию props и установить её в true. После этого $route.params станет связан с опцией props компонента Post.
Теперь, когда мы создали роутер, мы можем вернуться к нашему приложению и добавить еще несколько строк в шаблон.

Здесь мы имеем два компонента vue-router: и . Первый — это компонент для включения навигации пользователя в приложении с поддержкой роутинга. Второй компонент — это функциональный компонент, который отрисовывает согласованный компонент для данного пути.
Остался заключительный шаг. Нам нужно отобразить содержимое записи поста.

Шаг 4

Перейдём к файлу Post.vue, в котором добавим простой шаблон:

Затем нам нужно установить параметры экземпляра Vue для этого компонента. Здесь все также как в настройках отображения всех постов. Объявим опцию props с меняющимся id, которая будет получать номер нашего поста. Далее, объявим объект данных, как уже делали в App.vue:

Затем опишем метод getPost(), который будет получать только одну запись поста по идентификатору и вызовем его в хуке created().

Почти готово. Если мы запустим приложение сейчас, мы увидим, что, хотя URL-адрес меняется, мы видим единственный пост, который был отрисован первым. Дело в том, что для отрисовки разных постов у нас есть один и тот же компонент, и Vue не нужно его пересоздавать из-за лишней траты ресурсов, а это также означает, что хуки жизненного цикла компонента не будут вызваны.
Чтобы это исправить, нам просто нужно установить watcher для объекта $route.

Теперь всё работает так, как и должно. Чтобы получить версию для продакшина достаточно выполнить команду npm run build в консоли.

Читать еще:  Visual studio code javascript extensions
Ссылка на основную публикацию
ВсеИнструменты 220 Вольт
Adblock
detector