Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate diffing view tree directly instead of nodes #18

Open
fwcd opened this issue Sep 5, 2024 · 1 comment
Open

Investigate diffing view tree directly instead of nodes #18

fwcd opened this issue Sep 5, 2024 · 1 comment
Labels
refactoring Improvements to the code structure

Comments

@fwcd
Copy link
Owner

fwcd commented Sep 5, 2024

Maybe we could do something similar to https://rensbr.eu/blog/swiftui-diffing and add a method for diffing directly to View (which by default delegates to the body). This might also let us implement memoization e.g. like SwiftUI's EquatableView.

@fwcd fwcd changed the title Diff view tree directly instead of nodes Investigate diffing view tree directly instead of nodes Sep 5, 2024
@fwcd fwcd added the refactoring Improvements to the code structure label Sep 5, 2024
@fwcd
Copy link
Owner Author

fwcd commented Sep 6, 2024

Alternatively we could also research if there's a better way to diff Node types (would be nice to do it generically, so maybe we can repurpose the Diff trait for this, potentially under a different interface?)

The main problem is that we effectively have two different "consumers" of diffs with slightly different needs:

  • Root diffs nodes to emit appear/disappear events (and possibly others in the future), preferring the flat list of added/changed/removed that we currently implement in the Diff trait
  • Backends (like Adwaita) would probably like a more structured diff, i.e. something directly in terms of Node. We could model something like that by deriving a generic "delta" type for the implementor of the diff trait and then exposing it as an associated type, the question would just be how a "reasonable" delta type would look like. For structs, we could derive this type by making all fields optional and replacing every type with its corresponding delta type (i.e. T::Delta or something similar). For vectors or other collections we could provide a generic added/removed difference. For enums it's not that simple though. We would have to differentiate between when the discriminant changes (and thus everything else too) vs. when the discriminant stays the same and the associated values change.

Another question would be whether a potential "delta" type would operate in terms of id paths. This would make the logic less reusable (e.g. it might be nice to move this generic diffing logic into a new crate), but potentially help in unifying these two representations. In that case we may be able to provide a method on the delta type to provide a list with added/removed id paths, so the corresponding appear/disappear events could be emitted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactoring Improvements to the code structure
Projects
None yet
Development

No branches or pull requests

1 participant