Chris Eidhof@krzyzanowskim the key problem is that the layout system is top-down, and you cannot size yourself according to siblings. So some parent is responsible to make them the same width (based on their individual widths!). This is the simplest way I know of doing this that's backwards-compatible (you could abstract this further btw). https://gist.github.com/chriseidhof/51076f16b6725ff8b17f99cc656d17be
Exandra@chriseidhof @krzyzanowskim hey Chris. Your solution looks like it involves a feedback loop. Can it be addressed without a loop? For example, read the width of label but adjust the frame that contains it?
@Alexbbrown @krzyzanowskim the feedback loop is broken because we're proposing nil using fixedSize.
@chriseidhof @krzyzanowskim Oh I get it now! So the effective size of fixedSize is the intrinsic size of text, which we read, and then after finding the largest, use that to inflate the frame, which does not affect the overlay but does affect the button outside it?
@Alexbbrown @krzyzanowskim yes, the fixedSize makes sure we measure something that's independent of whatever it was proposed. The frame both proposes that width as well as makes sure the entire button becomes that width.
@chriseidhof @krzyzanowskim it's less clear to me how the overlay knows what size to be. Why isn't the overlay inside the fixed size?
@Alexbbrown @krzyzanowskim the overlay takes on the reported size of the text. You might enjoy this Swift Talk collection: https://talk.objc.io/collections/swiftui-layout-explained
