Thats actually bad but not too bad cause you are not mutationg dom tree. Assume you are mutating dom tree in setimeout then it would have became worst.
Also settimeout is not guaranteed to run exactly after 100ms it may drift all the way beyond 300ms mark (minimal threshhold to show feedback to user of their action) which would irritate user. Try putting a long empty loop after setTimeout and you can see that happening.
I don't see a reason why you would want to use setTimeout, this clearly a side effect and there are better options to handle side effects in React.
And also how would you know what the exact timeout value should be? Let's say if you choose 100ms (as mentioned in your example) and React does all the state update in 5ms, then the user of your app has to wait for 95ms (which is unnecessary) and suppose React takes 200ms then the whole purpose of using setTimeout gets nullified.
I've also elaborated the "Using effect hook" section, you might want to give it a read again.
Ok Bro, Why so serious. I'm a beginner! I just asked a doubt there!!
Thanks for your response though!
One more doubt I've got here, Can we use async on functoin and await on the setTimeout(()=> { listRef.current.scrollTop = listRef.current.scrollHeight;
}, 100)
line?
Would that work? If yes, is this considered a bad practice?
No no, you got me wrong, I didn't mean to be rude, I was just trying to answer your question.
Event handlers can be async functions, no problem in that, but setTimeout doesn't return a promise so there's no point of using an await with it (setTimeout returns the timer ID which you can use to clear the timeout).
Why dont you just use
setTimeout(()=> { listRef.current.scrollTop = listRef.current.scrollHeight;}, 100)
Is this bad or any complications involved?
Thats actually bad but not too bad cause you are not mutationg dom tree. Assume you are mutating dom tree in setimeout then it would have became worst.
Also settimeout is not guaranteed to run exactly after 100ms it may drift all the way beyond 300ms mark (minimal threshhold to show feedback to user of their action) which would irritate user. Try putting a long empty loop after setTimeout and you can see that happening.
I don't see a reason why you would want to use
setTimeout, this clearly a side effect and there are better options to handle side effects in React.And also how would you know what the exact timeout value should be? Let's say if you choose
100ms(as mentioned in your example) and React does all the state update in5ms, then the user of your app has to wait for95ms(which is unnecessary) and suppose React takes200msthen the whole purpose of usingsetTimeoutgets nullified.I've also elaborated the "Using
effecthook" section, you might want to give it a read again.Ok Bro, Why so serious. I'm a beginner! I just asked a doubt there!!
Thanks for your response though!
One more doubt I've got here, Can we use async on functoin and await on the
setTimeout(()=> { listRef.current.scrollTop = listRef.current.scrollHeight;}, 100)
line?
Would that work? If yes, is this considered a bad practice?
No no, you got me wrong, I didn't mean to be rude, I was just trying to answer your question.
Event handlers can be
asyncfunctions, no problem in that, butsetTimeoutdoesn't return a promise so there's no point of using anawaitwith it (setTimeoutreturns the timer ID which you can use to clear the timeout).Example below shows an
asynchandler:No, I meant is it ok to have the code like this :
const onAdd = async (newTask) => {
await setTodos([...todos, { id: uuid(), task: newTask }]);
listRef.current.scrollTop = listRef.current.scrollHeight;
};
then the scrolling will wait till the settodo is done rght? or am I wrong?