Какой из них лучше pushstate или location.hash?

window.location.hash и HTML5 history.pushstate . Какой из них лучше встретить URL-адрес с запросом ajax и почему? Благодарю.

location.hash имеет лучшую поддержку, чем метод history.pushState .
Преимущество метода pushState заключается в том, что вы можете привязать состояние к записи истории.
Если вам не нужен этот объект состояния, я рекомендую использовать свойство location.hash для лучшей совместимости со старыми браузерами.

 location.hash = 'new-hash'; console.log(history.state); // null or undefined history.pushState({extraData: "some state info"}, '', 'new-hash'); //<--- console.log(history.state); // [object Object] = {"extraData": "some state info"} 

Pushstate – это будущее. Это лучше, потому что:

  1. Он выглядит чище.
  2. При переходе к глубокой ссылке вы можете фактически наглядно представить реальные серверные данные для поддержки таких вещей, как SEO и Facebook Open Graph (оба посылают пауки, чтобы очистить html вашей страницы).
  3. Серверы не имеют доступа к данным hash-тегов, поэтому вы не видите их в своих журналах сервера, поэтому это помогает некоторым аналитикам.
  4. Это помогает исправить проблемы с hash-тегами. Например, у меня была перезапись Nginx, чтобы перенаправить пользователей, посещающих мое приложение, на тот же https-url. Он работает во всех браузерах, но Safari, который перенаправит вас только на домен без hashа (так раздражает)!
  5. Фактически вы можете использовать hash-тег для того, что предназначено для глубокой ссылки на разделы длинных страниц.
  6. Вы можете отказаться от использования реальных HTTP-запросов на бэкэнд для браузера, которые не поддерживают push state, или вы можете отказаться от использования hash-тега. Оба требуют дополнительной реализации, но легко справляются с небольшой работой.

См. Этот разговор от дизайнера Github для получения дополнительной информации: http://warpspire.com/talks/responsive/

history.pushState лучше, чем location.hash . но это функция HTML5. поэтому всегда лучше иметь метод возврата, как показано ниже.

 if (typeof(window.history.pushState) == 'function') { window.history.pushState(null, path, path); } else { window.location.hash = '#!' + path; } 

Я согласен с другими ответами, но вот несколько аргументов в пользу location.hash :

  • он работает в каждом браузере, включая Internet Exploder TM
  • history.pushState – это развивающийся стандарт, и API может измениться в будущем
  • если пользователи открывают ссылку в новом окне / вкладке, хеш-URL-адрес гарантирует, что для загрузки страницы не требуется запрос сервера (если установлены правильные заголовки кеширования)
  • Конфигурация сервера проста, так как весь сервер когда-либо видит URL без hash-части

: Я забыл один

  • с hashtags, вы можете использовать реальные ссылки ( a href ). Таким образом, вам не нужно настраивать прослушиватели кликов, что повышает производительность и уменьшает размер кода.

Преимущества / недостатки window.location.hash vs HTML5 history.pushstate в значительной степени определяются тем, как именно вы хотите, чтобы ваша страница ухудшалась.

Здесь вы можете быть заинтересованы в изящной деgradleации в двух разных сценариях:

Первый из них – клиент, который не поддерживает javascript, или автоматический бот / искатель, посещающий ваш сайт. Это особенно важно с точки зрения SEO. Если ваша веб-страница / веб-приложение использует хеш-URL, то контент, ansible через эти ссылки, не доступен этим конечным пользователям. Это определенно проблема, если вы делаете разделы контента доступными только через hash-URL без резервов. Однако это определенно не проблема, если вы используете ссылки hash-tag для изменения состояния приложения, которое просто не сохраняет значение, если страница ухудшается.

