run focus event listener after existing onFocus handlers

[jhurwitz]

Description
As described in the issue, the useFocused hook was returning incorrect/unexpected values. I debugged and realized it was displaying old values because of the order in which event listeners were running.

Issue
Fixes: #4754

Example
Here I repro the exact two behaviors I described in the linked issue, but with this fix in place. (View the GIFs in the issue to see what they looked like before this fix.)

Context
Based on my testing, I think there was a race condition between the focus/blur event listeners in components/slate.tsx (added in #3987) and the onFocus/onBlur handlers in components/editable.tsx. The IS_FOCUSED map was eventually consistent/had the correct values after all handlers ran, but the event listeners in slate.tsx were running before the handlers in editable.tsx and therefore the isFocused hook was displaying the old values, from before the focus/blur handlers ran.

Adding a setTimeout with a delay of 0 cause the event listeners in slate.tsx to run after the handlers in editable.tsx, thereby fixing the issue.

Checks

• The new code matches the existing patterns and styles.
• The tests pass with yarn test.
• The linter passes with yarn lint. (Fix errors with yarn fix.)
• The relevant examples still work. (Run examples with yarn start.)
• You've added a changeset if changing functionality. (Add one with yarn changeset add.)

[changeset-bot]

🦋 Changeset detected

Latest commit: b885d86

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
slate-react	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[jhurwitz]

I believe the integration test failure is a flaky test. That test passes locally, and it's failing on this line which suggests to me that maybe the wait just isn't long enough?

    cy.findByRole('textbox')
      // need wait() here otherwise the slate component is not fully mounted yet sometimes
      .wait(1000)
      .type(...

[dylans]

Actually @jhurwitz , I wonder if we really want to use window.setTimeout inside useIsomorphicLayoutEffect instead of some other timeout mechanism that doesn't rely on the presence of the window object?

[jhurwitz]

Actually @jhurwitz , I wonder if we really want to use window.setTimeout inside useIsomorphicLayoutEffect instead of some other timeout mechanism that doesn't rely on the presence of the window object?

Ah, good call. Would changing to just setTimeout work? That should call the same method in the browser, and seems to also work in Node/server-side environments where there is no window object.

[363676727]

I use the newest recently appeared.
It seems that the react on your demo is not the same.
Or is it the browser difference?

[jhurwitz]

I use the newest recently appeared.
It seems that the react on your demo is not the same.
Or is it the browser difference?

Thanks for the comment. Can you please give more details?

Are you running this out of the Codesandbox or locally? I suspect you might be running it locally, because the gray background in your screen capture does not appear in the Codesandbox.

And just to confirm -- are you testing on the main branch of slate-react, or on the branch containing this PR?

I use the newest recently appeared.

The newest what, exactly?

It seems that the react on your demo is not the same.

Are you saying you're using a different version of React.js (if so, which version? the codesandbox uses 17.0.2, the latest version), or are you saying that the reaction of the useFocused hook is different?

Or is it the browser difference?

What browser and OS are you using?

[zhugexinxin]

Actually @jhurwitz , I wonder if we really want to use window.setTimeout inside useIsomorphicLayoutEffect instead of some other timeout mechanism that doesn't rely on the presence of the window object?

Ah, good call. Would changing to just setTimeout work? That should call the same method in the browser, and seems to also work in Node/server-side environments where there is no window object.

my steps

1. git clone slate
2. modified plaintext.tsx
3. yarn start

import React, { useState, useMemo } from 'react'
import { createEditor, Descendant } from 'slate'
import { Slate, Editable, withReact, useFocused } from 'slate-react'
import { withHistory } from 'slate-history'
const FocusState = () => {
  const editorHasFocus = useFocused();
  if (editorHasFocus) {
    return <div>focused</div>;
  } else {
    return <div>not focused</div>;
  }
}

const PlainTextExample = () => {
  const [value, setValue] = useState<Descendant[]>(initialValue)
  const editor = useMemo(() => withHistory(withReact(createEditor())), [])
  return (
    <Slate editor={editor} value={value} onChange={value => setValue(value)}>
      <Editable placeholder="Enter some plain text..." />
      <FocusState />

    </Slate>
  )
}

const initialValue: Descendant[] = [
  {
    type: 'paragraph',
    children: [
      { text: '' },
    ],
  },
]

export default PlainTextExample

Environment

running on locally

Slate Version: 0.72.3
Operating System: macOS 10.15.7
Browser: Chrome 96.0.4664.55
react 16.12.0

[bryanph]

This causes a regression for me somehow when selecting between two different editors. It moves the cursor back to the previous selection instead. Trying to investigate why exactly but I narrowed it down to the setTimeout introduced here.

Perhaps a better way to solve this generally is to set the FocusedContext state in the Editable directly instead? (where IS_FOCUSED is set). Overall not a fan of using setTimeout to perform logic to make sure things run in the right order as it breaks very easily.