Slate throws exceptions too liberally in relation to selection failures
See original GitHub issueHello,
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?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:57
- Comments:11
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.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.