[whatwg] history state object api issues

[Justin Lebar]

> - allow for self-contained components to handle own state
>  [not supported by spec, *2]

I'm generally in favor of a minimalistic approach to this kind of
thing.  Ideally, we'd be able to compose independent components using
the API, but I'm not convinced that it's worth the complexity that
would add.  If pages really needed this kind of composition, someone
could write a thin library around the existing push/replaceState API.

> - have a notification event when entering a history entry
>  [almost full support in spec (popstate), *3]

I guess this might be useful if you have independent components
hooking into the API.  Again, I'm not sure that this is worth the
complexity it would add.  (Should a pushState trigger a popState?
That would be a little weird.  And certainly we wouldn't want to add a
new event just to tell you that you called pushState.)

> - have a notification event when leaving current history
>  entry
>  [not supported by spec, *4]

Is the use case here to allow pages to save their state right before
the browser navigates away?  This doesn't seem essential -- the page
could just call replaceState whenever the state changes -- but I
suppose it might be useful.

-Justin

On Wed, Dec 23, 2009 at 10:52 AM, Mike Wilson <mikewse at hotmail.com> wrote:
> There are still some issues with the pushState feature of
> session history, as I wrote in August [1]. As there was a
> lack of discussion at that time I am raising these issues
> again. Below is a list of naive requirements on the state-
> handling parts of the new "client-side" session history
> mechanism, mapped against the current support in the 21
> December 2009 version of editor's draft.
>
> "It should be possible to:"
>
> - specify associated state when programatically creating a
>  new session history entry
>  [supported by spec (pushState)]
>
> - update state for the current session history entry
>  [supported by spec (replaceState)]
>
> - get state for current session history entry
>  [partial support by spec (popstate), *1]
>
> - allow for self-contained components to handle own state
>  [not supported by spec, *2]
>
> - have a notification event when entering a history entry
>  [almost full support in spec (popstate), *3]
>
> - have a notification event when leaving current history
>  entry
>  [not supported by spec, *4]
>
> Notes:
> *1: only available in popstate event, not during rest of
>    history entry lifetime (getter needed)
> *2: all page parts saving state must coordinate with a
>    shared data structure (key/value-store or similar
>    needed)
> *3: popstate event not fired for navigation with pushState
>    (fire for navigation too needed)
> *4: there is no event that fires before upcoming history
>    entry is activated (new event needed)
>
> If there is interest, I can put together a pseudo code
> example to illustrate these needs, to aid the discussion
> of solutions.
>
> Best regards
> Mike Wilson
>
> [1]
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022211.html
>
>