У Google есть много живых экспериментальных функций, которые включаются/выключаются в зависимости от ваших предпочтений, местоположения и других факторов (вероятно, случайного выбора).
Что происходит в фоновом режиме, когда хэш используется вместо параметра строки запроса, так это то, что он запрашивает реальный URL-адрес (http://www.google.com/search?q=hello) с помощью JavaScript, затем он изменяет существующую страницу с содержанием. Это будет выглядеть гораздо более отзывчивым для пользователя, поскольку страница не должна полностью перезагружаться. Причина хеша в том, что история и состояние браузера сохраняются. Если вы перейдете на страницу http://www.google.com/#q=hello, вы обнаружите, что вы на самом деле получаете результаты поиска для приветствия (даже если ваш браузер действительно запрашивает только http://www.google.com/) Однако с отключенным JavaScript он не будет работать, и вы просто получите главную страницу Google.
Хэши появляются все чаще и чаще, поскольку динамические веб-сайты становятся нормой. Хэши полностью хранятся на клиенте и, следовательно, не требуют запроса к серверу при изменении. Это делает их отличными кандидатами для поддержки уникальных адресов для разных состояний веб-приложения, оставаясь при этом на одной и той же странице.
В последнее время я сам использую их все больше и больше, и вы можете найти один пример здесь: http://blixt.org/js -- Если вы взглянете на библиотеку хэшей на этой странице, вы увидите мою реализацию поддержки хэшей в разных браузерах.
Вот небольшое руководство по использованию хэшей для хранения состояния:
Как?
Сохранение состояния в хэшах подразумевает, что ваше приложение (я буду называть его приложением, поскольку вы обычно используете хэши для состояния только в более продвинутых веб-решениях) зависит от JavaScript. Без JavaScript единственной функцией хэшей было бы указание браузеру найти контент где-то на странице.
После того, как вы реализовали некоторый JavaScript для обнаружения изменений в хэше, следующим шагом будет разбор хэша на значимые данные (так же, как вы делаете это с параметрами строки запроса).
Почему?
Как только вы получите состояние в хеше, его можно изменить с помощью вашего кода (или вашего пользователя), чтобы представить текущее состояние в вашем приложении. Есть много причин, почему вы хотели бы сделать это.
Одним из распространенных случаев является то, что только небольшая часть страницы изменяется на основе переменной, и было бы неэффективно перезагружать всю страницу, чтобы отразить это изменение (пример: у вас есть поле с вкладками. Активная вкладка может быть идентифицирована в хеше.)
В других случаях вы загружаете контент динамически в JavaScript и хотите сообщить клиенту, какой контент загружать (пример: http://beta.multifarce.com/#?state=7001 приведет вас к определенному моменту текстового приключения.)
Когда?
Если вы заглянули в мою сферу JavaScript, вы увидите крайний случай перебора. Я сделал это просто потому, что хотел втиснуть на эту страницу как можно больше динамики JavaScript. В обычном проекте я был бы консервативен в отношении того, когда это делать, и делал бы это только тогда, когда вы увидите положительные изменения в одной или нескольких из следующих областей:
- User interactivity
- Usually the user won't see much difference, but the URLs can be confusing
- Помните индикаторы загрузки! Динамическая загрузка контента может разочаровать пользователя, если на это требуется время.
- Отзывчивость (время перехода из одного состояния в другое)
- Производительность (пропускная способность, ЦП сервера)
Нет JavaScript?
Здесь приходит большой сдерживающий фактор. Хотя вы можете смело полагаться на то, что у 99% ваших пользователей есть браузер, способный использовать вашу страницу с хешами для состояния, во многих случаях вы просто не можете полагаться на это. Поисковые роботы, например. Хотя Google постоянно работает над тем, чтобы их поисковый робот работал с новейшими веб-технологиями (вы знали, что они индексируют Flash-приложения?), он все еще не человек и не может понять некоторые вещи.
По сути, вы находитесь на перекрестке между совместимостью и пользовательским опытом.
Но вы всегда можете построить дорогу между ними, что, конечно, требует больше работы. В менее метафорических терминах: Реализуйте оба решения, чтобы для каждого URL-адреса на стороне клиента существовал URL-адрес на стороне сервера, который выводит соответствующий контент. Для совместимых клиентов он будет перенаправлять их на URL-адрес хеша. Таким образом, Google может индексировать жесткие URL-адреса, и когда пользователи нажимают на них, они получают информацию о динамическом состоянии!
person
Blixt
schedule
20.08.2009
