Use editor-change event to call onChange and onChangeSelection properties

[bakkerjoeri]

Closes #381

editor-change's selection change seems to more completely cover the cases in which one expects onChangeSelection to be called.

Another idea was exposing onEditorChange as a prop, and although this might provide better backwards compatibility, it also seems more confusing.

I'm curious to hear whether my proposed approach seems valid, or if you perhaps expect it to break other parts of the wrapper.

[alexkrolick]

editor-change
Emitted when either text-change or selection-change would be emitted, even when the source is "silent". The first parameter is the event name, either text-change or selection-change, followed by the arguments normally passed to those respective handlers.

My main concern would be more false-positives for selection change events when interacting with the toolbar - for example #367

[alexkrolick]

Does this fix #394?

[bakkerjoeri]

@alexkrolick

My main concern would be more false-positives for selection change events when interacting with the toolbar

I totally get that; the change I propose here feels like something that could have a lot of unforeseen side effects. All I can say is that for a while I've been using a fork with the change in this PR for a while now and things still seem to work as they should, including toolbar interactions.

[bakkerjoeri]

@alexkrolick

Does this fix #394?

I'm not sure it's related. It might have something to do with scrollingContainer though (see #239).

[parhamcurtis]

I have used this change and I can confirm this fixes the issue. I have not seen any downside to this yet! Please accept this!

[alexkrolick]

Published at 1.3.2

Thanks for everyone's input!