ComponentDidMount wipes out all decorators
See original GitHub issueUse-case/Problem
I found a few mention of this error in the logged issues but none seemed to truly address the problem other than suggesting not to use ComponentDidMount()
which makes it a bit problematic for what what I am trying to do.
I am currently using two plugins that have decorators and as long as I am not using ComponentDidMount
they work as expected but for some reason when that life-cycle method is introduced it wipes out all established decorators.
I am currently using "draft-js-plugins-editor": "^3.0.0"
I am happy to try and workout a fix but I’ll need some pointers as to what in the codebase needs fixing. Or if someone has a simple work around.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:4
- Comments:8
Top Results From Across the Web
react componentDidMount not firing - Stack Overflow
The reason why the "componentDidMount" methods weren't firing was because my server was bundling and serving all the react + html stuff on...
Read more >Lit for React Developers - Google Codelabs
Lit is a simple library for building fast, lightweight web components that work in any framework, or with no framework at all.
Read more >React Class Component vs Functional Component - Telerik
If you're a React developer or new to React, this article clears up some of the confusion between these two types of components...
Read more >Build a Simple CRUD App with Python, Flask, and React
The oktaAuth object has a method called signOut() that will wipe out all user related data from the session. This is exactly what...
Read more >React.Component
componentDidMount () is invoked immediately after a component is mounted (inserted into the ... This method is a good place to set up...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yes. The documentation suggests that you can set the decorator at any time https://draftjs.org/docs/advanced-topics-decorators#setting-new-decorators
Looking at the code, there’s no penalty on setting the decorator to the same value it already is: https://github.com/facebook/draft-js/blob/master/src/model/immutable/EditorState.js#L203.
So instead of using
componentDidMount
,draft-js-plugin-editor
can set the decorator oneditorState
before passing it to the underlying Draft.js instance. Or it can set the decorator once in the constructor, and again whenever theeditorState
property changes.Whenever something gets fixed with a setTimeout, it’s most likely a race condition.
When draft-js-plugin mounts, it uses the original editorState, adds decorators, and calls onChange.
https://github.com/draft-js-plugins/draft-js-plugins/blob/ed27d94b35dc91e5ceee510aab35a0813bf7dc7a/draft-js-plugins-editor/src/Editor/index.js#L66
Then the component mounts and calls focus, draft.js also uses the original editorState, adds focus, and calls onChange.
https://github.com/facebook/draft-js/blob/928563b1a3ac999389ed82dbf193dbc3bc9e7223/src/component/base/DraftEditor.react.js#L515
So there are two calls to onChange, one with decorators, one with focus, and the component only stores the last change.