While reading Learning React by Alex Banks and Eve Porcello, I came across a very neat method to check if a component is still mounted or not.
Thi...
For further actions, you may consider blocking this person and/or reporting abuse
Not sure how I feel about this, but from my understanding,
useEffectruns the cleanup function before each run of the effect, not just when the component updates. So, passing an empty array to theuseEffectwill make sure it's only set to false on unmount instead of flipping it between renders.I'm wondering why not an empty array too.
I did the same
useMountedRefhook but with an empty array usage and it change not a thing. So yes, I would also prefer that way IMHO.I am quite confused.
I did something like this (but with a local var instead), but I revert my change after finding this official article: reactjs.org/blog/2015/12/16/ismoun...
However, this article is talking about
this.isMountedfrom a component class, not a hook.My question is: Is it the same thing, and in this case also anti-pattern or what is the difference?
Thanks for the article!
See if you are able to cancel the request/promise in the clean up function of
useEffectand check if it was cancelled before updating the state, that is basically the gist of the official React blog in the age of hooks."An optimal solution would be to find places where setState() might be called after a component has unmounted, and fix them."
This article does that exactly.
Any place you feel cancelling the process or request is not an option or too much work you can definitely use this, just a tool in your arsenal.
Though this does a job, but it's still a workaround. I think the preferable way is to try to clean-up any side-effects when component is unmounted. In your example,
setTimeoutfunction actually returns timeout id, that you could use to doclearTimeout(timeoutId)on component unmount.Yeah agreed, but the real deal is that we have a method to check if a component is unmounted, we can use it anywhere we feel the need to have this functionality.
Do you really think it's good to keep fetching data when the user has left the current page? The request should be aborted, not just suppressed.
yep 😅
dev.to/pallymore/clean-up-async-re...
This is a useful article too, thanks for the reference.
Here, the request is being made just one additional time and that too because a user got frustrated(this won't be happening for the majority of time)
Abort Controller isn't even supported by IE11 and I think a wasted API call isn't always as bad as a memory leak.
what is the advantage of using "useRef.current" instead of just creating a variable "var isMounted = false(or true)"
I already answered this in a reply to another comment.
"I follow a general rule of using refs if I don't want to re-render, and using state if I want to re-render. I use local variables only for the derived state(incoming props). Also it was giving me a linting error as local variables value is lost on every re-render(which is fine in this case)."
Why can't we use a plain variable like let isMounted = true and make it false at the unmount function( clean up). Useref is little overhead for this purpose right?
I follow a general rule of using refs if I don't want to re-render, and using state if I want to re-render. I use local variables only for the derived state(incoming props). Also it was giving me a linting error as local variables value is lost on every re-render(which is fine in this case).
This is why I love publishing to dev.to. It actually improves the article.