Abstract flexbox over LayoutTree (rebased on top of latest main)#238
Conversation
|
@alice-i-cecile What would it take to get this PR merged? While I don't think the abstraction has quite been perfected yet, I'd rather do further work on top of this (and make further improvements in follow up PRs), because I think it's much cleaner (key improvement for me is passing the storage in an explicit parameter hidden behind a trait, rather than using self). However, I'm also reluctant to build too much on top of this as:
|
|
I need to dedicate an hour or two to review this, but I similarly feel that this should be merged pretty aggressively. I'll try to get that done for you by end of day next Monday (my 20% time at work). May happen before that, but you can hold me to that deadline. |
alice-i-cecile
left a comment
There was a problem hiding this comment.
I'm on board. This is well done, and in-line with my broader vision for how this library should evolve to support multiple layouts.
Merging now.
|
Just wanted to say thanks for reviewing this :) |
This PR is #202 rebased onto the history rewrite, and with the latest main merged in to resolve conflicts.
Files other than flexbox.rs were merged automatically by git.
Flexbox.rs was taken from this branch, and the following commits were manually ported in:
constcontext (Make library more usable in aconstcontext #203)hidden_layout()to parent scope (Movehidden_layout()to parent scope #208)Original PR description below:
This PR makes the flexbox algorithm generic over a LayoutTree trait.
At the time of filing this PR, the LayoutTree trait mostly abstracts over the broadest set of functions that the Taffy struct satisfies. I don't know or think this is the best and most general solution to flexboxing: Taffy internally does caching of calculations that a user's LayoutTree shouldn't really be concerned about. Perhaps some of the state - like caching - could remain in a Taffy struct, but this level of specificity intrinsically ties a user's UI system to Taffy due to dependent data structures.
Generally, since Taffy uses its own types, most implementations will be tied to Taffy anyways, so perhaps this linking of user code to Taffy is not a big deal.
Also - this trait supplies a method that returns a FlexboxLayout (not the final layout, despite the confusing name) which might not be exactly a trait implementation would return the "current state" of the DOM Node. For instance, in Dioxus, we are using the CSS Cascade to supply the "current state" of the DOM node's style. I think before publishing out these changes, it might be worth further abstracting the trait to supply single-level Taffy attributes. Perhaps a "TaffyAttribute" enum could be supplied so use cases like Dioxus' cascading CSS could be implemented efficiently.
Closes #182