Size Change: +1.3 kB (0%)

Total Size: 1.37 MB

_{compressed-size-action}

@saramarcondes So far so good!! I'm testing this locally in Gutenberg, forcing the new Flex everywhere.

I'm spotting a minor implementation issue.. but I think it can be easily resolved.

To be specific, it's related to the current InputControl. TLDR, there may be cases where the label needs to be visually hidden. However, the new Flex rules are adding margins on children elements, regardless if they're visually hidden or not. I think this particular use-case is uncommon. A more common workflow would be resolved with conditionally rendering elements as null if falsey (rather than hiding via CSS).

That being said.. I expect this to resolve by refactoring the InputControl with the new G2 Components.

In the meantime, we can add a patch fix to smoothen out InputControl rendering with the new Flex components.

P.S. Moving forward, it is unlikely for us to use Flex directly. From my experience, HStack/VStack would accommodate most use-cases. Even on my most wildest prototypes, I haven't need to reach for Flex.

Update: Alternatively... we could change the Flex gap strategy to match the current implementation. That could smoothen things better.

For context...

Current implementation:

.Flex > * { margin-right: 8px };
.Flex > *:last-child { margin-right: 0 };

G2 implementation:

.Flex > * + * { margin-left: 8px }

Technically they achieve the same thing. But I think the current implementation has less room for side-effects

Update: Looked into things in the G2 repo. There's pros/cons to both Flex inner child gap strategies 😂 😭 .

I think the newer G2 implementation offers more room for adjustments. I went through a bunch of places where this is used, in particular all Button and Input variants. Often, it's the last element that requires some sort of normalization. From a CSS perspective, since it cascades top-bottom (or left to right), it's easier to make that adjustment on the last item with margin-left: 0.

For example, an input

[ Input value    ↕️ ]

For a > * + * flow, we can normalize the margin on the ↕️ element.
For a > * flow, we'd have to do some negative margins to offset the previous margin-right. And this negative margin can be any value, because the gap value is dynamic.

Not impossible, just a lot more work.

With all this said... I think it's better to keep the G2 Flex gap strategy, and make retroactive adjustments to areas that may be affected. From what I've seen, it's only the InputControl.