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

Question

window.location.hash против HTML5 history.pushstate.Какой из них был бы лучше для удовлетворения URL с запросом Ajax и почему?Спасибо.

Answer 1

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"}

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

edit: я забыл один

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

Answer 5

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

Здесь вас может заинтересовать постепенная деградация в двух разных сценариях:

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

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

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

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

Answer 6

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

Вот сделка:

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

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

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

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

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

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

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

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

Вам нужно будет перенаправить запросы на / mainpage / charts / 1 на / mainpage, а затем использовать JS для разрешения фактического URL-адреса и выполнения предполагаемой операции изменения состояния. Перенаправление сервера абсолютно необходимо. Эту страницу нельзя разместить на AWS или на локальном диске без http-сервера с поддержкой сценариев.

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

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

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

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

Answer 7

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

Таким образом, location.hash не мертва, фактически она будет существовать очень долго.

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

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

Answer 8

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

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