Navigate a lazy-loaded turbo-frame #212
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.
Problem
Consider a
<turbo-frame>
element withloading="lazy"
. Once itbecomes visible, the
AppearanceObserver
will delegate to theFrameController
to load its contents.However, once visible, subsequent navigations of that frame will
continue to be deferred, since its
[loading]
attribute is stilldeferred, in spite of the fact that the element is visible on that page.
Proposed change
This commit proposes to immediately navigate a
<turbo-frame>
elementwith
[loading="eager"]
or a<turbo-frame>
element that has beenloaded previously.
Possible alternatives
As an alternative to adding another conditional to the guard clause,
could it be worthwhile to treat navigational changes driven by
<a>
clicks or
<form>
submissions different from programatically modifyingthe element's
[src]
attribute? Do Custom Elements support changing anattribute's value without also kicking off change callbacks?