Backbone: History.navigate는 상태 개체 설정을 허용해야 합니다.

동의하지 않을 수 있지만 그렇지 않은 경우에는 저를 설득해 보십시오.

History API의 요점은 다시 탐색할 수 있는 책갈피 및 공유 가능한 URL을 제공하는 것입니다. API를 사용하여 기록 개체를 첨부하면 다시 탐색하는 페이지가 동일한 URL에 붙여넣은 경우 표시되는 페이지와 _아니다_. 이것은 깨진 것 같습니다 ... 그리고 최소한 브라우저 세션 중에 JS에 임의의 상태를 저장할 수 있는 기능과 중복됩니다.

그것은 브라우저 구현자가 "이런, 할 수 있다면 깔끔하지 않을까요..."라고 생각하고 실제 결과를 고려하지 않은 API와 같은 냄새가 납니다.

나는 당신이 바람직한 앱 동작과 브라우저 API가 제공하는 것보다 더 제한적인 기록 이벤트의 세분성에 대해 가정하고 있다고 생각합니다. 특히 URI로 호출될 때 동작을 지시하는 앱이 아니라 프레임워크에 달려 있어야 할 이유가 없습니다. URI로 식별되는 리소스(및 인코딩된 상태)에 직교하는 상태(탐색 경로에 의해 제공됨)가 있고 프레젠테이션이 둘 모두에 대해 조건지어진 것이 완벽하고 명백하게 합법적인 것 같습니다. 분명히 그 선택은 개별 앱에 달려 있습니다.

그 추상적인 주장을 제외하고, 예를 들어 History API를 사용하여 (뒤로 버튼 포함) 탐색할 때 변경 사항을 저장/삭제하도록 제안하는 책갈피 가능한 입력 양식을 구현하는 방법을 알려주십시오.

이것은 한두 줄의 변경 사항입니다. History.navigate 매개변수를 추가하지 않으려면 currentState 속성이나 함수를 통해 주어진 상태를 사용하도록 만들 수도 있습니다.

예를 들어 책갈피 가능한 입력 양식을 구현하는 방법을 알려주십시오.
(
뒤로 버튼으로) History API를 사용하시겠습니까?

나는 단순히 양식 변경 사항을 다른 안전한 장소에 저장할 것입니다. 세션, 서버, localstorage...

사람들이 이 직책에 대해 어떻게 생각하는지 궁금해서 다음과 같이 질문했습니다.

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/basistance/status/142882410982420481

History API는 URI와 구별되는 탐색 경로에 연결된 앱 상태를 구체적으로 다룹니다. 즉 "우리가 여기 어떻게 왔어?" 아마도 Hysterisis API라고 불러야 할 것입니다. 우리는 동일한 URI를 공유하고 동일한 '페이지'에 있을 수 있지만 마우스의 뒤로 버튼을 누르거나 모바일에서 뒤로 스와이프할 때 동일한 반환 보기/페이지/상태가 아닐 수 있습니다. 그리고 그 뒤로 동작은 URI를 변경하지 않고 앱 상태/기록을 변경할 수 있습니다. 모든 탐색 전환이 URI 전환인 것은 아닙니다. 따라서 URI를 공유할 때 동일한 리소스 또는 '페이지'를 표시하지만 동일한 탐색 상태는 표시하지 않을 수 있습니다.

나는 당신의 무리의 경험에 감사하지만 대부분의 개발자가 제작자가 의도한 대로 API를 사용하는 방법을 아직 이해하지 못했다는 것을 보여주기 위한 것이라고 생각합니다. 그것은 프레임워크가 그것을 포장하는 좋은 이유가 아닙니다.

또한 양식 값을 유지하는 방법이 아니라 push/popState API를 사용하여 탐색하기 위해 뒤로 버튼을 눌렀을 때 변경 사항을 저장하라는 메시지를 사용자에게 표시하는 방법에 대한 질문을 다루지 않았습니다. 책갈피 가능한 URI가 있는 양식에서 멀리 떨어져 있습니다. 이에 대한 대처를 고려하시기 바랍니다.

나는 일반적으로 Backbone과 WebDev를 처음 접하지만 tribalvibes에 동의합니다.

Facebook의 Graph API를 기반으로 하는 웹 응용 프로그램을 만들고 Backbone의 탐색 기능을 사용하여 사용자가 다른 항목으로 돌아가 볼 수 있도록 하고 싶습니다. Facebook이 지금 하고 있는 것과 유사합니다. 그러나 pushState에 stateobject가 없으면 사용자는 API에서 항목을 다시 로드해야 하며 이는 분명히 비용이 많이 듭니다.

아마도 이 문제의 일반적인 패턴이 무엇인지 모르기 때문일 것입니다. 하지만 이에 대한 상태 개체가 있으면 매우 도움이 될 것이라고 생각합니다.

MDN 문서에 따라 상태 개체는 디스크에 저장됩니다. 로컬 저장소에 저장하는 것과 어떻게 다른지 이해가 되지 않습니다. 나는 이것이 다시 다루어져야 한다고 생각한다. 기록 API에서 상태 개체를 사용할 수 있는 경우 로컬 저장소 또는 다른 상태 저장 방법을 사용하는 것은 관련이 없어 보입니다.

맞습니다. 하지만 반대입니다. 로컬 저장소, 쿠키 또는 단순히 현재 URL에 연결되지 _아닌_ 상태를 저장하는 다른 방법이 있는 경우 상태 개체를 사용하는 것은 관련이 없습니다.

제공된 도구를 활용하는 것이 더 좋지 않은 이유는 무엇입니까? 상태 개체는 이전 상태를 저장하고 액세스하는 직접적인 방법을 제공합니다. 사용자가 페이지에 도착할 때마다 로컬 저장소를 탐색하는 대신 history.state를 사용할 수 있으면 URL 경로를 통해 보기의 일반 상태뿐만 아니라 사용자가 로 돌아가고 싶을 수도 있습니다.

제 생각에는 라우트를 사용하는 간단한 앱은 라우트를 간단하게 사용해야 합니다. 전체 경험을 위해 URL을 복사하여 붙여넣습니다. 복잡한 앱은 경로를 애플리케이션의 일반 영역 또는 특정 레코드에 대한 단순한 진입점으로만 사용해야 하며, 사용자(서버), 세션 또는 로컬이든 간에 지속성 유형을 더 잘 나타내는 스토리지 API를 사용해야 합니다.

기록 상태 개체를 사용하면 단일 페이지 앱이 URL을 잠재적으로 영구적인 책갈피로 사용할 수 있는 간단한 방법의 장점을 무효화합니다.

백본은 항상 다른 프레임워크보다 매우 유연하고 덜 독단적이었습니다. 이것이 기본 window.history.pushState와 다른 이유를 이해할 수 없습니다. 어떤 사람들은 그것을 좋아하지 않는다는 것을 이해합니다. 그러나 사용 여부는 최종 사용자에게 맡겨야 합니다.

그러니 다시 생각해 보십시오.

@rafayepes 나는 당신의 주장에 전적으로 동의합니다. 저는 Backbone과 그 단순성을 좋아하지만 이 API 변경으로 인해 앱이 URL과 상태 간의 1:1 관계를 저장해야 할 때 코드에 많은 문제와 해결 방법이 도입되었습니다. History API와 상호 작용하는 기본 방법은 훨씬 더 쉬울 것입니다.