Batching makes it difficult to perform imperative actions like focus

[astoilkov]

Example

Take a look at the example. Regardless of the fact that inputRef.focus() is called the input is not focused. This is because batching is in progress and the input still hasn't been rendered.

https://playground.solidjs.com/anonymous/1da322c3-dded-42c5-a735-1dc8a3d5878e

Problem

I can't focus the input while staying inside of the runWithOwner() function.

I can restructure the code to use Solid's button click handler but that's not the point. This is just an example. In the real world, I'm using a keyboard shortcuts library that subscribes to the keydown event.

Possible solutions

• Add an equivalent to React's flushSync() function
• Make batching opt-in instead of opt-out by default. I assume this solution is out of the question because Solid concentrates a lot on performance. I think there might be some discussion at least. In React it seems mandatory because React re-renders entire components but in Solid things are a lot more performent.

Related

3 years ago I logged the same issue for React that contains relevant discussion as well: facebook/react#18402

[ryansolid]

Hmm runWithOwner batches so in a sense you are opting in. I'm more curious about the runWithOwner use. It should be a rare API to use outside of writing your own control flows (like For component). In that example it is doing nothing.

Will keep this in mind though because we will likely be moving towards more things being batched. And on the microtask queue. If flushSync does the trick though we should be fine.

[astoilkov]

From your perspective (as framework author), I understand why batching is the right decision. I just wished I had more control over it as I always optimize my apps when there is a problem not before (Premature optimization is the root of all evil. — Donald Knuth). But doing batching on a microtask level is an improvement because it's more consistent. I'm having a better experience in React 18 because before the behavior was different depending on how I attached an event handler or if the code ran in an effect or not.

Yeah, runWithOwner batches but I wouldn't use it if I knew a better option. Let me explain:

runWithOwner

Let me show you why I need to call runWithOwner.

Here is the abstraction that calls it:

import checkShortcut from 'check-shortcut'
import unwrap, { Wrappable } from '../../packages/unwrap/unwrap'
import { createEffect, getOwner, runWithOwner } from 'solid-js'
import solidAbortSignal from '../solid-abort-signal/solidAbortSignal'

export default function solidShortcut(
  element: Wrappable<HTMLElement | Document | undefined>,
  shortcut: string,
  callback: () => void,
  { capture = false }: { capture?: boolean } = {},
): void {
  createEffect(() => {
    const owner = getOwner()
    const signal = solidAbortSignal()
    unwrap(element)?.addEventListener(
      'keydown',
      (e) => {
        const ke = e as KeyboardEvent
        if (!e.defaultPrevented && checkShortcut(ke, shortcut)) {
          runWithOwner(owner, callback)
          e.preventDefault()
        }
      },
      { signal, capture },
    )
  })
}

Here is how I use abstraction. I understand that I can move the useEditor() call in the Component initialization code. This is just a showcase and not the real-world case. The real-world case is just another abstraction (that doesn't have access to the Component initialization code) where I call useEditor():

function Component() {
  solidShortcut(document.body, 'Enter', () => {
    const editor = useEditor()
    editor.insertTextAtCaret('{selectedItem.text}')
  })
}

I wonder if useContext naming is prepended by use because it's better to follow React's Rules of Hooks. In this case I just shouldn't write this kind of code but also the Solid's ESLint plugin should warn about this.

flushSync

Yes, it would work for me. Do you mean that you are planning to add this in the future?

[ryansolid]

Yes. 2.0 will change the batching considerably. Basically everything will auto-batch. So flushSync will be the way to opt out of it.

And you comment on use is the right way to think about it. Not so much in the like order of hooks, no conditional sense. But that it belongs to the tree. It uses the reactive context. runWithOwner lets it continue, but it was created mostly for hoisting ownership. But people have been using it in this resuming context. To be fair this batching behavior came around largely because of error handling is tied to these run boundaries.

[astoilkov]

Not so much in the like order of hooks, no conditional sense. But that it belongs to the tree.

Understood. Good definition.

But people have been using it in this resuming context.

Yeah, from what I learned here, it feels like a bit of a misuse.

To be fair this batching behavior came around largely because of error handling is tied to these run boundaries.

Hmm, I can't understand this (any resource will be helpful). Isn't performance the main reason for batching?