Quill Editor does not work as expected with Angular Signal Forms

[grizlizli]

Hello 👋

We recently upgraded our project to Angular v21 and started using the new Signal-Based Forms API. When integrating it with the Quill Editor, we encountered an unexpected issue.

🚨 Problem

When applying the Field directive from Signal Forms on the component, the text cursor becomes stuck at the beginning of the editor.

As a result, all typed characters appear in reverse order.

For example:

Typing: hello

Produces: olleh

📌 Reproduction

•	Angular version: 21.x
•	Using Signal-Based Forms
•	Field directive applied to quill-editor
•	Editor initializes, but cursor never advances from index 0

💡 Expected behavior

The cursor should advance as the user types, and characters should appear in the correct order.

❗ Actual behavior

The cursor remains at the start of the text, causing characters to be inserted in reverse.

[KillerCodeMonkey]

Feel free to contribute on this with a pr.

I just upgraded to angular 21 and checked the default behavior within my demo repo.

I had no time to check out signal based forms, yet.

[KillerCodeMonkey]

@grizlizli i added a "failing" example to the demo repo for reproduction

[KillerCodeMonkey]

i do not even know if it is in general expected to work correctly, since an angular "field" just directly adds two way binding. So i do not even know how this should even generally work out of the box when using an ControlValueAccessor component.

In general i guess a whole new component is needed (but my knowledge about those new forms are limited, yet)

[grizlizli]

Similarly to the ControlValueAccessor, there is an interface FormUiControl, base contract for all form controls, easier to implement.

[grizlizli]

I'll try to take a look into the issue in next few days. Thanks!

[KillerCodeMonkey]

@grizlizli as a workaround just do something like this for now:

[ngModel]="form.editor().value()"
(ngModelChange)="form.editor().value.set($event)"

editorField = signal({ editor: '' })
form = form(this.editorField)

[KillerCodeMonkey]

For a new component - here is a minimal guide:

https://angular.dev/guide/forms/signals/custom-controls

[KillerCodeMonkey]

@grizlizli since i see many issues regarding custom signal form controls are popping up at the angular repo... honestly i would wait to create a new component for now and go with workaround i posted.

[mruknowme]

I'd agree, Signal Forms are the way forward. Having a proper solution is better and more future proof than trying to jam in changes and make an unreliable hybrid implementation.

Looking forward seeing Signal Forms supported implementation.

Thanks!

[Jaimy128]

<quill-editor [formControl]="control" />

I experience the same with Reactive Forms

[KillerCodeMonkey]

@Jaimy128 check the demo repo there are working examples with reactive forms

[grizlizli]

Thanks @KillerCodeMonkey!

We made it work with the workaround. However, touched/dirty states are not reflected in proper manner with Signal Forms.

[KillerCodeMonkey]

thanks for the feedback, but as i already commented earlier... you do not have to adopt directly to the newest features,since reactive forms / template driven forms are working with angular 21 + zoneless change detection.

I would recommend just to wait to introduce them in existing/complex applications until this feature feels a little bit more stable.

But feel free starting to implement a quill-editor-signal component and create a pr :).

[mruknowme]

@KillerCodeMonkey let me know if I'm interpreting your latest comment correctly. The way I understand it, you are saying no official development to support signal forms will even begin until signal forms are more 'stable' and more widely used. Is my understanding correct?

In which case it's a, well, very 'interesting' mindset. It's pretty apparent that Signal Forms will only grow in adoption. Meaning, eventually signal forms support will be basically required to stay up to date. And it's not too far in the future. I'm no 10x developer but I'd imagine it's not just 20 minute job to convert to signals. I think it makes sense to make an 'early' start (which isn't really early anymore anyway).

Concerned that API may change? Sure, will it change so significantly that it will be like a third re-write? Unlikely. If there are some changes, what will be quicker - make minor changes to already created signals implementation, or only begin working on the implementation in the future?

Further more, the two implementations can co-exist. Make signals a separate import, no need to make drastic changes to the existing component working with Reactive Forms.

I think it's a classic defensive case where community basically telling you they need it, and you are saying 'no, not needed yet'.

Don't take it as an offense, just give it another thought;)

[KillerCodeMonkey]

You are correct and that is the way i would go to build a new component. But i am not blocking to create a new component ;-)

But if you need it urgent... please contribute.. that is what i say...

And I said you should wait to invest hours or days in converting existing complex apps with complex forms directly after a release of a major version change.

For this component here it means in general: i implement new features and everything when ever i have time to.

Since i am not deep dived signal forms, yet. i will do it, if i have more experiences with it and time to start building a new component.

So if you have already experience to build CustomControls with Validators and so on. Feel free to contribute.

So i am not blocking creating a component now for ngx-quill. My last comments was a general one, when and if you should directly adapt hard changes in your apps not in this lib. ;-)