[custom-elements] :unresolved and :psych

I'm working with several individuals of varying skillsets on using/making
custom elements - we are using a way cut-back subset of what we think are
the really stable just to get started but I had an observation/thought that
I wanted to share with the list based on feedback/experience so far...

It turns out that we have a lot of what I am going to call "async
components" - things that involve calling 1 or more services during their
creation in order to actually draw something useful on the screen.  These
range from something simple like an RSS element (which, of course, has to
fetch the feed) to complex wizards which have to consult a service to
determine which view/step they are even on and then potentially additional
request(s) to display that view in a good way.  In both of these cases I've
seen confusion over the :unresolved pseudo-class.  Essentially, the created
callback has happened so from the currently defined lifecycle state it's
":resolved", but still not useful.  This can easily be messed up at both
ends (assuming that the thing sticking markup in a page and the CSS that
styles it are two ends) such that we get FOUC garbage between the time
something is ":resolved" and when it is actually conceptually "ready".  I
realize that there are a number of ways to work around this and maybe do it
"properly" such that this doesn't happen, but there are an infinitely
greater number of ways to barf unhappy content into the screen before its
time.  To everyone who I see look at this, it seems they conceptually
associate :resolved with "ok it's ready," and my thought is "that isn't
necessarily an insensible thing to think since there is clearly a
pseudo-class about 'non-readiness' of some kind and nothing else that seems
to address this".

I see a few options, I think all of them can be seen as enhancements, not
necessary to a v1 spec if it is going to hold up something important.   The
first would be to let the created callback optionally return a promise - if
returned we can delay :resolved until the promise is fulfilled.  The other
is to introduce another pseudo like ":loaded" and let the author
participate in that somehow, perhaps the same way (optionally return a
promise from created).  Either way, it seems to me that if we had that, my
folks would use that over the current definition of :resolved in a lot of
cases.



-- 
Brian Kardell :: @briankardell :: hitchjs.com