Clarity controls causes extra valueChanges event to be sent on Angular 14

[rbirkgit]

Describe the bug

When a clarity control loses focus, there is code to check if the control has been touched. If not, Clarity sets the touched state and updates the validity and value of the control. If this control subscribes to valueChanges event, it gets one initial erroneous one which can cause existing reactive form code to break.

How to reproduce

Update to Angular 14. Have a reactive form. Subscribe to valueChanges event and focus and blur the control.

https://stackblitz.com/edit/clarity-light-theme-clr13-cds6-sksq78

Expected behavior

To behave like it did with Angular 13. No extra call to valueChanges event.

Versions

Clarity version:

• [x] v14.x

Framework:

• [x] Angular
• [ ] React
• [ ] Vue
• [ ] Other:

Framework version: ie: Angular 11

Additional notes

A workaround is to put the ClarityModule after the Angular forms module in the modules imports. If it's located in front, the blur events seem to now happen in different order than in Angular 13. Clarity get its event first and therefor the control's touched state has not yet been set. If changing the module import order, now the control is touched by the time clarity's blur event happens.

I wonder if we still need the code that checks for touched in Clarity wrapped-control.ts file. It seems it was for a workaround for numbers in certain cases.

[kevinbuhmann]

I'm not sure if we can change this without breaking apps that use Angular 13. Maybe try control.valueChanges.pipe(distinctUntilChanged())?

[rbirkgit]

We cannot use distinctUntilChanged() as the issue is the first value that comes in.

I think there a good chance we don't need the test for touched in the Clarity blur event. But I'm not familiar with the history of it. Without the workaround we cannot use Angular 14 and Clarity. So far it seems promising though. Hopefully it lasts.

[Jinnie]

This was documented in code to have been done for only one case - input[type=number] not updating its touched state. From the tests I did, I could not reproduce this initial problem. Removing the fix looks safe. We'll still need some time to test it properly, though.

[github-actions[bot]]

:tada: This issue has been resolved in version 13.9.1 :tada:

The release is available on:

• GitHub release
• v13.9.1

Your semantic-release bot :package::rocket:

[github-actions[bot]]

Hi there 👋, this is an automated message. To help Clarity keep track of discussions, we automatically lock closed issues after 14 days. Please look for another open issue or open a new issue with updated details and reference this one as necessary.