IsOperation method do not handle the custom operations

[righetn]

Description
We've been using custom operations introduced in this pr -> #4708

When upgrading slate and slate-dom from v112 to v118, we had some exceptions trigged on action using custom operation
After digging in the codebase, we noticed the function isEditor needs every operation to be valid to return true
But the extended operation are not included in the validation

It means if my custom operation is in the editor object when isEditor function is called, then it will return false
This makes DOMEditor.findPath to throw an exception

Expectation
Custom operation to be handle by isOperation

Environment

• Slate Version: 0.118.1
• Operating System: OSX
• Browser: Chrome

[12joan]

I'm of the opinion that isEditor shouldn't check the exact structure of editor.operations, and should use it only as one of serveral hints that a given object is an editor object. This has also led to performance problems in the past when performing a large number of operations as part of the same batch.

Formally validating that the editor object exactly matches the expected schema seems unnecessary, since unlike node objects, editor objects are never deserialised from potentially untrusted JSON. Besides, validating that an editor (or even just its children) are safe for Slate to consume without throwing runtime errors is a very difficult problem, and not one that Slate can or should aim to solve.

[nabbydude]

I think having some function to validate an editor object has its uses, but I v much agree we shouldn't need to do it 99% of the time we're doing it. (I talk more about it in #5980)

As for isOperation, it definitely has its own usecases--collaborative plugins that serialize and sync operations might want to validate the data they receive, for example--so I think whether or not its checked in isEditor or isEditor is called at all, isOperation should be accounted for when adding custom operations.

isOperation checks for specific type values because each of those types has its own properties that it also checks for. If you want to add a custom operation you'd have to wrap/override Operation.isOperation. Usually functions that are meant to be overridden live on the editor instance itself but since its a pure function that would behave the same for the base operations it should be safe to wrap.

That being said there are multiple other places in the code that check for specific operation types. (Editor#getDirtyPaths, Path.operationCanTransformPath, and DOMEditor#apply, to name only a few tricky ones.) So true custom support would mean wrapping/overriding all of them.

IDK the intent here but operations are designed to be the most basic building blocks, with more intuitive actions ("bolding part of some text", "wrapping in a block", etc) composed of multiple operations. Might be worth considering if what you want to do can work with multiple existing operations instead of a new one. (Personally this is the first I'm hearing of custom operations and it seems like an anti-pattern IMO)