Fix bug where calling load() on lazy element breaks the loading#66
Merged
Fix bug where calling load() on lazy element breaks the loading#66
Conversation
koddsson
approved these changes
Jul 29, 2021
Contributor
koddsson
left a comment
There was a problem hiding this comment.
This looks good to me ✨
This file contains hidden or 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
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.
Fixes #67
This PR fixes #67 where calling
load()on aloading=lazyelement causes the contents not to be replaced when the element becomes visible.Context
There are two bugs at play here:
observer.unobservewhenload()was called. This is incorrect as it should only be called once content replacement has happened.load()doesn't actually properly preload the request, since nothing is done with the response - it should be saved into the weakmap but that is only done bygetData()notload().Fix
The fix here is twofold:
observer.unobservecall from theload()code.load()logic to a private function and instead callgetDatafrom theelement.load()function,getDatacorrectly caches the response or immediately returns a cached response, so it is the correct code to call to preload the response#66Implications
Technically this change does modify the public api of
include-fragment- if someone was subclassing the element and re-implementingload()to modify say how events are fired, this will no longer work for them. I cannot find any examples of us doing this within github (we do reimplementfetchbut notload.