В качестве примера рассмотрим сценарий, в котором у вас есть страница с тремя разделами текста, доступная на трех вкладках в виджетах с вкладками. Теперь возможны два сценария: во-первых, вы загружаете весь контент во время загрузки страницы, а виджет с вкладками будет просто скрывать другие разделы и показывать определенный раздел. Поэтому, если вы используете хеш-ссылки в ссылках, которые вы используете для создания вкладок, вы используете их только для изменения состояния приложения на стороне клиента. Когда javascript отключен / недоступен, просто javascript, используемый для построения макета с вкладками, не запускается, и весь контент сразу доступен – разумный изящный откат. Различные состояния приложения просто не существуют в этом случае, и поэтому hash-URL-адреса ухудшаются до того, чтобы указывать на якоря в html – цель. Вместо hash-ссылок, если бы вы использовали html5 pushstate в этом случае, это была бы плохая идея. Причина, по которой пользователь может добавить ссылку на конкретную вкладку. Поскольку ваш сервер должен будет взять этот URL-адрес и представить пользователю состояние клиентской стороны, которое он ожидает. Это плохо для архитектуры тонкого сервера, где клиентская сторона должна заботиться о своем собственном управлении государством. Вы можете игнорировать этот аспект на стороне сервера и позволить клиенту проверить URL-адрес в начале загрузки страницы, а затем переключиться в соответствующее состояние приложения. Но все же это не очень хорошая идея, потому что ваша система маршрутизации на стороне сервера связана с накладными расходами дополнительных fragmentов URL-адресов, которые она должна игнорировать, где это не должно беспокоить этот fragment вообще с эстетической точки зрения. Это точно соответствует требованию, для которого были разработаны hash-URL, и настоятельно рекомендуется использовать их. Если вместо этого в трех разделах текст загружается динамически, когда нажимается конкретный большой палец вкладки, то использование хеш-ссылок не является хорошей идеей. Причина, по которой пользователь будет просто не иметь доступа к связанному контенту, если javascript недоступен. Это особенно плохо для SEO. В этом случае, если вы обрабатываете URL-адреса (которые в обычном сценарии будут «захвачены» и «ааксифицированы») на стороне сервера, чтобы сделать контент доступным в целом, он отлично подходит как с точки зрения опыта конечных пользователей, так и с помощью SEO.

Второй сценарий – это клиент, у которого есть устаревший браузер, который не поддерживает pushstates html5. В то время как вышеупомянутые пункты все еще сохраняются, кроме того, я бы также утверждал, что принуждение пользователей без какой-либо pushstate с тем же уровнем деgradleации, что и не-javascript не является оправданным. Многие конечные пользователи просто не знают, почему они получают ухудшенную версию.

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

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

Вы можете использовать history.pushState с hash-возвратом, используя polyfill history.js, если вы хотите использовать pushState, но не хотите иметь проблемы со старой поддержкой браузера.

В настоящее время pushState поддерживается всеми современными браузерами. Поэтому pushState лучше, чем location.hash , но это функция HTML5.

Итак, location.hash не мертв, на самом деле это будет длиться долго, долго.

Хороший способ использовать это с lib, который поддерживает pushState , но также изящно ухудшает использование location.hash .
Пример: https://github.com/browserstate/history.js

Кроме того, location.hash все равно будет полезен для перехода к названным якорям. pushState будет огромной помощью в создании веб-приложений. Я с нетерпением жду его использования.

Это довольно старый вопрос (5 ​​лет + во время этого ответа), но многие комментарии к существующим ответам требуют обновления, основанного на «текущем» состоянии вещей.

Вот сделка:

Функция pushState HTML5 поддерживается во всех основных браузерах. Если вы также поддерживаете старые браузеры, history.js предоставляет отличный полиполк, который позволяет использовать pushState изначально и легко откидываться на устаревшие URL-адреса для старых браузеров. Теперь, когда pushState поддерживается на самом деле, это не означает, что это окончательно путь.

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

PushState красивее и чище и может использоваться для полной подделки навигации на вашем сайте / в вашем приложении. Например, GitHub использует его для незаметной замены всей навигации. Когда вы нажимаете любую ссылку на своем сайте, javascript используется для перехвата этого клика и превращения его в запрос AJAX, который обновляет содержимое страницы без загрузки новой страницы, в то время как URL-адрес на панели местоположений изменяется в соответствии с содержимым, которое было неправдоподобным. Это то, на что нужно было использовать pushState .

