Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Exposing onDocumentChange to the plugins

See original GitHub issue

Hey @ianstormtaylor, I was going to build an autosave plugin that saves on debounced onDocumentChange. Currently, I have that functionality in the onDocumentChange method passed to the editor. And I’d like to move it to a plugin.

To do that, I’d need onDocumentChange available to the plugins. Is that something you’d like as a PR? Are there any implications of this that you can foresee?

At a quick glance, it seems like this line here needs to call stack.onDocumentChange.

Issue Analytics

State:
Created 6 years ago
Reactions:1
Comments:5 (3 by maintainers)

Top GitHub Comments

1reaction

dklanaccommented, May 31, 2017

@ianstormtaylor First off. I have to thank you for your work here with Slate. It’s so well done. I have a key project I’m working on that needed a flexible editor, and your approach is how I hope to see DraftJS core eventually go.

I do support the idea of getting rid of onDocumentChange in favor of allowing devs to use the built in React callbacks like componentDidUpdate to decide when to serialize. It feels more natural to me after I saw your suggestion earlier in this thread.

Thanks again for your work here.

0reactions

dmitrizzlecommented, May 31, 2017

lol I built exact same plugin, but used _.throttle() instead. Same issue. Will try both componentDidUpdate and state.document != prevState.document - thank you for exposing this info.