Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explicitly fire ready() #178

Closed
beriberikix opened this issue Jun 10, 2013 · 6 comments
Closed

Explicitly fire ready() #178

beriberikix opened this issue Jun 10, 2013 · 6 comments

Comments

@beriberikix
Copy link

I think it makes sense to allow us to explicitly for ready(). There will be times when a component is still bootstrapping the js even after the HTML is rendered, like if it loads json configs async. What I have to end up doing is writing a second custom event reallyReady().

@sjmiles
Copy link
Contributor

sjmiles commented Jun 12, 2013

I may not be following you.

ready is there for you to do whatever you want, but it happens at a discrete quantum of time with respect to the element lifecycle. If you want to do something at some other time, this is also up to you.

IOW, ready is not some notification to others that you are in any particular state,.

@beriberikix
Copy link
Author

Let me give more context. I'm trying to make a ui-less components from js libraries that I don't have control over & that have their own api-ready callback. Take the Google+ JS library - plusone.js. When's it's all set up, it calls a callback function it grabs from the url:

https://apis.google.com/js/client:plusone.js?onload=plusOnloadHandler

What I'd like to do is have ready be called when the component is actually ready, IE when plusOnloadHandler fires. Otherwise, I'd have to have a second "ready" method and somehow bubble up the plusOnloadHandler as an event or chained function.

If not, do you have better recommendation on how to handle ui-less JS includes?

@sjmiles
Copy link
Contributor

sjmiles commented Jun 12, 2013

I think you want something like this:

https://gist.github.com/sjmiles/5763113

@beriberikix
Copy link
Author

Thanks!, I'll give that a spin. I was going to add comments on the gist but it might be more useful for others to address them here:

  • Is it possible that google_plusone_loaded gets called before ready? Then plusOneReady will never get called.
  • I'm curious why you included the array. Does it handle the condition mentioned above? If so, would you suggest that as a best practice worth documenting more fully?
  • What exactly is ready and what guarantees do we have about it? Is it comparable to onload, domcontentready or something else? Is it possible that code before or after Polymer.register could trigger (similar to my question above.)
  • How do you recommend we handle multiple libraries with various onready callbacks. The port I'm working on has plusone.js-style, an explicit onApiReady custom event, the overall document ready and I guess WebComponentsReady. My initial plan is to include a q.js component (a Promise library) in my main app and have the various ready events call then to kick off the app bootstrapping flow.

All of this is rather dizzying and I wish there was an opinionated route - coming from require.js and/or Angular's DI, I'd love to hear your thoughts!

@sjmiles
Copy link
Contributor

sjmiles commented Jun 12, 2013

  • What exactly is ready and what guarantees do we have about it? Is it comparable to onload, domcontentready or something else? Is it possible that code before or after Polymer.register could trigger (similar to my question above.)

ready is a personal concept for your element. It does not have any particular bearing on any other state. It's simply a place for you to do initialization on your element, must like a constructor.

ready is guaranteed to be the first code your element runs. It's only called by the element creation code itself and never by any other trigger. It is not an event.

In these senses, it's completely different from onload, domcontentready, etc. We realize the name is confusing, we may have to change it. Imagine it's called created, does that help?

  • Is it possible that google_plusone_loaded gets called before ready?

Yes, but when google_plusone_loaded is called, the addInstance implementation is replaced by the notify implementation, so any objects that are readied after that point have plusOneReady called immediately.

  • I'm curious why you included the array. Does it handle the condition mentioned above? If so, would you suggest that as a best practice worth documenting more fully?

The array handles the case where you make N instances of your element before google_plusone_loaded time. It's hard for me to suggest this is a best practice, as it's just a simple algorithm.

  • How do you recommend we handle multiple libraries with various onready callbacks.

I don't really understand the question, probably we will need more examples. :)

@sorvell
Copy link
Contributor

sorvell commented Oct 2, 2013

Closing since this is a per-element issue.

@sorvell sorvell closed this as completed Oct 2, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants