editor.selection is delayed so selection is undependable to find current element

[thesunny]

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

bug

What's the current behavior?

Press a cursor key and the cursor position is not updated in editor.selection for between 100ms and 200ms on a fast computer.

This causes funkiness like holding down tab in a table. We read the current td and move to the next but because of the slow selection updates, the cursor jumps several times to the same td because it is returning the old selection (i.e. cursor has moved but we keep getting the td from before the move because of the old selection).

Also the cause of other issues to do with cursor movement.

Slate: 0.55.3
Browser: Chrome
OS: Mac

What's the expected behavior?

In earlier Slate like 0.47, the editor.selection was updated within a requestAnimationFrame.

[thesunny]

I think I found the cause of the delay and it's in the debounce in the onDOMSelectionChange method here https://github.com/ianstormtaylor/slate/blob/master/packages/slate-react/src/components/editable.tsx

@ianstormtaylor I noticed that you switched lodash's _.throttle (0.47) to the debounce package (0.50+) and this is probably what is causing the issue. Looking at the docs, lodash's throttle invokes on both the leading and trailing edge of the call by default and Slate 0.47 was using the default call. This means that in 0.47 we get the first selection change immediately.

This differs from debounce which always waits until [x]ms has ellapsed before firing for the first time.

The debounce method does have the option to fire on the leading edge but it looks like then it wouldn't fire on the trailing edge which we would still want.

Are you okay with switching back to `lodash's throttle method?

[ianstormtaylor]

Hey @thesunny thanks for investigating this. If I remember right, there was some reason I ended up using debounce instead of throttle, but I can't remember why.

I think the ideal would be to use neither, and just let the code run very frequently? But I feel like I remember there being an issue with that too (other than performance, which I'm okay to wait and see if it's even a problem).

If you can verify that switching to _.throttle fixes it I'm down to revert that. Although I'd prefer to use a smaller dependency, since it seemed like lodash was always really complex to ensure that the bundle size stayed small.

Ideally I'd love to get rid of throttling or debouncing entirely.

[thesunny]

There's two ways to keep the bundle size small.

1. Use the npm package lodash.throttle which is just the throttle code extracted (2.1KB and 993B gzipped according to bundlephobia).
2. Use the lodash package but import it with a path like import throttle from 'lodash/throttle' (I assume its the same size but not listed on bundlephobia)

I tend to use #2 in my code because I get access to other lodash methods when I need them without having to add more packages; however, if throttle will ever be the only import, it's probably better to use the lodash.throttle package.

I can use the method you prefer.

Note: I do tend to agree that not having to use throttle or debounce at all would be preferred. I can think of some use cases that could cause issue and come to think of it, I wonder if this is what caused or contributed to the Android bugs when holding down backspace.

[ianstormtaylor]

The 2nd one sounds good to me.

Yeah I'd love to see both of them removed instead.