-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Possible shared state on core elements. #731
Comments
What shared state are you seeing? paper-radio-button and core-drawer-panel both have Note that The |
2 similar comments
What shared state are you seeing? paper-radio-button and core-drawer-panel both have Note that The |
What shared state are you seeing? paper-radio-button and core-drawer-panel both have Note that The |
Thanks for the quick response, I do see now that the objects I was concerned about are part of the publish object. Thank you for clearing that up. I haven't run into a specific shared state scenario in my development, but was trying to find some use case examples of how to use a created callback. Thanks for pointing out the eventDelegates as well. |
The documentation provides some great guidelines when initializing objects and arrays for an element. It suggests to initialize them in a created callback instead of the prototype object. This should prevent a “shared state”.
I tried to find some good examples of how this is done in the core and paper elements on the polymer site, and discovered this is typically not the case. I only found a few set up this way.
core-component-page has a created callback that initializes objects and arrays.
A few examples of elements that don't implement this are:
paper-radio-button
core-submenu
core-drawer-panel
The core and paper elements should be updated to using a created callback to further clarify the importance of its use, and prevent a shared state.
The text was updated successfully, but these errors were encountered: