[whatwg] history state object api issues

[Mike Wilson]

Justin Lebar wrote:
> > - 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.

It seems we agree that this is an issue with the current API 
that forces all components to cooperate, or be coordinated, 
through a central point. The rub with those thin wrapper 
libraries is that all components need to be using the same 
library and thus also requiring cooperation, albeit in a 
different way.

Examples that could be using this feature are drop-in 
components that implement things like trees and rich-text 
editors that automatically cooperate with session history to 
restore their values or layout, without manual coding to 
collect all data inside an app-specific data structure. Of 
course, these components can continue to use DOM tricks that 
hook into the browser's form field storage, but I thought 
one of the point with the state object feature was not 
having to do that.

> > - 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.)

I agree this is the most questionable part of my observations, as
programmatic activation of a feature doesn't normally trigger the associated
event. Though, here it would simplify code as a "logical" page can get its
state in the same way independent of it was "navigated" (pushState) or
traversed (history) to.
Also, it seems like the other programmatic way to switch state objects,
History.go/back/forward, does trigger the popstate event, but maybe that
should go away instead?

> > - 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.

Certainly the page code can update the state on every change of
user-editable state, setting up a swarm of event handlers not to miss
anything important. My point is that this is not always practical, imagine f
ex serializing a large tree or rich-text editor on every update event.

(Btw, did you have any insight on issue #1?)

A merry Christmas to all you web-standard-oholics out there! :-)

Best regards
Mike

> 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-Augus
t/022211.html
> >
> >
>