mat-select does not display default (null) option text in mat-option

[zolakt]

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

I'm reposting this issue again: #6466

since you closed it without providing any reasonable workaround or an explanation why you chose to implement this super weird, opinionated, behaviour. What is the reason to implement it like this? What problems does you implementation solve or prevent? From what I can see, it's just limiting a very common use-case, without any reasonable benefits. If you really insist on this, at least make it optional with an input binding, so we can opt-out of it when we don't need it.

The only workaround for this is to use some other value, e.g. '' and then map it back and forth all over the place, for each mat-select. Honestly this is ridiculous. Totally messy, bug prone etc. and still a very poor workaround.

I haven't found a single workaround that would enable the desired behaviour in the use-case when you have your own component, implementing control value accessor, which wraps a mat-select.

Reproduction

http://plnkr.co/edit/i919jzNOoXhlPeN4hxxE?p=preview

Expected Behavior

Select should display text associated with null/undefined value when provided

Actual Behavior

Select displays nothing

Environment

• Angular: 14,0,0
• CDK/Material: 14.0.0
• Browser(s): ALL
• Operating System (e.g. Windows, macOS, Ubuntu): ALL

[wagnermaciel]

@crisbeto Given this was a deliberate decision, is this considered working as intended? Or would you like to revisit this eventually?

[crisbeto]

Yes, this is working as expected. The idea was to mimic the behavior of the native select and option elements with mat-select and mat-option.

[zolakt]

@wagnermaciel @crisbeto Sorry, but that is not an answer.

You haven't answered any of the questions that I've asked:

1. What is the reason to implement it like this? It's simply not true that the native select behaves like this (see screenshot). It shows the text "NONE", not an empty string
2. What problems does you implementation solve or prevent?
3. Can you provide some workaround?
4. Can you name just one lib (any framework, any technology) that works the way that your does?

I honestly don't get your reasoning. This is a needless limitation that is making a super common use case (optional filters, "ALL" options etc) nearly impossible to implement (at least without a totally dirty workaround, that needs to be repeated for every single mat-select)

You could at least make it optional. Instead of forcing a opinionated, weird, behaviour like this, for no good reason.

So no... this issues isn't "completed"... you are just refusing to address it... again, for no good reason.

Read the original thread... there are millions of use cases where this behaviour doesn't make any sense. So far I haven't seen a single one where it would be desirable. To me this looks like a case of a bruised ego. Instead of making it right, you refuse to acknowledge the fact that you made a poor design choice

[crisbeto]

You still have the ability to control what the trigger looks like using the mat-select-trigger element. There's a live example in the docs: https://material.angular.io/components/select/examples#select-custom-trigger

[zolakt]

@crisbeto No you don't. I tried that already.

Here is a stackblitz example:
https://stackblitz.com/edit/angular-l21cgb?file=src/app/select-custom-trigger-example.ts

The custom trigger is not shown either if mat-option value is "empty".
In that case it shows the placeholder.
And you can't use the placeholder for this purpose if you use floating labels.
Even if you could, it would be an awful hack.

These lines are the problem:

components/src/material/select/select.html

Lines 16 to 22 in 8ca012f

	<div class="mat-select-value" [ngSwitch]="empty" [attr.id]="_valueId">
	<span class="mat-select-placeholder mat-select-min-line" *ngSwitchCase="true">{{placeholder}}</span>
	<span class="mat-select-value-text" *ngSwitchCase="false" [ngSwitch]="!!customTrigger">
	<span class="mat-select-min-line" *ngSwitchDefault>{{triggerValue}}</span>
	<ng-content select="mat-select-trigger" *ngSwitchCase="true"></ng-content>
	</span>
	</div>

Others have reported this already in the original thread.
#6466 (comment)

There doesn't seem to be a clean workaround for this, not even close.
Your argument that it mimics the native select is also not true.
So again, what is the point in persisting with this weird behaviour that goes against every other select implementation?
It's just limiting a whole bunch of extremely common use cases.
This can't possibly take more than a few lines of code to make it work "normally", or at least to make this optional (since you are persisting with this so strongly).

[crisbeto]

Alright, I'll reopen the issue but it's worth noting that there are other use cases that need to be considered. E.g. if we were to match the reset option to its label, the user won't have a way to put the select back into its initial state after selecting something.

[zolakt]

Thanks.

As others have suggested in the original thread.
If the list of mat-options contains an "empty" value, than that initial/blank state doesn't make sense to begin with. So they shouldn't be able to get to it from the start, or after selection. That is how a native select works. There is no blank state.

And please don't treat null and undefined as the same thing. It's not.
You could potentially treat undefined as a reset option, but null is definitely not some magical reset option. It is an explicit value.

This isn't ideal either, since that would still require us to define union types all over the place (e.g. value: string | null). It would be much cleaner if undefined was treated as a normal value, so we could simply define it as e.g. value?: string

In my opinion, the cleanest solution is to make this behaviour optional with a boolean input binding. Let the users choose the behaviour they want. Everything else is opinionated and limiting, in one direction or another.

[crisbeto]

If the list of mat-options contains an "empty" value, than that initial/blank state doesn't make sense to begin with. So they shouldn't be able to get to it from the start, or after selection. That is how a native select works. There is no blank state.

Users may find that weird though since the form field around the select changes if a value is shown. For example you could have an empty form with a few input elements and a mat-select. The label of the inputs won't be floating, but the select will, despite the fact that you haven't interacted with it.

[Totati]

And please don't treat null and undefined as the same thing. It's not. You could potentially treat undefined as a reset option, but null is definitely not some magical reset option. It is an explicit value.

FormControls change undefined values to null.

[zolakt]

Users may find that weird though since the form field around the select changes if a value is shown. For example you could have an empty form with a few input elements and a mat-select. The label of the inputs won't be floating, but the select will, despite the fact that you haven't interacted with it.

True. But the current behaviour is even more weird. You select something (with an "empty" value) and it just disappears. This is a functionality issue, compared to the opposite which is a UX issue, at best.

Although I don't think this decision should be affected by your touched state argument. The floating label doesn't represent if something has been touched or not. It represents if the value is empty or not. e.g. take a normal mat-input and type something. The label floats. Then delete your input. The label doesn't float anymore, even though you interacted with the component. The floating label doesn't represent if something was interacted with or not, it represents the empty state. Therefore if you are using an explicit "empty" mat-option, there is no empty/blank state, and the label should always float.

Making this optional is the cleanest way to go. Let the devs decide what is less weird for their use case.

FormControls change undefined values to null.

Yeah, true, I think this is weird as well.
It converts undefined to null for the initial value, but not when you change selection.
Pretty weird and inconsistent.

Angular.Components.-.Select.with.custom.trigger.text.-.StackBlitz.-.Google.Chrome.2022-06-29.11-51-13.mp4