use destructuring for middleware arguments

[ianstormtaylor]

Do you want to request a feature or report a bug?

Idea / discussion.

What's the current behavior?

Right now the signature for event middleware is:

(event, editor, next) => {
  // ...
}

And more generally, middleware are:

(...args, editor, next) => {
  // ...
}

And transforms are often long as well:

addMark = (editor, path, offset, length, mark) => {

}

But this has some issues...

What's the expected behavior?

We end up not being able to add any arguments to middleware to expose new things over time, without either attaching them to event objects (which is awkward, and React makes even more problematic with its "synthetic" events), or attaching them to the editor itself, which results in everything being chucked there, and awkward scenarios like React's editor and non-React's editor being different.

If we were to use destructuring instead, we could do:

({ event, editor, ref, el, next, ... }) => {
  // ...
}

And for transforms, similarly:

({ path, start, offset, mark, editor, ... }) => {
  // ...
}

This makes API evolution a lot easier, since adding new things isn't a breaking change. And it makes passing in optional arguments easier to reason about. And it makes separating out the editor grab bag possible.

---

But there is a counter argument that having everything on editor, while bad for being a random bag of stuff, is also positive because it means there is only ever a single object to pass around, and we're guaranteed to have access to it everywhere. Without that, we might end up with situations where you want the ref but it isn't passed in, etc.

If anyone has any other pros/cons, I'd love to hear them!

[brendancarney]

I can't think of many cons other than it being another change. I definitely like the extensibility of it.

[ianstormtaylor]

Fixed by #3093.