Dom state cache #240
Merged
Dom state cache #240
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
added 4 commits
June 23, 2023 17:12
I want to keep impossible state impossible, but for some of the Selection mode transitions I need to know what the current state of the DOM is. We _could_ pass everything and kitchen sink in every time a DOM node changes but I think it would be more elegant to avoid that.
Moving and cleaning up a couple of other things.
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.
I've been seeing some bugs, where, as a much select changes, and moves from 1 configuration to another the configuration gets out of sync with the DOM.
For instance:
(I added a unit test, to test for this exact scenario, hopefully more unit tests like this one will help prevent us from breaking things like this in the future)
There's a few ways I could have solved this problem, but the one I thought would be the easiest to reason about would just be to keep a separate record that would just keep track of what the state of the light DOM is. Then in the logic for transitioning from one configuration to another we can bring in this
DomStateCacherecord whenever we need to.Hopefully this will allow for some progress to be made on #89
Right now this feature is only half baked. There will be more work to do to handle all the changes in the light DOM that we want to track.