Issue with reactivity
crayon1337 opened this issue · comments
Hi there,
Thank you for the great efforts put into this package. I really find it awesome. However I experienced a minor bug whether I am doing something wrong or it is an actual problem with the editor.
I am trying to build a small Filament hint next to the editor that would show the characters left as the user type in
TiptapEditor::make(name: 'short_description')
->required()
->maxLength(self::$model::$shortDescriptionTextLimit)
->reactive()
->hint(
fn($state, $component) =>
'left: ' . ($component->getMaxLength() - strlen(str_replace(' ', '', strip_tags($state)))) . ' characters'
)
->columnSpan(span: 'full');However, the hint shows perfect fine on page load. But, as I start typing in nothing is updating. I believe the $state is not being updated. Therefore, it does not update the hint.
Hi @crayon1337, which version of the plugin are you on? I did a quick test on 2.6.5 and I can replicate the issue.
I think there are a few things at play here, but the first thing that comes to mind is that reactive() can be a become a bit expensive if the content of the editor is very large. It will make a full round-trip to the server with the content on every key press. I'm curious to see if we can find a solution for this that stays 100% client-side.
Hi @pboivin I am running version 2.6.5 as well.
I strongly agree that relying on the server would be very expensive.
Probably this https://tiptap.dev/api/extensions/character-count would be useful? If the characters count might be resolved using client side and then just inform the component of the updated count then it can be used to get the count of characters in there. However, it should also strip the HTML tags to get an accurate number of the characters count in the editor's content.
This is always a tricky thing to do with WYSIWYG editors. It's never safe.
Image you show a character count that is based on the text size and it's under your limit. All good.
But you have to save the data in the DB with the HTML, now your character limit is over budget, and if that limit is based on the DB field size, it won't be able to save.
If you're just showing the user the count just for the sake of it then it's fine, but those things all have to be considered.
I agree that it's a tricky problem. If we ever integrate this into the plugin, I'd be in favor of explicitly documenting that the character count is for end-user feedback on the text (e.g. need to limit the field to X characters for SEO, design guidelines, etc.), and that the DB considerations are entirely up to the programmer.
Seems reasonable to me.