Plugin support for onMouseOver, onMouseOut etc.

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

Feature

What’s the current behavior?

If a plugin wants to handle onMouseOver or onMouseOut events, it either needs to bind arguments in the render method, or store data in a data-attribute. The specific use case I’m trying to achieve is taking action based on mark data on mouse over.

class Plugin {

  static onMouseOver(event) {
    console.log(event.target.getAttribute('data-foovalue')
  }

  static renderMark() {
    const fooValue = props.mark.data.get("foo");
    return (
      <span data-foovalue={fooValue} onMouseOver={Plugin.onMouseOver}>
        {props.children}
      </span>
    )
  }

}

What’s the expected behavior?

It would be great if onMouseOver and onMouseOut were supported “naturally”, such that we got an event and a change, so we had access to value, document, fragment, or mark data. We wouldn’t need a renderMark function then, and could do something like:

class Plugin {

  static onMouseOver(event, change) {
    // vague-ish pseudo-code. could also handle this by addition
    // of a new `hover` range to the change object, similar to selection.
    const node = findNode(event.target, change.value)
    const marks = node.getMarksAtRange(rangeOfNode), 
    console.log(marks[0].data.get("foo"))
  }
}

I’m happy to put together an initial pass at this, if it’s likely to be accepted in principle, and if I can be pointed in the right direction 😃

[mmdonaldson]

Any updates on this? Do we need someone to dive into it? As this is also a requirement for me too

[AndreiRailean]

I see, you’re optimising for memory. Perhaps it’s worth writing a proper component and letting react optimise for multiple instances of the same component

const MySpecialMark = ({fooValue, children}) => {
  const onMouseOver() => consoleLog(fooValue)
  return (
      <span onMouseOver={onMouseOver}>
        {children}
      </span>
  )
}

and

  ...
  static renderMark() {
    const fooValue = props.mark.data.get("foo");
    return <MySpecialMark fooValue={fooValue} />
  }

I guess it’s similar to my other suggestion.

Your suggestion seems like a common pattern in Slate.js so it’s quite easy to reason about. Serialisation rules work in the same way: loop over all rules, find one that can generate a node from content. Having convenient access to the value, change is important, but pure components don’t need to know anything about it - just feed them callbacks.

Anyway, sounds like you already know how to implement it. Give it a go!