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-textfields.Upon experimenting, I found out that contember provides
PersistOnFieldChangedefined in this wayThe problem is described with a scenario below:
AthentriggerPersistis called. Thus, the character is saved to the correct entity. (Which is excellent).input-fieldand have to manually click theinput-fieldagain to type.only one charactercan be typed at a single time.Also there is a
PersistOnFieldChangedefined in the@contember/interfacewith 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