Issue
Almost all of the methods in the LayoutTree trait either take a taffy::Node (which is an alias for slotmap::DefaultKey) as a parameter or are required to return one. But the only way to create or use a slotmap::DefaultKey is to depend on the slotmap crate and actually a have a slotmap allocated in memory!
This is not ideal considering the whole point of the LayoutTree trait is to enable alternative storage backends.
Context
The LayoutTree trait definition: https://github.com/DioxusLabs/taffy/blob/main/src/tree.rs
I'm currently trying to create a grid widget for iced using Taffy for layout. Hopefully this should be a good test case that will surface issues like this that make Taffy to integrate with.
Proposal
The LayoutTree trait should be decoupled from slotmap. Possibly by making the node id an associated type on the trait, or just standardising on u64 instead of slotmap::DefaultKey.
Issue
Almost all of the methods in the
LayoutTreetrait either take ataffy::Node(which is an alias forslotmap::DefaultKey) as a parameter or are required to return one. But the only way to create or use aslotmap::DefaultKeyis to depend on theslotmapcrate and actually a have a slotmap allocated in memory!This is not ideal considering the whole point of the
LayoutTreetrait is to enable alternative storage backends.Context
The
LayoutTreetrait definition: https://github.com/DioxusLabs/taffy/blob/main/src/tree.rsI'm currently trying to create a grid widget for
icedusing Taffy for layout. Hopefully this should be a good test case that will surface issues like this that make Taffy to integrate with.Proposal
The
LayoutTreetrait should be decoupled fromslotmap. Possibly by making the node id an associated type on the trait, or just standardising onu64instead ofslotmap::DefaultKey.