Причины использования Backbone.js Router для маршрутизации вместо использования кода на стороне сервера

Ответ 1

Вы представили ложную дихотомию. Реальность такова, что, вероятно, никогда не будет ситуации, когда вместо серверного решения вы будете использовать Backbone's. Тем не менее, существует определенная тенденция к использованию клиентских маршрутизаторов в целом (не специально для Backbone's) для создания одностраничных приложений, например Ember.js. Вот ваши варианты:

Только серверные маршруты

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

Только клиентские маршруты

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

Гибридный подход

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

• Страница профиля пользователя с встроенным редактором. Маршрут может быть: /users/me#mode=edit, где /users/me - типичный маршрут, обслуживаемый сервером, а #mode=edit - это магистральный маршрут, который изменяет представление в режиме редактирования, где пользователь может редактировать информацию своего профиля.
• Календарь, который выделяет дату. Маршрут может быть: /calendars/work#date=today. Вот пример того, что вы просто не можете сделать с помощью серверного маршрута: выделите конкретную ячейку календаря (а именно today).

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

Ответ 2

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

• быстро, обычно вам нужно загрузить только одну часть страницы
• памятный, история хранится на странице, и вы можете контролировать то, что входит в историю, что не
• когда вы создаете клиентское приложение, хорошо иметь всю необходимую логику на стороне клиента, включая важный компонент, такой как диспетчер (маршрутизатор)
• легко сделать, реализация почти такая же, как на стороне сервера, вы указываете маршруты и обработчики, а затем ссылки в привязке href attr.

случай исключения

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

только мои 2-центов

Изменить: удалить "в качестве серверной стороны" в незабываемой строке.

Ответ 3

Это полностью вопрос предпочтения. Это в основном другая версия запроса, когда нужно выполнить запрос AJAX, а не полный запрос. Вы можете использовать Backbone полностью для маршрутизации с помощью одностраничного приложения, а затем просто иметь back-end представление чистого представления модели через API. Это было бы особенно полезно, если бы вы использовали решение HTML5 → Mobile. Я бы рекомендовал более умеренный подход для начала, в зависимости от набора навыков от вас и ваших коллег.

Лучшим первым шагом будет, как правило, использовать что-то вроде маршрутизатора Backbone для представления адресных изменений состояния переднего конца, которые выровнены с основной целью приложения. Если передняя часть делает такие вещи, как отображение подробного представления, созданного с помощью запроса AJAX, вместо этого реализовать его через обработчик событий, прикрепленный к некоторому элементу пользовательского интерфейса, вы должны реализовать его с использованием сегмента хеширования и маршрутизации на передней панели, который пользовательский интерфейс ссылки на элементы. Так, например, элемент пользовательского интерфейса будет просто ссылкой на нечто вроде /#/item/45, а затем маршрутизатор подберет это и запустит обработчик, прикрепленный к шаблону, например /#/item/{itemId}. Это лучше отражает состояние и открывает дверь для использования истории браузера и создания ссылок, которые используют существующий код внешнего интерфейса в чистом виде.

После этого вы можете использовать маршрутизаторы по мере необходимости.

Ответ 4

Почему я буду использовать его:

• Чистый код приложения UI. Централизованный подход к проблемам. Это играет большую роль для сложных приложений пользовательского интерфейса.

Следующие два элемента несколько связаны с маршрутизацией на стороне клиента (не напрямую):

• Запросы Ajax не обязательно должны возвращать всю страницу (хотя все равно).
• Запросы Ajax могут использовать компактный формат данных (например, JSON), который делает обработку запросов еще быстрее.

Почему я бы не использовал его:

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

Вывод:

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

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

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

например. блоги, общедоступные сайты, wiki-страницы и т.д.

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

Ответ 5

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

Вам все равно нужно выполнять маршрутизацию на стороне сервера. Из документов Backbone:

Например, если у вас есть маршрут /documents/ 100, ваш веб-сервер должен иметь возможность обслуживать эту страницу, если браузер посещает этот URL-адрес непосредственно.

Ответ 6

Вы будете выполнять маршрутизацию на сервере и на стороне клиента.

Запросы от вашего клиента на сервер по-прежнему должны быть перенаправлены на сервер. С точки зрения сервера, маршрутизация по-прежнему выполняется для запросов Ajax.

Маршрутизатор на стороне клиента используется для маршрутизации #links в ваше базовое приложение. Поэтому, когда кто-то нажимает на ссылку #, ваш маршрутизатор выберет это и сделает это, скорее всего, запустит соответствующее событие.

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