Constraints data should be stored on a per-axis basis
- Dominant language
- Rust
- Stars
- 3.6k
- Forks
- 222
- Avg merge
- 10h 41m
- Merged PRs (30d)
- 40
Description
The way the constraints data is structured seems wrong to me.
In Flex you usually access the constraints one axis at a time but the current API makes that awkward and fragile.
For example, look at the `text_constraint` function in the widget/text.rs:
```rust
pub fn text_constraint(min_size: Val, size: Val, max_size: Val, scale_factor: f64) -> f32 {
match (min_size, size, max_size) {
(_, _, Val::Px(max)) => scale_value(max, scale_factor),
// ..
}
}
```
called with:
```rust
text_constraint(
layout.size_constraints.min.width,
layout.size_constraints.suggested.width,
layout.size_constraints.max.width,
scale_factor,
)
```
If the constraints data is stored per-axis:
```rust
pub struct LengthConstraint {
pub min: Val,
pub max: Val,
pub suggested: Val,
}
```
it's much more natural:
```rust
pub fn text_constraint_2(length_constraint: LengthConstraint, scale_factor: f64) -> f32 {
match length_constraint {
LengthConstraint { max: Val::Px(max), .. } => scale_value(max, scale_factor),
// ..
}
}
```
```rust
text_constraint(layout.size_constraints.width, scale_factor)
```
In Bevy that is the worst it gets at the moment, but in Taffy there are lots of tangled sections like:
```rust
if constants.node_inner_size.main(constants.dir).is_none() && constants.is_row {
child.target_size.set_main(
constants.dir,
child.size.main(constants.dir).unwrap_or(0.0).maybe_clamp(
child.resolved_minimum_size.main(constants.dir).into(),
child.max_size.main(constants.dir),
),
);
} else {
child.target_size.set_main(constants.dir, child.hypothetical_inner_size.main(constants.dir));
}
```
where most of the complexity would vanish with some sort of per-axis interface.
_Originally posted by @ickshonpe in https://github.com/bevyengine/bevy/issues/5513#issuecomment-1386300923_
Contributor guide
Assessment
This issue has not been assessed yet.