Discussion regarding abstractions

[VarLad]

@nicoburns First of all, thank you for the awesome project.
I need some pointers (if possible), for my own project, a big part of which is heavily inspired by Taffy.

My assumption is that Taffy has some abstract interfaces/functions and "flexbox" and "grid" just implement those, and I assume that other layouts fit in those interfaces as well.
Can you point me to the parts of Taffy that defines such interfaces/parts? In other words, what are the parts that are irrelevant to flexbox or grid or any specific implementation?

[nicoburns]

The core abstraction is the LayoutTree trait. Algorithms mostly implement fn(tree: &mut impl LayoutTree, node: NodeId, inputs: LayoutInput) -> LayoutOutput - block, flexbox, and grid do, although the "leaf" and "hidden" algorithms are different because they require different inputs. See also: the LayoutInput and LayoutOutput types (the "margin" properties could be eliminated from these types if you don't need to support CSS Block layout margin collapsing).

We did also have a LayoutAlgorithm trait, but I removed it just yesterday! The primary problem with it was that it hardcodes the Style type, and while I could make it generic over the Style type, I don't really want to hardcode the Style type at all: I want to make each algorithm generic over an algorithm-specific style trait and allow users to provide anything that implements the trait. But Rust doesn't allow a trait to be generic over a trait, so doing that would require a trait per algorithm. Which is kind of what I'm planning: removing the style method from LayoutTree and then having traits like FlexboxLayoutTree: LayoutTree that add back in an algorithm-specific style method.

I also have a PR up that modifies the trait a little. The key thing that's driving changes at the moment is a tricky balance between web-like "open world" systems where the entire node tree is globally accessible to the layout code, and "closed world" systems where each widget in the tree is a black box which you can only interact with via it's public interface (which in Rust ends up being quite restricted because of poor support for dynamic typing - you can't easily express "this object may or may not implement this interface" in Rust).

For "open world" systems we really want to handle things like rounding internally within Taffy. But in "closed world" system it won't always be possible for consumers to Taffy to provide us with the interface necessary to make that work, and they'll need to implement that themselves.

---

See also:

• Proposal for layout / child widget sizing in Xilem linebender/xilem#37
• https://docs.flutter.dev/ui/layout/constraints
• https://developer.android.com/jetpack/compose/layouts/custom

Sorry this isn't quite as neat and pinned down as I might like. But I hope that gives you something to go on.