Closed hawkett closed 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.
Exactly that use case - i.e. signed in user lifecycle notification/awareness across the app ;)
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...
Cool - thanks for the pointers - this definitely looks like a better pattern.
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:
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.