linebender / xilem

An experimental Rust native UI framework
Apache License 2.0
3.16k stars 92 forks source link

Widget IDs? (for usability, persistence, animations) ("explicit identity") #318

Open makoConstruct opened 1 month ago

makoConstruct commented 1 month ago

In SwiftUI and Flutter, you're able to assign each widget an ID, which it will use to track the widgets between widget tree renders, which is good for two kinda big things:

This is a situation where I'd really want an optional id parameter, but rust has alternatives to optional parameters (chainable setters (Widget::set_global_id(self, Box::new(ProfileID)): Widget)).

IDs can be local or global. A local ID will only be tracked against its siblings (the framework will assume that it wont leave that nesting level), and a global ID will be tracked wherever it goes in the tree (which requires more strictness in maintaining uniqueness, so you wouldn't do it by default). A local child of a global parent will be tracked even if the global parent moves.

To aid global uniqueness, it would be good to make use of Any stuff to use the type of the ID as a discriminator. For example, struct ProfileID; could be a type that was defined for one widget in the entire application, which effectively uses the compiler to maintain a guarantee of uniqueness from other type ids.

Philipp-M commented 1 month ago

I'm not sure if I get what you mean, and whether Xilem or masonry is meant. Xilem itself is using the type-system via the View trait to check whether the widgets have changed and retains the widget state (including focus), but as you note, it doesn't track tree-structure changes currently of views which are moved somewhere else in the view-tree.

I think you mean explicit identity of Views (and their respective Widgets), which I think is planned.

See also Demystify SwiftUI for more information (explicit identity starts around 5:00).

makoConstruct commented 1 month ago

Explicit identity, yes, that's it.