Actually I would just debounce it and add a spinner. No need to shoehorn additional operations in between, which are going be outdated in a split second anyway.
So it just depends on how much you care about UX. And consider my markdown preview example where UI lock on every Nth keypress is hardly better than every keypress.
If you don't care, then why bother with auto-updating on keypress at all? Just wait for user to press enter. Much less jarring for the user than a shoddy half-solution.
No, it means it happens only after the user stopped typing for a while - a very different experience.
If you don't care, then why bother with auto-updating on keypress at all? Just wait for user to press enter.
Doesn't cover all the cases and you have to update eventually - after the first debounced event goes through is a good moment.
Internally, React manages a list of updates. Whenever you trigger one, it will be added to the list but the next re-render will only start after the previous one has finished (this is of course a simplified explanation but you get the idea).
This batching gives us the best of both worlds: We start rendering as soon as we have data and don’t have “idle” time in which the UI is unresponsive (like a long debounce function) but we still batch all updates between the different renderings so that we can skip individual updates to save time.
Because now I see mostly the cost of having pieces of the render function shoehorned between input events just so that they can be discarded, because once the render function finishes it's grossly outdated.
There is also the other problem with debounce that was pointed out earlier: The main thread _will be blocked_ when a long running tasks is executed, no matter _when_. You mentioned that the block would happen _after_ the user type in so it would be less noticeable but this is only an approximation. If you have animations on your website that use rAF, the block will still be very visible. Also if the user continues to type.
That said, I know that this is a contrived example and it might not be used as-such in a real world application. I also think it's not comparable to your auto-saving input example that would maybe be better off with using a debounce call. I'm sure that better examples for this use case will follow.
Edit: I can recommend Dan's talk at JSConf Iceland last year. He speaks about debounce as well: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...