Issue with hooks and onBlur
See original GitHub issueHey, very useful component, thanks!
I ran into an issue when trying to use this component in a functional component combined with useState. The issue is that not all prop changes lead to an update of the component, therefore an onBlur like in my example would return the old initial content
value.
The issue resides in the current implementation of shouldComponentUpdate
.
Please look at this example Codesandbox. I copied this component’s current source code over there and just return true in the shouldComponentUpdate
and everything works fine. To see the issue, comment the return true and uncomment the original code. If you type something and look in the console, you’ll see the following logs:
render log:
render log: a
render log: as
render log: asd
onBlur log:
To fix this, I’d suggest going with a return true or make it a PureComponent to make updates based on prop changes.
Maintainer edit
Short answer
Do this
const text = useRef('');
const handleChange = evt => {
text.current = evt.target.value;
};
const handleBlur = () => {
console.log(text.current);
};
return <ContentEditable
html={text.current}
onBlur={handleBlur}
onChange={handleChange} />
NOT THAT
const [text, setText] = useState('');
const handleChange = evt => {
setText(evt.target.value);
};
const handleBlur = () => {
console.log(text); // incorrect value
};
return <ContentEditable
html={text}
onBlur={handleBlur}
onChange={handleChange} />
Explanation
react-contenteditable has to prevent rendering (using shouldComponentUpdate
) very frequently. Otherwise, the caret would jump to the end of the editable element on every key stroke. With useState, you create a new onBlur event handler on every keystroke, but since the ContentEditable is preventing rendering, your event handlers are not taken into account on every keystroke, and it’s the handler function that was creating the last time the component was rendered that gets called.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:40
- Comments:21 (5 by maintainers)
Top GitHub Comments
Hey all;
So I also hit this issue. It appears to be less about the “hooks” feature of React, and more about the paradigm that “hooks” operate within - i.e. the need to create new callback functions containing new scope closures.
The current design of this component, along with the usage of
shouldComponentUpdate
does not play nicely with this paradigm. I haven’t gone into the source in depth, and understand the introduction ofshouldComponentUpdate
was to prevent the caret position from changing. However, the current design doesn’t allow new instances of callback components to be passed down, therefore you can get into a case where an old callback instance is called with a stale closure scope, leading to difficult to debug issues and strange behaviour.To try and alleviate this I created my own wrapping component which manages refs of each callback and then passes down the callbacks down.
I’ve had good results from this as a temporary measure. My longer term hope is that we can revisit the internal design of this component as a community and move it forward.
Here is my wrapping component (click to view)
You can now write your code as described how not to do it in within the OP.
i.e. This is fine now:
Demo here
You can use the following hook to reduce boilerplate
Usage in the wrapping component
If you don’t want to copy the wrapping component, you can use
useRefCallback
as a drop-in replacement foruseCallback
:Demo