Let developers access the initiator element in visit/fetch events #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To successfully communicate with the iOS view, messages need to be of a type supported by the structuredClone algorithm. The new TransferableVisitOptions type ensures that VisitOptions passed to the adapter conform to this type. The StructuredCloneValue type has been created based on https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm#supported_types
Ensure Navigator#currentVisitOptions is always present
domchristie
force-pushed
the
initiator_with_native_support_domchristie_turbo
branch
from
1c629b4
to
b48b4a3
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This pull request aims to provide a safe way to dispatch events on initiating elements, enabling developers to choose how to handle Visits based on the element that triggered them. (See hotwired#99). Prior to sending
Visitoptions to the adapter, non-transferable properties are removed. When creating aVisit, the original options are reinstated. Ideally the sanitization process would be handled by the iOS adapter (just before callingpostMessage), but for backwards compatibility, it needs to done at this level.