Flex-layout: Proposals for improving shorthand syntax and disabling additional styles

[adamdport]

I find myself constantly frustrated and surprised by this layout API. I wanted to start a conversation as to what I'm expecting vs what actually happens.

Shorthand syntax

The shorthand flex: 1; in CSS applies the flex-grow: 1; styling. The shorthand syntax for this API, however is fxFlex="<basis>". This is counter-intuitive.

I like that fxFlex alone applies flex: 1 1 0.000000001px, but imho fxFlex="2" should yield flex: 2 1 0.000000001px.

A compromise could be that _if units are used_ (ie. fxFlex="100px" instead of fxFlex="100", then the shorthand affects flex-basis instead of flex-grow, but personally I don't find myself ever wanting to use shorthand to affect flex-basis.

Additional fxFlex Stylings

The shorthand flex: 1 1 200px in CSS implies flex-grow: 1; flex-shrink: 1; flex-basis: 200px;. The general form fxFlex="1 1 200px" however, adds max-width: 200px; min-width: 200px;. This is counter-intuitive (and unusable in all of my use cases thus far).

I'm sure you added this for a reason, but could I we have the ability to disable these additional fxFlex stylings via config or something?

---

I love the concept of this API but feel that it's trying to do too much for me. Thanks for your consideration!

[greenGoby]

This same issue just wasted a bunch of my time today. I was sitting here struggling with why fxFlex="1 1 120px" wasn't behaving the same as flex css attribute. It was then I stumbled upon this min-width and max-width additions, which I have to agree are very counter intuitive. In fact, I am being forced to write the flex css by hand to get around this. Would love to see a fix or a way to work around this.

[ThomasBurleson]

We are discussing and attempting to address this issue before Beta.13 (in December).

[CaerusKaru]

Alright, here's what I have in mind for this (totally open to discussion):

• convert fxFlex to modify flex-grow instead of flex-basis
• introduce a new fxBasis to modify flex-basis exclusively, since supporting two behaviors on one directive seems counterintuitive
• possibly add an injection token FLEX_BASIS_COMPAT that maintains the old behavior for those who don't want to screw up their templates. This could be removed in a subsequent release. An alternative would be to have this token opt-in to the new behavior
• add an injection token FLEX_WIDTH that when set to true will add the width parameters to CSS, and won't otherwise (we could also add a compatibility token for this in the event that it represents too much of a breaking change – possibly bundled with the basis token)

Would this be satisfactory?

[adamdport]

Yes! For the last two bullets I like the injection token idea. This would permit support the old style syntax for a few releases to give people time to refactor. That being said, what was the original purpose of the max-width min-width thing? Is it safe to deprecate that behavior and remove it in a future release?

convert fxFlex to modify flex-grow _instead of flex-basis_

Just to be 100% clear, flex-shrink and flex-basis SHOULD have the correct defaults set (ie. 1 and 0% respectively) to satisfy flexbug #6. I'm not sure why this implementation uses the 0.0001px thing instead of 0%, either way is fine with me.

Thanks!

[ThomasBurleson]

@adamdport - many of the weird outputs for flex-basis and max-width originated as part of efforts to resolve browser-bugs and issues.

@CaerusKaru - the fxFlex supports many usages: single value (<basis>), full value set (<grow ), andcalc()` values. I am loathe to introduce a new fxBasis API.

• I do like the idea of an injection token for backwards compatibility.
• I think a configuration API may be explored to configure specific runtime outputs.

[CaerusKaru]

@ThomasBurleson Sounds good. I meant more that we shouldn't/couldn't support two defaults on fxFlex, hence the added directive, but I see your point that it's just adding more complexity.

So then, the idea would be to change fxFlex to maintain its current form (with other fixes for other issues), so that by default it affects flex-grow instead of flex-basis, where users can still modify both in the full form. Then we add a compat token so that the old behavior is preserved for those who want it.

We can discuss more offline, but that looks pretty solid to me.

[adamdport]

If fxFlex is changed to affect flex-grow by default, we don't really need the existing fxGrow anymore. For consistency I think a fxBasis could replace it. Not sure why fxGrow and fxShrink were ok but fxBasis isn't?

[CaerusKaru]

Apologies, but I think this is going to get punted to beta.15. I'll follow-up with @ThomasBurleson on the idea of adding a fxBasis directive, but there's a chance it might not happen.

What I'm looking at in terms of possibilities is adding a new token or tokens, i.e.

DEFAULT_FLEX = InjectionToken<'basis'|'grow'|'shrink'>

{provide: DEFAULT_FLEX, useValue: 'grow'}

and

DISABLE_SIZING = InjectionToken<'nomax'|'nomin'|'nosize'>

{provide: DISABLE_SIZING, useValue: 'nosize'} // disables max-width and min-width (and height)

Does that seem reasonable/do you have any other suggestions?

[adamdport]

I like the approach, but I'm not a fan of the options for DISABLE_SIZING. The reason for the max/min-width was to resolve a flex bug right? If that's the case, why would someone want to _only_ disable max-width or _only_ disable min-width?

I never understood that approach in the first place (hence this ticket) so I can't speak to what others would want. Unless I'm missing something, you're effectively disabling flex behavior and just setting a static width, right? It can't grow or shrink. Maybe just have two options, 'flex'|'noflex', where 'flex' disables the max/min-width sizing?

[CaerusKaru]

The reasoning for max/min width/height I think is best expressed in this excellent article by Dave Geddski.

The reason I thought of for disable min, max, or both, is so that users could override the styles themselves. I think flex|noflex is too ambiguous for options.

[adamdport]

I didn't understand how that article justified setting max and min to the same value. In this example, you can see that flex: 10000 10000 10000px;, flex: 0 0 0px;, flex: none;, and flex: 1 0 50px; all yield the _exact_ same results when setting max/min-height to the same value. imho you're not using flexbox anymore, thus my "noflex" suggestion.

Personally, if I wanted a max or min, I'd want to apply that specifically to each element that needed it. As an enhancement, I might suggest new tags for max/min (eg. fxMax="100px")? Can you give an example of a use case for users wanting to only override max or min across an entire app? (or am I misunderstanding something?)

Regardless, it sounds like what you've proposed will let me configure it to work like I'd expect. So if you think other devs are using it the way you've envisioned, then we're all set. Thanks!

[CaerusKaru]

Let me try and paint a clearer picture for you. The article explains that it's sometimes necessary to preserve the sizing intention by setting a max/min-width/height. So, for instance, if you want to preserve growth, you need to set min-width/height, as mentioned in the Wiki page you linked above. If you want to preserve shrink, you need to set max-width/height. If you want to preserve both, you need to set both.

In the examples you listed, max-width would only be set on the first and fourth examples. Min-width only on the first example (thus both would only appear on the first example, and would be set to 10000px for min and max). Therefore, although in your example setting the min/max-width to the same thing does yield the same results (almost by definition), that wouldn't actually be the case for those definitions.

We won't introduce fxMax/fxMin as new directives. That makes this even more confusing for new devs. As it is, I'm still not convinced it's necessary to have config to override this behavior, although I am partial to the needs for customization with any library. So, instead of a token or new directive, how about a new option for fxFlex like this:

fxFlex="1 1 50px nomax nomin" where nomax and nomin are optional and do as you would expect

[adamdport]

I don't understand what you mean by "preserve growth/shrink"—I would expect it to grow or shrink like pure css flexbox does based on available space.

If we're adding optional inputs to fxFlex, could we do fxFlex="1 1 50px min max" where I can actually pass in my own min/max values, or none if I want none? I think that would be very useful and flexible enough that anyone can use it. It can default to the current behavior, which would mean it's not a breaking change, and would just complement existing functionality.

[CaerusKaru]

I'm going to open a separate issue where we can poll users (I think this one kind of got pushed into the aether). I'm not opposed to your idea, and I respect that you think fxFlex should more of a direct translation to the flex CSS property.

The library was originally designed to be the most accessible to newcomers to Flexbox, where when someone wrote fxFlex="200px" it meant they just wanted a box that would "flex" to 200px within the context of a flex container. I know this doesn't match your expectations, and we can change this if we get enough positive input one way or another.

[CaerusKaru]

https://github.com/angular/flex-layout/issues/689

[adamdport]

Totally fair, thanks!

[CaerusKaru]

Closing this since it will be wrapped up by #884, tracking in #689

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}