React 18 useTransition Hook Crash Course 

Yes I was thinking it should be called useLowPriority or useDeferredPriority or useInterruptable

Ikr even the startTransition doesn't make a lot of sense to me. I would've preferred a name like lowPriority or something

I thought transitions were about those ordinary transitions with ease, ease out, ease in out 😂

This! Although refactoring might break a lot now. But it is really bad especially for beginners but also for developers that don't develop React all the time but come back to it for a new need once in a while.

Tell me about it. You could never tell by the hook's name that that is what it does.

my favourite hook useTraction

@@codesymphony your comment made me laugh thanks lol

@@Linuslkm lol yeah 😂

But only if you use isPending in your JSX, not?

It changes the state of pending but it still does so in the same render it changes the state of the array So it does all that in 1 render

@@bigti1199 6:50 - startTransition runs asynchronously (i'm talking about updating the state). It doesn't matter in terms of performance because of the amount of resources that useTransition saves makes it all worthwhile. But it does render three times. Here's why: Without startTransition, it will do *synchronously* (although your computer will be really suffering for 3 seconds) one update (setInput() and setList()). With startTransition, it does it three times: - setInput - (setTransition gets delayed) -> sets `isPending` to true. - (setTransition code runs) -> setList - setTransition Ends, and when it ends (because it doesn't know what happens inside of it) sets `isPending` to false. Since this is an asynchronous operation, it cannot change `isPending` to false on the same rerender as `setList(l)`. The last point, which is the one i was referring to, is due to a state being updated inside of startTransition. This is something that Facebook knows, and they have a warning in case they detect multiple re-renders while running the code. "'Otherwise concurrent mode guarantees are off the table.'" Feel free to check the ReactStartTransition.js file of the source code :)

Thank you so much for the support!

How is this handled in Svelte?

^

I mean I did this in svelte and it was sluggish so what are you talking about? let val = ""; let list = []; const LIST_SIZE = 20000; const updateList = (val) => { list = [] for (let i = 0; i < LIST_SIZE; i++) { list = [...list, val] } } $: updateList(val) {#each list as item, idx (idx)} {item} {/each}

Update: Added debouncing and works much better: let val = ""; let list = []; const LIST_SIZE = 20000; const debounce = (func, time = 1000) => { let timeoutId = null; return (...args) => { if (timeoutId) { console.log(`Cleared timeout with id: ${timeoutId}`) clearTimeout(timeoutId); } timeoutId = setTimeout(() => { console.log(`Called timeout callback with id: ${timeoutId}`) func(...args) }, time) } } const updateList = debounce((val) => { list = [] if (!val) return; for (let i = 0; i < LIST_SIZE; i++) { list = [...list, val] } }); $: updateList(val) {#each list as item, idx (idx)} {item} {/each}

usedeferredvalue is also a new hook which can solve that problem

You could probably set it back with a useEffect hook using a setTimeout that waits for the user to stop typing in order to actually set the new state

better use timeout, with 0.5 sec after input. if user types again before 0.5sec, reset the timeout.

React 18 updates are useTransition hook that you already saw which is a concurrent mode feature that React team has been working on for years. And another update is useId hook that you can generally use to generate unique ids in your application

same question, since both of these will be used on maybe the same use cases

I think it's fairly easy to check. Console log max index of each iteration. If the index same for each iteration (equal to items count) then it's not cancelled.

That's the debounce functionality. You have to do implement that yourself.

Yes, it does run every time. If you have, let's say, a search input and want to avoid making a request for every character, then you should implement a Debounce().

Yes. However, if you’re using lodash, there’s a useDebounce hook included that can alleviate this issue. If not, implementing it isn’t hard: function useDebounce(value, delay) { const [debouncedValue, setDebouncedValue] = useState(value); useEffect( () => { const handler = setTimeout(() => { setDebouncedValue(value); }, delay); return () => { clearTimeout(handler); }; }, [value, delay] ); return debouncedValue; };