Хоча номер 2 може бути "простішим" для вас як розробника, він забезпечує лише сканування пошукової системи. І так, якщо Google дізнається, що ви пропонуєте інший вміст, ви можете бути покарані (я не експерт з цього питання, але я чув, що це відбувається).
Як SEO, так і доступність (не тільки для людей з обмеженими можливостями, але й доступність через мобільні пристрої, пристрої з сенсорним екраном та інші нестандартні платформи для обчислень / Інтернету) обидва мають схожу основу філософії: семантично багата розмітка, яка є "доступною" (тобто може отримати доступ, переглядати, читати, обробляти або використовувати іншим чином) до всіх цих різних браузерів. Зчитувач екрана, сканер пошукової системи або користувач з увімкненим JavaScript, повинні без проблем використовувати / індексувати / розуміти основну функціональність вашого сайту.
pushState
не додає цього тягаря, на мій досвід. Це лише виводить те, що раніше було задумливим, і "якщо у нас буде час" на перший план у веб-розробці.
Те, що ви описуєте у варіанті №1, як правило, найкращий шлях - але, як і інші проблеми з доступністю та SEO, виконання цього завдання pushState
у важкому додатку JavaScript вимагає попереднього планування, або це стане значним тягарем. Це має бути зафіксовано на сторінці та архітектурі додатків із самого початку - оновлення болісне і призведе до більше дублювання, ніж потрібно.
pushState
Нещодавно я працював із SEO і працював над декількома різними програмами, і я виявив, що, на мою думку, хороший підхід. Це в основному відповідає вашому пункту №1, але не враховує дублювання html / шаблонів.
Більшість інформації можна знайти в цих двох публікаціях блогу:
http://lostechies.com/derickbailey/2011/09/06/test-driving-backbone-views-with-jquery-templates-the-jasmine-gem-and-jasmine-jquery/
і
http://lostechies.com/derickbailey/2011/06/22/rendering-a-rails-partial-as-a-jquery-template/
Суть у тому, що я використовую шаблони ERB або HAML (запуск Ruby on Rails, Sinatra тощо) для візуалізації на стороні сервера та для створення шаблонів на стороні клієнта, якими може користуватися Backbone, а також для моїх специфікацій Jasmine JavaScript. Це виключає дублювання розмітки між стороною сервера та клієнтом.
Звідти вам потрібно зробити кілька додаткових кроків, щоб ваш JavaScript працював з HTML, який надає сервер - справжнє прогресивне вдосконалення; прийняття отриманої смислової розмітки та покращення її за допомогою JavaScript.
Наприклад, я будую додаток із галереї зображень із pushState
. Якщо ви запитаєте /images/1
від сервера, він візуалізує всю галерею зображень на сервері та надішле весь HTML, CSS та JavaScript до вашого браузера. Якщо у вас відключений JavaScript, він буде працювати чудово. Кожна дія, яку ви зробите, вимагатиме отримання різної URL-адреси від сервера, і сервер відображатиме всю розмітку для вашого браузера. Якщо у вас увімкнено JavaScript, JavaScript підбере вже відредагований HTML разом із кількома змінними, згенерованими сервером, і перейме звідти.
Ось приклад:
<form id="foo">
Name: <input id="name"><button id="say">Say My Name!</button>
</form>
Після того, як сервер надає це, JavaScript підбере його (використовуючи перегляд Backbone.js у цьому прикладі)
FooView = Backbone.View.extend({
events: {
"change #name": "setName",
"click #say": "sayName"
},
setName: function(e){
var name = $(e.currentTarget).val();
this.model.set({name: name});
},
sayName: function(e){
e.preventDefault();
var name = this.model.get("name");
alert("Hello " + name);
},
render: function(){
// do some rendering here, for when this is just running JavaScript
}
});
$(function(){
var model = new MyModel();
var view = new FooView({
model: model,
el: $("#foo")
});
});
Це дуже простий приклад, але я думаю, що це зрозуміло.
Коли я створюю подання після завантаження сторінки, я надаю існуючий вміст форми, наданої сервером, екземпляру перегляду як el
перегляду. Я не викликаю візуалізацію або перегляд, який створює el
для мене, коли завантажується перший погляд. У мене доступний метод візуалізації після запуску перегляду, і ця сторінка - це JavaScript. Це дозволяє мені переглядати подання пізніше, якщо мені потрібно.
Якщо натиснути кнопку "Скажи моє ім'я" з увімкненим JavaScript, це призведе до вікна сповіщення. Без JavaScript він буде розміщений назад на сервері, і сервер міг би десь надати ім'я елементу html.
Редагувати
Розглянемо більш складний приклад, де у вас є список, який потрібно долучити (з коментарів нижче цього)
Скажімо, у вас є список користувачів у <ul>
тезі. Цей список був наданий сервером, коли браузер зробив запит, і результат виглядає приблизно так:
<ul id="user-list">
<li data-id="1">Bob
<li data-id="2">Mary
<li data-id="3">Frank
<li data-id="4">Jane
</ul>
Тепер вам потрібно переглядати цей список і приєднати перегляд та модель опорних кісток до кожного з <li>
елементів. За допомогою data-id
атрибута ви можете легко знайти модель, з якої походить кожен тег. Тоді вам знадобиться представлення колекції та вигляд предмета, який є досить розумним, щоб приєднатися до цього html.
UserListView = Backbone.View.extend({
attach: function(){
this.el = $("#user-list");
this.$("li").each(function(index){
var userEl = $(this);
var id = userEl.attr("data-id");
var user = this.collection.get(id);
new UserView({
model: user,
el: userEl
});
});
}
});
UserView = Backbone.View.extend({
initialize: function(){
this.model.bind("change:name", this.updateName, this);
},
updateName: function(model, val){
this.el.text(val);
}
});
var userData = {...};
var userList = new UserCollection(userData);
var userListView = new UserListView({collection: userList});
userListView.attach();
У цьому прикладі UserListView
буде проведено перегляд всіх <li>
тегів та додавання об’єкта перегляду з правильною моделлю для кожного. він встановлює обробник подій для події зміни імені моделі та оновлює відображений текст елемента, коли відбувається зміна.
Такий процес - взяти html, який надає сервер, і запустити мій JavaScript, і запустити його - це чудовий спосіб отримати зручні речі для SEO, Доступності та pushState
підтримки.
Сподіваюся, що це допомагає.