[Beta] - Get error context with onContentError event?

[stpp2]

Hi,

Thanks for this awesome library!
Playing around with the latest branch (currently 2.5.0-beta.4) and I'm trying to get info from the onContentError event.

It's firing properly as expected (with enableContentCheck enabled), but how can one get the actual invalid HTML tag or piece of content that's causing the error? That'd be great for testing content in bulk and adding any missing tags via custom extensions.

The error message itself seems generic - Error: [tiptap error]: Invalid HTML content. Am I missing anything here?

CC: @nperez0111 - #5178

Thanks!

[nperez0111]

Hi @stpp2 Unfortunately with the way that it is implemented right now for HTML, we only check that some content did not match any schema. I could see how knowing that info would be useful though.

I wonder how to provide that information to you though. Since it is implemented as an error we have error.cause (which we already use to notify for the JSON errors). What would you expect on that property?

[stpp2]

Ahh I see, thanks!
I'm indeed using HTML input rather than JSON.

The error.cause doesn't return anything at the moment, so really just getting any kind of insight there would be absolutely great. (the invalid tag name, list of tag names, or the piece of HTML that did not match the schema)

Thanks again for the help!

[nperez0111]

Yea error.cause only gives something when the input is JSON. I can extend the HTML handler to include a tag name to match what the JSON one does

[stpp2]

That would be really great! 🙏

[nperez0111]

Ok I've added an error.cause with https://github.com/ueberdosis/tiptap/releases/tag/v2.5.0-beta.5

[stpp2]

Thanks! Really appreciate the quick update.
It's very useful for testing and debugging.

One minor thing [I think] I've noticed is that it only shows up one error, even though there could be 10 different invalid errors in the HTML document. Not a huge problem but I suppose it could be also nice to log them all.

[nperez0111]

Yea, I was trying to be in line with the existing errors with the JSON version. Unfortunately an error isn't a great way to communicate this sort of a thing. If I receive more feedback on it, I can maybe add an additional value to the callback instead of trying to stuff it into an error.