В случае GitHub используются оба URL-адреса http: // mysite / page1 и http: // mysite / page2 . Они являются «реальными» ссылками с «реальным» контентом, и изначально посещение любой страницы проходит через традиционный подход MVC. GitHub использует pushState для навигации в современных браузерах, но не требует его – т.е. pushState используется как «функция добавления» (по их мнению), приводит к лучшему опыту пользователя, когда дело касается навигации. Когда вы копируете ссылку в адресной строке браузера, вы копируете ссылку, которая была сформирована с помощью javascript и pushState, но ссылка, которая тем не менее действительна и действительна.

Однако, если вы начинаете с нуля и создаете одностраничное приложение и не используете структуру MVC, скорее всего, у вас на самом деле есть только одна страница, особенно если вы не используете динамический бэкэнд (т. Е. Контент извлекается через javascript , никогда не генерируемый сервером). В этом случае, если вы используете pushState над hash-адресами, вам нужно будет обработать случай, когда URL-адрес в браузере не является реальным URL-адресом. Я проиллюстрирую.

Пользователь загружает одностраничное приложение: http: // mysite / mainpage

На этом этапе панель браузера содержит реальную ссылку на ваше приложение и отобразит пользователя в том же виде, что и в настоящее время: главная страница. Теперь они нажимают ссылку, которая приведет их на «страницу», где будут показаны детали какой-либо активности. На этом этапе вы хотите обновить строку местоположения, чтобы указать изменение состояния. Вы либо используете хеш-адрес, и ваша панель местоположений выглядит как http: // mysite / mainpage # charts / 1 или вы используете pushState и обманываете его, чтобы стать http: // mysite / mainpage / charts / 1

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

Вам нужно будет перенаправить запросы на / mainpage / charts / 1 to / mainpage, а затем использовать JS для разрешения фактического URL-адреса и выполнить запланированную операцию изменения состояния. Требуется redirect сервера. Вы не можете размещать эту страницу на AWS или на своем локальном диске без скриптового HTTP-сервера.

Теперь, если вы использовали хеш-URL-адреса, ваш URL-адрес, с которым пользователь мог бы видеть и взаимодействовать, был бы http: // mysite / mainpage # / charts / 1, и это действительный реальный URL-адрес . Браузеры понимают, что существует только одна страница, и будет ли пользователь копировать и вставлять ссылку или закладки, вам просто нужно обработать hash-состояние в javascript и не нуждаться в какой-либо серверной магии, чтобы заставить все работать.

То, о чем никто не упоминает, это то, что pushState и hash-ссылки не являются взаимоисключающими . pushState – это просто API для управления местоположением браузера, который является видимым для пользователя и реализует надежную навигацию в режиме « назад / вперед» в современных браузерах. Он ничего не говорит о том, как должна выглядеть ваша схема URL.

В 2017 году Google и практически каждый другой бот JS-совместимый понимают URL-адреса hashа и отлично проходят их. Google хочет, чтобы вы использовали #! мерзости для целей максимизации SEO, но даже если вы этого не сделаете, ваш сайт будет судоходным просто отлично.

Правильный ответ – использовать все, что лучше всего подходит вашим потребностям. Если у вас есть реальные URL-адреса и вы хотите подделать навигацию между ними, используйте pushState и продолжайте (возможно, с полиполнением для старых браузеров). Но если у вас одностраничное приложение, не притворяйтесь, что не хотите (если у вас нет веской причины). Используйте URL-адреса hashа, чтобы упростить вашу жизнь и не вводить ненужные проблемы, а затем использовать pushState для управления этими hash-URL-адресами, чтобы использовать преимущества поддержки back / forward .

  • Когда я вводил адрес с https, Firefox (иногда) меняет его на http
  • Как заменить все пробелы на% 20 в C #?
  • Могу ли я использовать символ (@) внутри URL?
  • Как установить сервер по умолчанию для помощников URL-адресов в рельсах?
  • Доступ к URL-адресу и чтение данных с помощью R
  • Почему URL-адреса файлов начинаются с 3 косой черты?
  • Код для декодирования / кодирования измененного URL-адреса base64
  • Как сделать HTTP-запрос с помощью файлов cookie на Android?
  • ускорение амперсанда в URL-адресе
  • Можно ли создать ссылку на конкретное сообщение электронной почты в Outlook?
  • В чем разница между параметрами URL и строками запроса?
  • Давайте будем гением компьютера.