Slate throws exceptions too liberally in relation to selection failures

Hello,

I would like to start a discussion about error handling in Slate which I think is too strict as Errors are often thrown for things that could just as easily be ignored or replaced by a warning. These are in functions like toDOMPoint or toSlateRange when Slate is trying to do things like map a HTMLElement to a Node but cannot because there is no direct mapping (the HTMLElement is created indirectly by a Slate Node). In many cases Slate will throw an Error that will take down the whole page. I understand that various attributes can be applied to have Slate ignore certain regions of the editor but I’ve still found it a bit of a fight and I really don’t understand why Slate can’t just return early in cases where no DOM-to-Slate mapping exists. In fact, I have forked Slate and disabled these Errors (here and here) and made Slate return early and while this fork is a WIP, I can tell you that my app is much better for it - it’s less work for me and I will still find problems where things aren’t wired-up correctly and I no longer have anxiety of deploying to production and worrying about the WSOD when the user’s only crime was clicking on an empty <div/> (I know prod apps should have error handling but again it feels like I am having to handle more errors than is really necessary).

Some ideas:

• As above, log a warning like React does when in development mode and only use Error when it is absolutely necessary (cannot be recovered/ignored).
• Maybe Slate could add a onError callback to its API for users to learn about errors

Thoughts?

[skogsmaskin]

So far the only error that have been really problematic for me is this one (Cannot resolve a DOM point from Slate point):

Tracked in own issue here: https://github.com/ianstormtaylor/slate/issues/3575 (my comment here https://github.com/ianstormtaylor/slate/issues/3575#issuecomment-620568898)

It makes collaborative editing near impossible, because as far as I can tell, there is no way we are able to adjust the selection when a new value is coming in through props before slate-react tries to naively restore the current user selection to a potential invalid DOM-range.

[mpkelly]

Hi @CameronAckermanSEL, I use componentDidCatch in production as it is necessary whether using Slate or not. However, it feels like Slate is the source of too many errors and that’s the key point. There is also the development experience when first getting started to consider, too - here people might not have proper error handling in place and have to constantly restart/refresh/whatever due to errors for things they probably don’t even care about.

Slate seems to think it has to do something based on every interaction with the editor otherwise there is a bug but I don’t think this is right. I guess raising errors was just the easiest approach for the library devs when trying to get 0.50 ready but I don’t think this is the best longterm approach for the library consumers who should ideally decide what is critical and what is not.