- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 11 Apr 2013 18:36:00 -0700
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: "www-dom@w3.org" <www-dom@w3.org>
On Thu, Apr 11, 2013 at 5:25 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote: > * Tab Atkins Jr. wrote: >>However, events aren't well-suited for this either, as you can't tell >>what the "current" state of loading is at the time you register >>events. Plus, while this exact case won't ever have errors, other >>similar cases may, so they'd need to add an error event too. > > You are saying that you want to inspect the state at the level you call > `addEventListener` on, but it sounds like you want to inspect the state > in the event listener, which you assume would not work because there is > initially no state transition. > > var currentState = obj.state; > obj.addEventListener('stateTransition', function(evt) { > var newState = evt.newState; > }, ...); > > If you want `currentState` then "Futures" do not really help you in any > good way, you would rather want `obj.state` to simply exist. If you want > `newState` when it isn't "new", then that problem has come up a number > of times, and could trivially be addressed with events. There have been > some crude workarounds (make the event happen when a listener might need > "fresh" information), but there are also more elegant options available. Right, Futures as written are not appropriate. I'm not particularly looking for a Future to solve this, but rather looking for a specified and well-known callback pattern for this, so that specs can use the One True Pattern when they need to do this, rather than doing lots of ad-hoc things. Today's specs solve this problem in lots of different ways, usually by using a combination of arbitrarily-named events for state transitions and arbitrarily-named attributes storing the current state. It's the "arbitrarily-named" part that I'd like to solve. ~TJ
Received on Friday, 12 April 2013 01:36:46 UTC