From 0ad4c1360f77b6db637417c1f97fa79239e29ecb Mon Sep 17 00:00:00 2001 From: Brian Cardarella Date: Mon, 5 Dec 2016 09:20:11 -0500 Subject: [PATCH 1/3] RFC: Track unique history location state --- ...000-track-unique-history-location-state.md | 93 +++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 text/0000-track-unique-history-location-state.md diff --git a/text/0000-track-unique-history-location-state.md b/text/0000-track-unique-history-location-state.md new file mode 100644 index 0000000000..4bdbd986aa --- /dev/null +++ b/text/0000-track-unique-history-location-state.md @@ -0,0 +1,93 @@ +- Start Date: 2016/12/05 +- RFC PR: (leave this empty) +- Ember Issue: (leave this empty) + +# Summary + +Track unique history location states + +# Motivation + +The path alone does not provide enough information. For example, if you +visit page A, scroll down, then click on a link to page B, then click on +a link back to page A. Your actual browser history stack is [A, B, A]. +Each of those nodes in the history should have their own unique scroll +position. In order to record this position we need an ID that is unique +for each node in the history. + +# Detailed design + +Code: [PR#14011](https://github.com/emberjs/ember.js/pull/14011) + +We simply add a `stateCounter` so we can track uniqueness on two +dimesions. Both `path` and the generated `id`. + +This API will allow other libraries to reflect upon each location to +determine unique state. For example, +[ember-router-scroll](https://github.com/dollarshaveclub/ember-router-scroll) +is making use of a [modified `Ember.HistoryLocation` object to get this +behavior](https://github.com/dollarshaveclub/ember-router-scroll/blob/master/addon/locations/router-scroll.js). + +Tracking unique state is required when setting the scroll position +properly based upon where you are in the history stack, as described in +[Motivation](#motivation) + +# How We Teach This + +We could describe what meta data is generated for each location in the +history stack. For example, it could look like: + +```js +// visit page A + +[ + { path: '/', id: 1 } +] + +// visit page B + +[ + { path: '/about', id: 2 }, + { path: '/', id: 1 } +] + +// visit page A + +[ + { path: '/', id: 3 }, + { path: '/about', id: 2 }, + { path: '/', id: 1 } +] + +// click back button + +[ + { path: '/about', id: 2 }, + { path: '/', id: 1 } +] +``` + +# Drawbacks + +None that I'm aware of + +# Alternatives + +The purpose for this behavior is to enable scroll position libraries. +There are two other solutions in the wild. One is in the guides that +suggests resetting the scroll position to `(0, 0)` on each new route +entry. The other is +[ember-memory-scroll](https://github.com/ef4/memory-scroll) which I +believe is better suited for tracking scroll positions for components +rather than the current page. + +However, in both cases neither solution provides the experience that +users have come to expect from server-rendered pages. The browser tracks +scroll position and restores it when you revisit the page in the history +stack. The scroll position is unique even if you have multiple instances +of the same page in the stack. + +# Unresolved questions + +Is this public API? If so, would this be considered additive or +breaking? From c1fb4ccb701f2e20a447bc913beee5439f2341fe Mon Sep 17 00:00:00 2001 From: Brian Cardarella Date: Sun, 11 Dec 2016 07:21:24 -0500 Subject: [PATCH 2/3] Updated from feedback --- ...000-track-unique-history-location-state.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/text/0000-track-unique-history-location-state.md b/text/0000-track-unique-history-location-state.md index 4bdbd986aa..a2e85a906a 100644 --- a/text/0000-track-unique-history-location-state.md +++ b/text/0000-track-unique-history-location-state.md @@ -15,13 +15,6 @@ Each of those nodes in the history should have their own unique scroll position. In order to record this position we need an ID that is unique for each node in the history. -# Detailed design - -Code: [PR#14011](https://github.com/emberjs/ember.js/pull/14011) - -We simply add a `stateCounter` so we can track uniqueness on two -dimesions. Both `path` and the generated `id`. - This API will allow other libraries to reflect upon each location to determine unique state. For example, [ember-router-scroll](https://github.com/dollarshaveclub/ember-router-scroll) @@ -32,6 +25,13 @@ Tracking unique state is required when setting the scroll position properly based upon where you are in the history stack, as described in [Motivation](#motivation) +# Detailed design + +Code: [PR#14011](https://github.com/emberjs/ember.js/pull/14011) + +We simply add a `stateCounter` so we can track uniqueness on two +dimensions. Both `path` and the generated `id`. + # How We Teach This We could describe what meta data is generated for each location in the @@ -69,7 +69,7 @@ history stack. For example, it could look like: # Drawbacks -None that I'm aware of +* The property access is writable # Alternatives @@ -89,5 +89,4 @@ of the same page in the stack. # Unresolved questions -Is this public API? If so, would this be considered additive or -breaking? +None at this time. From 455ff5f1d4bf7a97317d8676658c5ccf0074b39a Mon Sep 17 00:00:00 2001 From: Brian Cardarella Date: Mon, 16 Jan 2017 20:55:07 -0500 Subject: [PATCH 3/3] Change from counter to uuid per Stef's request --- ...000-track-unique-history-location-state.md | 25 +++++++++++-------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/text/0000-track-unique-history-location-state.md b/text/0000-track-unique-history-location-state.md index a2e85a906a..8bbfbefb2e 100644 --- a/text/0000-track-unique-history-location-state.md +++ b/text/0000-track-unique-history-location-state.md @@ -12,7 +12,7 @@ The path alone does not provide enough information. For example, if you visit page A, scroll down, then click on a link to page B, then click on a link back to page A. Your actual browser history stack is [A, B, A]. Each of those nodes in the history should have their own unique scroll -position. In order to record this position we need an ID that is unique +position. In order to record this position we need a UUID for each node in the history. This API will allow other libraries to reflect upon each location to @@ -29,8 +29,11 @@ properly based upon where you are in the history stack, as described in Code: [PR#14011](https://github.com/emberjs/ember.js/pull/14011) -We simply add a `stateCounter` so we can track uniqueness on two -dimensions. Both `path` and the generated `id`. +We simply unique identifier (UUID) so we can track uniqueness on two +dimensions. Both `path` and the generated `uuid`. A simple UUID +generator such as +https://gist.github.com/lukemelia/9daf074b1b2dfebc0bd87552d0f6a537 +should suffice. # How We Teach This @@ -41,29 +44,29 @@ history stack. For example, it could look like: // visit page A [ - { path: '/', id: 1 } + { path: '/', uuid: 1 } ] // visit page B [ - { path: '/about', id: 2 }, - { path: '/', id: 1 } + { path: '/about', uuid: 2 }, + { path: '/', uuid: 1 } ] // visit page A [ - { path: '/', id: 3 }, - { path: '/about', id: 2 }, - { path: '/', id: 1 } + { path: '/', uuid: 3 }, + { path: '/about', uuid: 2 }, + { path: '/', uuid: 1 } ] // click back button [ - { path: '/about', id: 2 }, - { path: '/', id: 1 } + { path: '/about', uuid: 2 }, + { path: '/', uuid: 1 } ] ```