bug
Custom block will unmount when you type Chinese, but not when you type English, Is this normal?
reproduce in this fiddle: https://jsfiddle.net/shenenkaka/5oqgbpc4/18/
Custom block should not unmount when you type language that DraftJs support
Draft.js version: 0.11.7
browser: Chrome v87,macOS Big Sur
It is also not work in previous version.
I'm having a similar issue when typing brazilian portuguese. We have some letters that use accents e.g., é, ê, ã, etc. Typing any of these triggers an unmount on all our custom components. It can be really troublesome if we have a custom component that does a request or some async code, as it keeps redoing it every time we type any of those letters. I made some tests and this behavior started happening on v0.11.0.
It can also be reproduced in the example @Shenenkaka made.
After further investigation, I found the commit responsible. This behavior started happening on this PR: https://github.com/facebook/draft-js/pull/2035
It solved major issues related to Android input and word composition. The issue seems to be directly tied to the alterations made to the DraftEditorCompositionHandler.js file. Apparently after any kind of composition, it runs a function called restoreEditorDOM, which is described as "a complete re-render of the DraftEditorContents based on the current EditorState". Before the PR, this function was only called when certain conditions were met, now it seems to happen everytime a composition is completed.
Trying to work on a solution for this.
Hey! Some updates. I've made a solution and tried to return the composition behavior to what is was before v0.11.0 version without losing the fixes made for Android. I brought back the mustReset flag and with that I expect the re-render of the DraftEditor to happen only on certain conditions. So, a composition on the start of a new text block will still cause the unmount on atomic blocks, this unmount is still necessary for draft-js to work properly, as stated in some comments in the code:
We also re-render when the composition occurs
at the beginning of a leaf, to ensure that if the browser has
created a new text node for the composition, we will discard it.
I made a code sandbox with a version that has my fix and the CustomBlock @Shenenkaka made, if the CustomBlock is unmounted it will show up on the Console. I'll link it here so anybody can test and please, give me some feedback if you run into any kind of problems.
https://codesandbox.io/s/draftjs-basic-example-forked-5rr3j
The sandbox uses the package draft-js-composition-fix, version 0.0.1.
Hey! Some updates. I've made a solution and tried to return the composition behavior to what is was before
v0.11.0version without losing the fixes made for Android. I brought back themustResetflag and with that I expect the re-render of the DraftEditor to happen only on certain conditions. So, a composition on the start of a new text block will still cause the unmount on atomic blocks, this unmount is still necessary fordraft-jsto work properly, as stated in some comments in the code:
We also re-render when the composition occurs at the beginning of a leaf, to ensure that if the browser has created a new text node for the composition, we will discard it.I made a code sandbox with a version that has my fix and the CustomBlock @Shenenkaka made, if the CustomBlock is unmounted it will show up on the Console. I'll link it here so anybody can test and please, give me some feedback if you run into any kind of problems.
https://codesandbox.io/s/draftjs-basic-example-forked-5rr3jThe sandbox uses the package
draft-js-composition-fix, version0.0.1.
Nice fix, but it still unmount at the first time typing. @lousander
小伙子来试试我这个编辑器,开箱即用,功能强大https://github.com/gland2015/gland,快来颗star
Most helpful comment
After further investigation, I found the commit responsible. This behavior started happening on this PR: https://github.com/facebook/draft-js/pull/2035
It solved major issues related to Android input and word composition. The issue seems to be directly tied to the alterations made to the
DraftEditorCompositionHandler.jsfile. Apparently after any kind of composition, it runs a function calledrestoreEditorDOM, which is described as "a complete re-render of the DraftEditorContents based on the current EditorState". Before the PR, this function was only called when certain conditions were met, now it seems to happen everytime a composition is completed.Trying to work on a solution for this.