Backbone: History.navigate должен разрешать установку объекта состояния

Боюсь, что я не согласен, но, пожалуйста, убедите меня в обратном.

Задача History API - предоставить доступные для закладки URL-адреса, к которым вы можете вернуться. Если вы присоедините объект истории к API, страница, на которую вы перейдете обратно, _ не_ будет такой же, как страница, которую вы бы увидели, если бы вставили идентичный URL-адрес. Это кажется сломанным ... и, по крайней мере, избыточным с вашей способностью сохранять произвольное состояние в JS во время сеанса браузера.

Это пахнет API, в котором разработчики браузеров подумали: «Ну что ж, было бы здорово, если бы вы могли ...», и не учли реальных последствий.

Я думаю, вы делаете предположения о желаемом поведении приложения, а также о детализации событий истории, которые являются более строгими, чем то, что предоставляет API браузера. В частности, нет причин, по которым структура, а не приложение должно диктовать поведение при вызове с URI. Кажется совершенно и очевидным правомерным, что существует состояние (заданное путем навигации), которое ортогонально ресурсу (и закодированному состоянию), идентифицированному URI, и что представление обусловлено обоими. Очевидно, что этот выбор должен зависеть от конкретного приложения.

Помимо этого абстрактного аргумента, скажите мне, как бы вы реализовали, например, форму ввода с закладками, которая предлагает сохранять / отменять изменения при переходе от (в том числе с помощью кнопки возврата) с помощью History API?

Это изменение на одну или две строки. Если вы не хотите добавлять параметр в History.navigate можно также использовать состояние, указанное, например, с помощью атрибута или функции currentState .

скажите мне, как бы вы реализовали, например, форму записи с закладками
который предлагает сохранить / отменить изменения при переходе от (включая
с помощью кнопки возврата) с помощью History API?

Я бы просто сохранил изменения формы в другом и более безопасном месте: в сеансе, на сервере, в локальном хранилище ...

Мне было любопытно, что люди думают об этой должности, поэтому я спросил:

https://twitter.com/jashkenas/status/142736117895151616

И вот несколько ответов:

https://twitter.com/juandopazo/status/142737949178601472

https://twitter.com/yaypie/status/142737982879842304

https://twitter.com/fortes/status/142742305877659648

https://twitter.com/dyakovlev/status/142743995020349441

https://twitter.com/bassistance/status/142882410982420481

History API имеет дело конкретно с состоянием приложения, привязанным к пути навигации, отличному от URI. Т.е. "Как мы сюда попали?" Может быть, это следует назвать Hysterisis API. Мы можем использовать один и тот же URI и находиться на одной и той же «странице», но не в одном и том же отображении / странице / состоянии возврата, когда я нажимаю кнопку «Назад» на мыши или смахиваю назад на вашем мобильном телефоне. И это обратное действие может изменить состояние / историю приложения без изменения URI. Не все переходы навигации являются переходами URI. Поэтому, когда мы делимся URI, это может привести к представлению одного и того же ресурса или «страницы», но не одного и того же состояния навигации.

Хотя я ценю опыт вашей группы, я думаю, это просто показывает, что большинство разработчиков еще не выяснили, как использовать API, как задумано создателями. Это не повод для того, чтобы фреймворк заморачивался.

Кроме того, вы не ответили на вопрос, который заключался не в том, как сохранить значения формы, а в том, как использовать API push / popState, чтобы предложить пользователю сохранить изменения, если таковые имеются, когда они нажимают кнопку «Назад» для перехода к навигации. вдали от формы с помощью URI, добавляемого в закладки. Пожалуйста, подумайте над решением этой проблемы.

Я новичок в Backbone и WebDev в целом, однако я согласен с tribalvibes.

Я хочу создать веб-приложение на основе Facebook Graph API и использовать функцию навигации Backbone, чтобы позволить пользователю возвращаться к различным элементам для просмотра, аналогично тому, что Facebook делает прямо сейчас. Однако без объекта состояния в pushState пользователь должен перезагрузить элемент из API, что, очевидно, требует больших затрат.

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

Согласно документации MDN, объект состояния сохраняется на диск. Я не понимаю, чем это отличается от сохранения в локальное хранилище. Я считаю, что это следует переадресовать. Использование локального хранилища или другого метода сохранения состояния кажется лишним, если у вас есть объект состояния, доступный вам в api истории.

Верно, но против: использование объекта состояния должно быть лишним, если у вас есть локальное хранилище, файлы cookie или любой другой метод сохранения состояния, который _не_ просто привязан к текущему URL-адресу.

Почему не было бы лучше использовать предоставленный инструмент? Объект состояния обеспечивает простой метод сохранения и доступа к предыдущим состояниям. Вместо того, чтобы просеивать локальное хранилище каждый раз, когда пользователь попадает на страницу, наличие history.state позволило бы вспомнить не только общее состояние представления через URL-адрес, но и конкретное состояние этого представления, которое пользователь может захотеть вернуться к.

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

Использование объекта состояния истории лишает нас преимуществ того простого способа, которым одностраничные приложения могут использовать URL-адреса в качестве потенциально постоянных закладок.

Backbone всегда был очень гибким и менее самоуверенным, чем другие фреймворки. Я не понимаю, почему это отличается от собственного window.history.pushState. Я понимаю, что некоторым это не понравится. Однако решение использовать его или нет должно быть оставлено за конечным пользователем.

Так что, пожалуйста, подумайте над этим.

@rafayepes Я полностью согласен с вашим аргументом. Мне нравится Backbone и его простота, но это изменение API привносит в код кучу проблем и обходных путей, когда приложение должно сохранять отношение 1 к 1 между URL-адресом и состоянием. Нативный способ взаимодействия с History API был бы намного проще.