googlearchive / iron-signals

Publish-subscribe functionality
14 stars 16 forks source link

Don't require iron-signals to be attached to the DOM #4

Closed hawkett closed 9 years ago

hawkett commented 9 years ago

I'm trying to listen for an iron-signal in a behaviour definition. Since iron signals is reliant on the attached() lifecycle callback, I need to do the following:

var ironSignal = this.create('iron-signals');
ironSignal.addEventListener('iron-signal-hello', function(event, msg) {
   console.log("iron-signal-hello received", event, msg);
});
this.appendChild(ironSignal); /*** We shouldn't need to this. ***/

Is it possible to move the initialisation code to the ready() callback? detached() could continue to be used to attempt cleanup for those situations where it was ever attached.

atotic commented 9 years ago

Oh no, iron-signals usage in the wild :) What's the use case? I fought hard to eradicate them from google-signin, and thought they might be endangered.

I prefer to leave attached(), detached() as is. You just call attached() manually if you are using the component outside of DOM.

hawkett commented 9 years ago

Exactly that use case - i.e. signed in user lifecycle notification/awareness across the app ;)

atotic commented 9 years ago

FYI: this is what google-signin will look like without iron-signals. All auth is handled by AuthEngine. google-signin-aware is user-facing auth model, google-signin-button is the view on google-signin-aware. AuthEngine keeps a list of all signin-awares, so no need for signaling...

https://github.com/atotic/google-signin/tree/0.8-preview

hawkett commented 9 years ago

Cool - thanks for the pointers - this definitely looks like a better pattern.