Replies: 2 comments 1 reply
-
Hi, Thanks for the question! You're right in observing that PersistOnFieldChange isn't well-suited for rich-text fields. It's primarily designed for one-off discrete changes—like selecting an option from a dropdown or updating a status. We use it, for example, in our Kanban board to persist status changes instantly. Saving every keystroke in a text-based field (especially rich-text) typically leads to issues like the one you're seeing—it interrupts the input flow and doesn't scale well in practice. Could you share more about your use case for autosaving the rich-text field? Depending on what you're trying to achieve, we might be able to suggest a better pattern—like debounced saving or saving on blur or inactivity. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I saw that contember provides Currently, I have fixed this issue by popping up a dialog warning the user about unsaved changes which works well with the scope. Thank you! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, I'm trying to implement autosave for
rich-text
fields.Upon experimenting, I found out that contember provides
PersistOnFieldChange
defined in this wayThe problem is described with a scenario below:
A
thentriggerPersist
is called. Thus, the character is saved to the correct entity. (Which is excellent).input-field
and have to manually click theinput-field
again to type.only one character
can be typed at a single time.Also there is a
PersistOnFieldChange
defined in the@contember/interface
with the same issue.I wanted to know if this is the intended feature and also wanted to know how to modify this component to implement what I need.
Thank you!
Beta Was this translation helpful? Give feedback.
All reactions