flex-basis on flex shorthand declaration about react-flexbox-layout

[rafaelchiti]

That is a silly way of formulating the question, I think I just wanted to check if by any chance you know or you have any idea about it, certainly uing auto by default makes more sense, however there is something in the combination of layouts that is causing issues, Im isolating an example at the moment trying to reproduce it, will update here.

[bywo]

I'm not sure why I went with flex-basis: 0 earlier. It might have been so
that the flex child wouldn't cause the parent to expand if the child had
wide content. But if that's the case, having flex-shrink: 1 should help

On Tue, Jun 21, 2016 at 2:04 PM Rafael [email protected] wrote:

That is a silly way of formulating the question, I think I just wanted to
check if by any chance you know or you have any idea about it, certainly
uing auto by default makes more sense, however there is something in the
combination of layouts that is causing issues, Im isolating an example at
the moment trying to reproduce it, will update here.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#24 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABXjcQh2F3zO-APKJOP5CPV9a1nzFGHEks5qOFH1gaJpZM4I6UPN
.

[rafaelchiti]

Hey, well this case is driving me crazy so far is a weird bug with how IE11 calculates the width for the scenario of using align="stretch" on a HLayoutItem, either way, does not seem like something the library should tackle, at least not from my understanding so far.

I know I should remember this but I don't :( hehe can we add 'technical' explanation of why immediate children of a HLayoutItem align="stretch" are turned into 'flex items' with value 1 1 auto. Since we keep getting confused by this and I keep forgetting the conceptual and rational of this.
I can add a 'technical' section to the README if it makes sense for some rationales like this.

Thanks!!

[bywo]

So stretch is tricky. There are two cases to consider

1. The LayoutItem is the largest item in Layout, so it renders as it normally would
2. The LayoutItem is not the largest item in Layout, so it stretches to match the size of the container

We have this non-ideal situation where we can't inject props onto children elements.

e.g. given this code:

<HLayoutItem align="stretch">
  <div>this div should be stretched</div>
</HLayoutItem>

the ideal output would be

<div style="align-self: stretch">this div should be stretched</div>

but since we can't trust the child component to pass along the style prop, we end up doing this:

<div class="growChild" style="align-self: stretch"> // HLayoutItem
  <div>this div should be stretched</div>
</div>

and we need the CSS rule for growChild to satisfy the two cases listed above.

Does that make sense?

[rafaelchiti]

Brilliant! thanks very much, we could probably add this very same explanation to the README? under a 'technical' section.