Node.js и одностраничное веб-приложение

Ответ 1

Одностраничные приложения - это те, которые живут в одном документе HTML. Это означает, что если вы хотите отобразить для пользователя какой-то другой контент, в зависимости от состояния приложения, вам нужно будет сделать некоторые манипуляции с DOM (вырезание и замена некоторых элементов текущего документа с помощью другого HTML), чтобы обновить "вид", который видит пользователь. Извините, если это очевидно для вас, пожалуйста, не обижайтесь. Я решил, что начну с этого момента. Поговорите со мной, и я объясню, как ваша маршрутная ситуация будет играть (более или менее).

URL-адреса состоят из нескольких разных частей, каждый из которых информирует браузер о конкретном бите информации, который требуется для загрузки ресурса, к которому пользователь пытается получить доступ. Как правило, ресурсы, которые вы ищете, отключены на сервере где-то, и браузер знает об этом из-за фрагментов в URL, таких как "протокол" ( "http:" ) и "host" ( "www.mydomain.com" ), поэтому он отправляется на этот сервер, чтобы найти то, что вы запрашиваете. В URL-адресах также есть параметры запроса, которые предоставляют некоторую дополнительную информацию серверу о конкретном действии, например условия поиска поискового запроса. После параметров запроса появляется "хэш". Хеш - это то место, где магия одностраничных приложений происходит... ну, ну, вроде.....

Сначала немного о хэше. Когда вы добавляете "#" в URL-адрес, браузер затем интерпретирует информацию, которая появляется после того, как это будет какое-то местоположение (элемент) в текущем отображаемом документе. Это означает, что если у вас есть элемент с идентификатором 'main' и вы добавляете '#main' в конец URL-адреса, например: http://www.example.com#main, браузер будет "прокручивать" (обычно "прыгать" ) в начало этого элемента, чтобы вы могли его видеть. Имейте в виду, что если вы наберете 'http://www.example.com/#main' (с хешем, отделенным от URL-адресом косой чертой), вы будете вынуждать полная перезагрузка страницы, и браузер попытается найти файл по имени "#main" на сервере (я уверен, он его не найдет).

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

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

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

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

Итак, в одностраничном приложении у вас есть один маршрут на сервере, который занимается рендерингом HTML-документа приложения (index.html), и у вас есть маршруты, которые отвечают за обработку данных вашего приложения (создание новые экземпляры в базе данных, вход в систему и выход из нее, редактирование или уничтожение экземпляров в БД и выборка данных...), которые вызываются через запросы AJAX.

Это довольно сложная ситуация в том, что HTML5 позволяет нам отказаться от хеша (с помощью некоторой перезаписи ссылок на сервере), а также иметь возможность использовать кнопки "назад" и "вперед", как если мы фактически перешли от исходного документа (чего у нас нет, потому что мы указали браузер только на тот же самый URL-адрес, только с измененными значениями хэша, поэтому никаких новых загрузок страниц не произошло). Традиционная навигация и привязка к сайту могут быть достигнуты за счет использования API истории браузера, который доступен для IE, начиная с версии 10 (я полагаю), остальные крупные поставщики браузеров уже были к нему довольно немного раньше, поэтому структуры, которые используют эта технология позволит вашим пользователям перемещаться по вашему приложению без хеша в URL-адресе. Объяснение этого - утечка и не требуется для понимания маршрутизации в одностраничных приложениях, но это интересно, и вам все равно придется узнать его в конце концов, возможно.

AJAX следует использовать для запроса JSON с сервера. Запросы AJAX всегда будут попадать на ваш сервер, потому что вы не включаете хэш-символ в запросы AJAX (было бы смешно сделать это, потому что хеш предназначен только для просмотра в документе), поэтому серверные маршруты должны отвечать за раскрытие ваш API данных (рассмотрите RESTful). Хотя это не единственная их цель в одностраничных приложениях, это, пожалуй, самый важный из них.

Соооо, чтобы завершить его, у вас будет два набора маршрутов. Один на клиенте (как часть клиентской стороны, такой как AngularJS или EmberJS, список продолжается... Я предпочитаю Angular, но для этого есть довольно крутая кривая обучения.), А одна на сервере, Когда вы думаете о "серверных маршрутах", думайте об API данных. Когда вы думаете о "маршрутизации страниц", помните, что все это обрабатывается клиентом, с помощью javascript, который вы поставили с исходным ответом сервера (это единственный и единственный необходимый серверный маршрут, связанный с рендерингом HTML в браузер, загружая ваш "index.html" и все необходимые скрипты и таблицы стилей и т.д.). Вы будете использовать промежуточное программное обеспечение express.static для обслуживания статических файлов, поэтому вам не придется беспокоиться о назначении маршрутов для этого материала.

EDIT Быстрое упоминание о реализации AJAX. На сервере у вас будут маршруты, аналогичные тем, которые Алекс предоставил в качестве примеров, и вы будете звонить на эти URL-адреса от клиента, используя какой-либо объект XMLHttpRequest (XHR), доступный вашей инфраструктуре или библиотеке выбора. В настоящее время считается более или менее стандартным и оптимальным вариантом для фреймворков/библиотек для реализации этих запросов как Promises http://wiki.commonjs.org/wiki/Promises/A. Вы должны прочитать немного об этом самостоятельно, но я мог бы обобщить его, сказав, что это асинхронная операция, аналогичная "try, catch, throw" в синхронных операциях. Вы создадите объект обещания, и через него вы попытаетесь загрузить данные с сервера, например, с помощью запроса GET. Убедитесь, что вы назначили функции для обработки запросов, сделанных по URL-адресу, на который вы сделали запрос (серверный маршрут)! Этот объект, который вы создаете и затем передаете запрос серверу, Promises, чтобы вернуть результат запроса к вам после его возврата с сервера (независимо от того, был ли он успешным или нет). Если он успешно, вызовет функцию, которую вы написали, и будет поставлять ее с данными с сервера. Если он терпит неудачу, он вызовет другую функцию, также написанную вами, и предоставит ей объект ошибки (или "причину" для отказа), поэтому вы можете соответствующим образом обработать ошибку.

Надеюсь, что это помогло ответить на ваш вопрос.

Ответ 2

Вам нужно только маршрутизировать запросы, которые вы обслуживаете динамически. Ваш HTML, CSS, JS - это все статические активы. Итак, все, что вам нужно для обработки маршрутизации, - это ваши данные.

Похоже, вам нужен Restful API, который в основном означает, что у вас есть URL-адреса для определенных ресурсов и HTTP-глаголы для их управления.

Что-то вроде:

• GET /books.json - Получить все книги
• POST /books.json - Создайте новую книгу со свойствами, переданными в теле запроса
• GET /books/123.json - Получить книгу с идентификатором 123
• PUT /books/123.json - обновить существующую книгу со свойствами, переданными в теле запроса

Это сообщение в блоге, похоже, показывает, как установить это в Express.

После того, как у вас есть нормальный API, предоставляющий JSON, вы просто используете свои вызовы AJAX, используя его на основе того, какие объекты вы хотите получить.