Slate: Add onFocus to Editor's contenteditable div

[JasonEtco]

It would be great to have a way of knowing when the contenteditable div in the editor is being focused; I would then set a state in the Editor: isFocused: true.

What do other people think about this? Can't be that hard to implement.

[ianstormtaylor]

Hey @JasonEtco, have you checked out the isFocused property on the Selection object? It's also proxied on the State object, so you should be able to simply do if (state.isFocused) to get what you want. Let me know if that's not what you meant!

[JasonEtco]

@ianstormtaylor That does sounds like what I'm asking for, but I'm getting an error any time I try to look deeply into the state tree using Chrome's React Dev Tools, which is preventing me from actually looking into it. I'm sure you're aware of this bug though.

On the other hand, I think it would be a neat feature to pass our own onFocus function for some added customization; I know that for my app, it would mean a lot less code that cancels out other code.

[ianstormtaylor]

Interesting idea, what kinds of things are you doing onFocus?

Not sure what you mean about the error in the state tree though!

[JasonEtco]

Using Redux, I'd like to be able to change a boolean in my store. Because the isFocused bool is part of the Editor's state, I don't think there's a way for me to run like a componentDidUpdate kind of thing from outside of the Editor, to be able to check when that isFocused boolean has changed.

In terms of the error I'm seeing, when (in React DevTools) I click the triangle beside state: State{...} to expand the object, I see the following error in console (and also the object doesn't expand):

Uncaught TypeError: Cannot read property 'key' of null                node.js:1117 

[ianstormtaylor]

For the error, it looks like it's due to this bug in React Dev Tools: https://github.com/facebook/react-devtools/issues/390

Still not sure what the exact use case looks like for the isFocused. Could you not grab that value with an onChange handler on the <Editor> and store it for later access if you need? If not, do you have some pseudocode of what you mean?

[JasonEtco]

I suppose I could use the onChange, but it seems like a more semantic way of knowing when the thing is focused would be to use onFocus. I think this has evolved from a feature request to more of a change in the handlers of some sort?

[ianstormtaylor]

It would definitely be more semantic for that use case, but then it might lead to having to have more and more custom handlers for specific pieces. I could be down to add it in a bit if it becomes a really common need. But for now I think it's best to keep things simpler with just onChange or onSelectionChange if there's a worry about document changes impacting it for performance.

[JasonEtco]

Alright, sounds good. Thanks for listening @ianstormtaylor :+1: