We are not considering any new features to this control - Only Bug Fixes

[ADefWebserver]

We are not considering any new features to this control, other than bug fixes.

It is important that a person, who has the control working fine in their Blazor app, doesn't do a "Update All" with their NuGet packages and suddenly all their HTML controls are broken 😰

Also, we don't want to add any feature that marshals data from the Quill JavaScript component to the Blazor app (for example on each quill.on('text-change'...))

• Many people have several instances of the TextEditor on a .razor page and their app would take a serious performance hit when users start typing a novel and there are other elements on the page
• The TextEditor currently fulfills all requirements for loading and retrieving Quill contents without keystroke level binding

[Cr3ature]

Agree, to disagree

Everyone that updates their packages should follow up on major releases if it has breaking changes towards their project and implementation. Certainly if it's a vNext.

The features for marshal data worked great on a previous application using Tiny that held up to 30 editors and numerous pages within each editor. Loved to use quill for it, but your package did not have a two-way binding setup for the content within blazor and request/suggestions were shot off. It's loop workings on the machine, but who types a novel in their browser ;)

None the less, love the work and commitment. And mostly respect the decision
Grts

[ADefWebserver]

The Text Editor uses Quill as its underlying technology. Quill consists of thousands of lines of JavaScript that was designed to run under specific situations. Blazor binding, with the diffing engine that repaints parts of the webpage in unpredictable ways, without a full-page refresh (so Quill could re-initialize) is not one of those situations.

I spent weeks trying to make this work. I came to the conclusion that this was hubris, and for reliability, I must accept the situation and the limitations.