Introduce some tree abstraction

[cztomsik]

What problem does this solve or what need does it fill?

If I want to use this library in my project I need to build and maintain a tree of layout nodes even when I have some tree already.

What solution would you like?

I propose introducing a trait, called LayoutTree with methods for traversing & accessing the styles. Something like this:

What alternative(s) have you considered?

morphorm is already using similar abstraction, just in a little different flavor. https://github.com/vizia/morphorm/blob/main/src/hierarchy.rs

Additional context

I think there is also another option, in a sense of visitor pattern, so instead of implementing some Tree trait, one could implement TreeVisitor which could look like this:

pub trait LayoutVisitor {
  fn open_node(&mut self, style: &LayoutStyle, dirty_flags: Xxx) -> bool;

  fn close_node(&mut self, result: &mut LayoutResult);

  fn visit_text(&mut self, paragraph: &dyn Paragraph, result: &mut LayoutResult);
}

This way we wouldn't need any Tree::NodeRef because the client is rather supposed to implement internal iteration for this library, including writing the results which means we don't need any id/ref and data can be stored anywhere/anyhow.

BTW: original discussion on reddit https://www.reddit.com/r/rust/comments/v9en4v/comment/ic6pfx9/?utm_source=share&utm_medium=web2x&context=3

[alice-i-cecile]

Thanks for the writeup :) I'm definitely in favor of this, but the devil is in the details. Currently undecided about whether or not I prefer the LayoutTree or LayoutVisitor approach 🤔

To merge this I'll want to see:

1. Clear docs, including an example.
2. Benchmarks showing that there's no performance regression in the current case.
3. (Optional) Benchmarks showing that this is faster than duplicating tree state.

[jkelleyrtp]

I'm going to take a stab at this, and move our existing storage abstraction to something like a TaffyECS type.

We could then make a TaffyECS<Data> type to extend Taffy with a custom storage solution using secondary types as brought up in the #198 PR.

That way, for most users, they don't need to bother with the custom generic abstract solution, and just plop down their own tree, assuming.

I'll dogfood it against Dioxus to see if I can find a real-world API that works in our favor.

[alice-i-cecile]

Excellent. Once that PR is ready @colepoirier or I can see about dogfooding it with Bevy's solution.