ickshonpe

> Should this PR move to Draft? Was said to be nearly done, then got 12 commits merged. Also designed completely changed from initial version. I'm not sure as a...

> Starting a review. From just the readme, this seems fantastic. Exactly what I was looking for in basically every way. thanks that's great, I was just about to go...

The example needs to be run with the "bevy_ui_container" feature enabled: ``` cargo run --example ui_container --features bevy/bevy_ui_container ``` Otherwise it doesn't work correctly.

Realised this might be stupid, glam's functions aren't `const` because of all the simd optimisations? I'm not sure though, `Rect` isn't normally used in such a way that makes those...

> well if you're changing things around there, could you replace the `events` with `messages`? 😄 It dispatches both events and messages so it's confusing what to do, I guess...

Ah I'm stupid I was worried this was going to be terrible but I hadn't realised required components were transitive until now 😅 I think though that `Style` might be...

Do you mean that `Style` and `Node` should be consolidated into one component containing both the layout constraints and the resolved layout values? Or is it more like `Style` being...

> I think Node should be the "driving" public facing interface containing all of the "styleable" properties inherent to a UI node. For computed values (such as calculated_size), we should...

If we don't want breaking changes then `Style` could be the central component for now, using `Node` (without changes) doesn't make sense with the new `require` api. Required components is...

Last thing, we could put require on both `Style` and `Node`?