Skip to content
This repository has been archived by the owner on Feb 6, 2023. It is now read-only.

ContentState.replaceEntityData does not cause DraftEditorContent to re-render #1189

Closed
jtadmor opened this issue May 2, 2017 · 2 comments
Closed

Comments

@jtadmor
Copy link

jtadmor commented May 2, 2017

Do you want to request a feature or report a bug?
bug

What is the current behavior?
When using contentState.replaceEntityData and then pushing the resulting EditorState, DraftEditorContent component does not update.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. You can use this jsfiddle to get started:

The way I did this was creating a custom 'atomic' type block with an entity, and then updating the entityData. I have not tested this with other block types.

https://jsfiddle.net/m6z0xn4r/187/

(Note that after hitting "make me blue", the next time a change - such as typing in new characters - triggers a render(), the text is indeed blue)

What is the expected behavior?

In shouldComponentUpdate for DraftContentEditor , prevContent !== nextContent is returning false when applying contentState.mergeEntityData.
I would expect either the resulting ContentState object to have changed, or for their to be a separate check that looks at entityData (this seems like it would be more expensive).

Which versions of Draft.js, and which browser / OS are affected by this issue? Did this work in previous versions of Draft.js?

Draft: 0.10
Browser: should be any, this is a code issue

@jtadmor jtadmor changed the title ContentState.replaceEntityData does not return a new contentState and so does not update the Editor ContentState.replaceEntityData does not return a new contentState, DraftEditorContent does not re-render May 2, 2017
@jtadmor jtadmor changed the title ContentState.replaceEntityData does not return a new contentState, DraftEditorContent does not re-render ContentState.replaceEntityData does not cause DraftEditorContent to re-render May 2, 2017
@tobiasandersen
Copy link
Contributor

This is actually the expected behavior currently, but it will be fixed in a future release, see e.g. #1047 for some more info.

@jtadmor
Copy link
Author

jtadmor commented May 3, 2017

Thanks, and sorry about the duplicate issue :)

@jtadmor jtadmor closed this as completed May 3, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants