fix(material/form-field): outline not updated if required state changes

[crisbeto]

Fixes that the form field outline wasn't being updated when the required state of the underlying control changes. Also adds some logic to reduce the amount of times we measure the label on init.

Fixes #26848.

[devversion]

Shouldn't the underlying control instead emit stateChanges?

[crisbeto]

The control already emits to stateChanges, but the asterisk itself doesn't show up. I think that some of the data bindings in the form field need to be re-evaluated.

[devversion]

That seems surprising to me, but I also haven't played with the form field in a while. I think the flow should be:

Control changes required -> emits state changes -> form field is marked for check -> on re-render, asterisk should render -> content change causes outline refresh (via cdk observe content).

I don't understand why we need an explicit detectChanges here (and no markForCheck), and also why this is needed at all. Just trying to make sure we understand it before forcing an explicit change detection. Although it's likely fair to say that the content of a label doesn't change often.

[crisbeto]

I think that your sequence of events is correct, but I believe that the MutationObserver is synchronous so we need to detect changes for the change to be picked up immediately instead of waiting for the next change detection.

[devversion]

What would be the problem with waiting for the next change detection? You mean, that might not happen "soon" because nothing asynchronous is triggering Zone/a new application tick? If so, that seems reasonable to me

[crisbeto]

Yeah so the problem is that it may take until the next user interaction for it get picked up. This could be problematic if required is based on a data binding.

[devversion]

Gotcha. Good that we have this captured here. Ideally the comment would reflect some of these comments, but the PR is also sufficient I think.

[crisbeto]

I ran a presubmit for this, but I won't have time to debug all the failures or come up with an alternate approach for a while. From skimming through them, they seem to be in the following categories:

• Tests that were depending on the extra change detections transitively. Ideally we would add change detection calls to them, but there are a lot of them.
• Screenshot tests that show the required asterisk when they previously didn't. Need to verify if it's a fix or a regression.
• Screenshot tests where the outline width is slightly different. We can just approve these.

[crisbeto]

This should've been resolved by #26028.

[angular-automatic-lock-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.}