Constraints data should be stored on a per-axis basis

[alice-i-cecile]

          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:

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:

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:

pub struct LengthConstraint {
    pub min: Val,
    pub max: Val,
    pub suggested: Val,
} 

it's much more natural:

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),
        // .. 
    }
}

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:

 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 bevyengine/bevy#5513 (comment)

[nicoburns]

Hmm… there’s definitely a case to be made for this. I’ve reduced a lot of this noise by implementing methods directly on Size (which allows a kind of vectorised api that acts on both axis at once), but the are definitely still places where there is quite a bit of noise from the axis selection code.