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

this.setState({editorState: EditorState.createEmpty()}) doesn't work to clear the component #73

Closed
rcoh opened this issue Feb 24, 2016 · 15 comments
Labels

Comments

@rcoh
Copy link
Contributor

rcoh commented Feb 24, 2016

With this method, the editor seems to get its internal state corrupted.
EditorState.moveFocusToEnd(EditorState.createEmpty()) was required to actually clear the state properly.

@tasti
Copy link
Contributor

tasti commented Feb 24, 2016

Did you mean to do this.setState({editorState: EditorState.createEmpty()})?

@rcoh rcoh changed the title this.setState({EditorState.createEmpty()}) doesn't work to clear the component this.setState({editorState: EditorState.createEmpty()}) doesn't work to clear the component Feb 24, 2016
@rcoh
Copy link
Contributor Author

rcoh commented Feb 24, 2016

Sorry, the title is incorrect. I did this.setState({editorState: EditorState.createEmpty()})

@tasti
Copy link
Contributor

tasti commented Feb 25, 2016

I can't get this to repro. I used the plaintext example and created a button that calls this.setState({editorState: EditorState.createEmpty()}) when clicked, which worked fine.

Do you have some sample code to share?

@rcoh
Copy link
Contributor Author

rcoh commented Feb 25, 2016

I cleared on handleEnter which I think was related to the issue. The component clears, but then if you continue typing into it your input goes onto the next line. I'll see if I can make a reproducing case this evening.

@hellendag
Copy link

Did you return true from your handleReturn function? This tells the keydown handler that the event should not be treated like a newline insertion.

http://facebook.github.io/draft-js/docs/api-reference-editor.html#cancelable-handlers-optional

@rcoh
Copy link
Contributor Author

rcoh commented Feb 25, 2016

Yes, I returned true and then cleared the input. Upon subsequent typing it seemed like my newline was latently sitting there waiting for more text.

@hellendag
Copy link

Can you provide a gist?

@Ahineya
Copy link

Ahineya commented Mar 2, 2016

Hello! I'm experiencing this issue too. Here is the gist:
https://gist.github.com/Ahineya/e689a012e32a48e6d734

After pressing escape or enter, the editor is cleared, but when I press a letter key, it adds a letter after the cursor, not before. And after pressing a letter key second time, it creates a new line with previous key. It produces this html: https://gist.github.com/Ahineya/bb4556ae3e5503ce1ddf

And after pressing enter or escape, produced html is like this:
https://gist.github.com/Ahineya/a12fcafe7379a43f7261

And when new line is created, pressing escape or enter doesn't remove it.

EditorState.moveFocusToEnd(EditorState.createEmpty()) helped.

@hellendag
Copy link

EditorState.moveFocusToEnd(EditorState.createEmpty()) helped.

Thanks, this helps give me a hunch about what the issue is here.

When using EditorState.createEmpty, we can't currently make any assumptions about whether the generated SelectionState has focus or not, since one may be prepopulating the editor without focus. We therefore create a non-focused SelectionState.

As you note, using moveFocusToEnd will resolve the issue. This is because the current selection will be given focus, and subsequent edits make sense to the editor.

I think the right fix here is to create an EditorState.createEmptyWithFocus method for use cases like these, where the focus should remain in the editor after clearing it, basically exactly as you've implemented above.

static createEmptyWithFocus() {
  const empty = EditorState.createEmpty();
  return EditorState.moveFocusToEnd(empty);
}

Does that sound like a good solution to you?

@rcoh
Copy link
Contributor Author

rcoh commented Mar 2, 2016

Yes. Any chance you could log a warning if createEmpty is called and the
editor remains focused with a hint to use createEmptyWithFocus? There is no
obvious reason why createEmpty would also cause the component to blur.

On Wed, Mar 2, 2016 at 11:44 AM Isaac Salier-Hellendag <
notifications@github.com> wrote:

EditorState.moveFocusToEnd(EditorState.createEmpty()) helped.

Thanks, this helps give me a hunch about what the issue is here.

When using EditorState.createEmpty, we can't currently make any
assumptions about whether the generated SelectionState has focus or not,
since one may be prepopulating the editor without focus. We therefore
create a non-focused SelectionState.

As you note, using moveFocusToEnd will resolve the issue. This is because
the current selection will be given focus, and subsequent edits make sense
to the editor.

I think the right fix here is to create an
EditorState.createEmptyWithFocus method for use cases like these, where
the focus should remain in the editor after clearing it, basically exactly
as you've implemented above.

static createEmptyWithFocus() {
const empty = EditorState.createEmpty();
return EditorState.moveFocusToEnd(empty);
}

Does that sound like a good solution to you?


Reply to this email directly or view it on GitHub
#73 (comment).

@hellendag
Copy link

There is no obvious reason why createEmpty would also cause the component to blur.

Hmm, it's hard to say where exactly the warning would go. Within a createEmpty call, we won't have any awareness of whether the editor is still focused in the DOM.

@hellendag hellendag added the bug label Mar 2, 2016
@hellendag
Copy link

Would love a PR for this, with or without a console warning. :)

@Ahineya
Copy link

Ahineya commented Mar 3, 2016

Does that sound like a good solution to you?

Yes, thank you. I have understand that this is by-design stuff :)
I think you should add this example to documentation to avoid misunderstanding in future.

@hellendag
Copy link

EditorState.moveFocusToEnd is now added to the docs, so I'm going to go ahead and close this.

@adrianmcli
Copy link

This was great. I feel like this should be in an FAQ somewhere. Clearing the editor should be a pretty common use case.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants