Defensively create custom turbo elements #483
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are instances when turbo attempts to create the frame and stream
elements when they have already been registered. This is easily
reproducible in development when using webpacker by following these steps:
When Turbo replaces the page it appears as if it reloads the Turbo
library and attempts to create the custom elements again. I have also
observed this behavior in my production app via my exception monitoring
service, but have been unable to reproduce this behavior in production
on my own.
This change simply checks for the existence of the custom element prior
to to attempting to define it. The
get
method used here explicitlyreturns
undefined
when the element does not yet exist so it is safe touse the strict equality operator here. Reference:
https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry/get
Fixes #188