useMemo has its uses, which the article does a very nice job to explain which ones.
What you suggested is everything you should NOT do with useMemo. There is no point to argue against this, useMemo is only there IF you have performance problems, which is extremely rare and more often a sign of a bad component architecture.
I don't know if you're a native English speaker or not, but the words you use have meanings in the context of React. Unfortunately, because the words you use, you seem to mix concepts together and perpetrate the wrong information as a side effect. Take for example your last comment:
useMemo is a necessity to ensure your state is consistent between renders. It ensures the state of your component only changes when you actually intend for it to change.
I'm sorry to have to point it out, but this is 110% wrong. useMemo has nothing to do with state. state is either coming from a useState, useReducer or an external store. useMemo doesn't come near these concepts at any point.
Some people are mixing the concept of state with props which is NOT the same thing at all, your words seem to point out you're making a similar mistake with useMemo.
The truth is, useMemo doesn't play any role with state. It doesn't ensure your state is consistent between renders and it doesn't ensure the state of your component only changes when you actually intend for it to change. Your state is always consistent and is managed by React. The useMemo command will not affect state and the callback function you pass to it should never modify state otherwise you will have an infinite loop.
The use of useMemo is to encapsulate an expansive function so that if the dependencies don't change, it will bypass the expansive function and return a cached value. That's it! Nothing less, nothing more.
I'm sorry to say but you are 120% wrong about what application state is. Props are just a means of passing state down to child components. useMemo produces state just like useState or useReducer... I'm entirely lost as to why you would want to claim otherwise...
It's the very first time you allude to application state.
As I said, the meaning of words is important and using the right words in the right context is important.
When we're talking about React, using the word state means the actual React state concept; what the lib actually tracks internally as state. For which everything I said is 100% correct.
When we're talking about application state in the greater sense of it, then yes what you said makes a lot more sense. I still feel you're bending way too much what application state technically means, but ultimately, I can understand where you're going with it.
It's important to be precise. You can't expect people to connect a very specific concept in React to a much broader sense of the word without giving the correct context 🤷♂️
State was a concept that existed long before React. The useState hook in itself indicates a point in React where you can manually update the state using the setState method, but that's far from the only place where state gets manipulated in a React app. Because React uses a uni directional data flow, we pass state down through component props, but if you pass props by value (which you do if you dont memoize), React will interpret this as the state for that component having changed, because the diffing that React does, to determine whether it should rerender a particular component only checks for referential equality. That's not a problem if that particular component doesn't do anything interesting, but if there are any side effects in that component, the behaviour of your entire app might start doing really weird things. The biggest problem here is that other devs won't realize that much higher up in the tree something wasn't memoized and that's why they are seeing bugs in the component they just made.
I have no idea why you're trying to explain to me the basics while I'm trying to explain to you the very precise mechanics behind the basics...
Again, your example for the re-rendering has a flaw: props are not state according to how React treat's it. If you had read the article I posted, you'd know a component only re-render if state changes. Pass any object, doesn't have to be a ref, as a prop to a component then change only that prop and React will NOT re-render. This is what I've been pointing out since the start and what you refuse to believe even if I gave your irrefutable proof 🤷♂️
At this point, I guess the Internet strangers will be able to make their mind about what I wrote. Let's just agree to disagree and move on...
No that's not what you have been saying, what you've been saying is that you don't need to memoize values that you pass as props, which is incorrect and leads to many bugs. What you're saying now is that in the particular case where you pass a ref (from useRef hook) through props that it will not cause rerenders, that is exactly my point. A ref is a memoized object (a reference) that you pass to component props, which means the referential equality check will pass and the component will indeed not rerender.
I have been saying 2 things since we started this argument:
The article is right about when to use useMemo
Your definition of state is flawed; You mix props with state concept, you reference application state in the general sense while using the specific React state wording which will cause confusion, etc.
Now you're mixing what memoization actually means... There's a big difference between memoization and how object reference works. If you remove all the details, they look alike but they use very different approach.
In the very broader sense, what you say is fine if you don't fret the details. Simply try to understand why I'm pointing out what you're saying is NOT technically correct?
Props are state... I'm still not sure why you would claim anything else. You've done it over and over again and it is factually wrong. I've tried explaining to you in many different ways how React works and what the word "state" actually means... I am not sure what else to do at this point, except try to stay far away from any code that you write I guess.
Now I think you are being dense on purpose lol @thethirdrace tried to pinpoint the definition of state multiple times, and you are back saying 'props are state'.
Just let it go. You should not mindlessly use useMemo all the time, the same way that in programming you should just not do X 100% of the time. There's no silver bullet, and if you were supposed to always use useMemo don't you think it would say so in the docs? The docs only explain useMemo as an optimization tool, just like this article describes.
What the docs fail to point out though is that you dont know. You dont know if you or someone else is going to use that piece of unmemoized state weeks/months later in another component as a dependency of a hook, or more specifically in a useEffect hook.
This is not a theoretical discussion. Its a very real problem that causes bugs in React code right at this very moment. So yes, after 4 years of React hooks and seeing that this is the cause for 9/10 bugs in React code. I am absolutely convinced that leaving dirty/unmemoized state inside a component should very much be considered a bad practice.
If you can avoid creating bugs in the future, why would you refuse to do it out of some kind of weird conviction? Is it really too much effort to just type:
functionSomeComponent({name}:{name:string}){constmemoizedState=useMemo(()=>({foo:`Yay ${name} wont create bugs!`}),[name])return<>Do whatever you like with memoizedState</>}
vs
functionSomeComponent({name}:{name:string}){constdirtyState={foo:`Screw every developer that comes after ${name}`}return<>Better hope nobody passes that dirty state here in the future</>}
Is it hurting you in any way? Because it is hurting me, that I have to keep fixing these kinds of easily avoidable bugs.
I read the link and nothing in that section goes beyond an example of how you could memoize the dependency of a hook. It is not mentioned in this section why you'd want to do that, just how to do it if you need it.
But if you zoom out your focus and read the whole page, the usage section mentions the biggest case: skipping expansive recalculations.
And we're commenting here on dev.to on an article that points exactly at this.
Re-rendering is not a problem unless there's an actual noticeable performance problem. Re-rendering is not a bug.
See this excellent article that explains why you should fix the slow render before thinking about fixing re-rendering: kentcdodds.com/blog/fix-the-slow-r...
I've linked a few sources in this post and the previous ones. You simply refuse to read them and point out to a section of the official documentation that doesn't say what you say it does 🤷♂️
Memoization has a cost. It's just a matter of applying it when the cost is less than not using it. It makes total sense, why would you make your app slower and eat memory like crazy if you can avoid it? 🤔
So to answer the question in your previous post is: Yes, it's hurting me, and everyone, to use memoization where it's unnecessary.
Unless there's a real measurable performance problem, what you see as a bug is not a bug.
And I say this as a performance freak. I'm the guy that bothers everyone at work non-stop about performance. I rarely use memoization because we simply rarely need it. I architect the application state, yes I consciously mean application state here, in a way as to not cause those problems. I'm very sorry you have to deal with those kinds of bugs. The solution is a better architecture, not a slower and memory hungry app/site.
Nadia Makarevich argument is: if you have atleast one piece of dirty state in your component, go ahead and create more dirty state... What kind of attitude is that? Her example is dirty:
functionDirtyComponent(){return<OtherComponentsomeProp={[1,2,3]}/>// someProp will always contain a new value}
It's easily fixable, do this instead:
constneverChangingArray=[1,2,3]// <-- this is still application statefunctionCleanComponent(){return<OtherComponentsomeProp={neverChangingArray}/>}
Or if you need other state, memoize:
functionCleanComponent({someItem}:{someItem:string}){// someItem is application state, passed down via propsconstnoChangeBetweenRenders=useMemo(()=>[1,2,someItem],[someItem])return<OtherComponentsomeProp={noChangeBetweenRenders}/>}
If you dont and OtherComponent has a useEffect (literally any side effect) that depends on your dirty state, you just screwed someone in the future:
functionOtherComponent({items}:{items:string[]}){// items is applications state, passed down via propsuseEffect(()=>{// trigger any side effect when items changefetch('/my/api').then(()=>{// in reality always executes on every render because items always change.})},[items])return<>foobar</>}
This is a simple example, in reality the dirty state that you produce gets passed down through many levels of the component tree until nobody knows what is dirty and what is clean. Pretty sure that Kent C. Dodds and hopefully also Nadia Makarevich have realized this by now and changed their ways.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
useMemo
has its uses, which the article does a very nice job to explain which ones.What you suggested is everything you should NOT do with
useMemo
. There is no point to argue against this,useMemo
is only thereIF
you have performance problems, which is extremely rare and more often a sign of a bad component architecture.I don't know if you're a native English speaker or not, but the words you use have meanings in the context of React. Unfortunately, because the words you use, you seem to mix concepts together and perpetrate the wrong information as a side effect. Take for example your last comment:
I'm sorry to have to point it out, but this is 110% wrong.
useMemo
has nothing to do withstate
.state
is either coming from auseState
,useReducer
or an external store.useMemo
doesn't come near these concepts at any point.Some people are mixing the concept of
state
withprops
which isNOT
the same thing at all, your words seem to point out you're making a similar mistake withuseMemo
.The truth is,
useMemo
doesn't play any role withstate
. It doesn't ensure yourstate
is consistent between renders and it doesn't ensure thestate
of your component only changes when you actually intend for it to change. Yourstate
is always consistent and is managed by React. TheuseMemo
command will not affectstate
and the callback function you pass to it should never modifystate
otherwise you will have an infinite loop.The use of
useMemo
is to encapsulate an expansive function so that if the dependencies don't change, it will bypass the expansive function and return a cached value. That's it! Nothing less, nothing more.I'm sorry to say but you are 120% wrong about what application state is. Props are just a means of passing state down to child components. useMemo produces state just like useState or useReducer... I'm entirely lost as to why you would want to claim otherwise...
It's the very first time you allude to
application state
.As I said, the meaning of words is important and using the right words in the right context is important.
When we're talking about React, using the word
state
means the actualReact state
concept; what the lib actually tracks internally asstate
. For which everything I said is 100% correct.When we're talking about
application state
in the greater sense of it, then yes what you said makes a lot more sense. I still feel you're bending way too much whatapplication state
technically means, but ultimately, I can understand where you're going with it.It's important to be precise. You can't expect people to connect a very specific concept in React to a much broader sense of the word without giving the correct context 🤷♂️
State was a concept that existed long before React. The useState hook in itself indicates a point in React where you can manually update the state using the setState method, but that's far from the only place where state gets manipulated in a React app. Because React uses a uni directional data flow, we pass state down through component props, but if you pass props by value (which you do if you dont memoize), React will interpret this as the state for that component having changed, because the diffing that React does, to determine whether it should rerender a particular component only checks for referential equality. That's not a problem if that particular component doesn't do anything interesting, but if there are any side effects in that component, the behaviour of your entire app might start doing really weird things. The biggest problem here is that other devs won't realize that much higher up in the tree something wasn't memoized and that's why they are seeing bugs in the component they just made.
I have no idea why you're trying to explain to me the basics while I'm trying to explain to you the very precise mechanics behind the basics...
Again, your example for the re-rendering has a flaw: props are not
state
according to how React treat's it. If you had read the article I posted, you'd know a component only re-render ifstate
changes. Pass any object, doesn't have to be aref
, as a prop to a component then change only that prop and React will NOT re-render. This is what I've been pointing out since the start and what you refuse to believe even if I gave your irrefutable proof 🤷♂️At this point, I guess the Internet strangers will be able to make their mind about what I wrote. Let's just agree to disagree and move on...
No that's not what you have been saying, what you've been saying is that you don't need to memoize values that you pass as props, which is incorrect and leads to many bugs. What you're saying now is that in the particular case where you pass a ref (from useRef hook) through props that it will not cause rerenders, that is exactly my point. A ref is a memoized object (a reference) that you pass to component props, which means the referential equality check will pass and the component will indeed not rerender.
I have been saying 2 things since we started this argument:
useMemo
state
is flawed; You mix props withstate
concept, you referenceapplication state
in the general sense while using the specific Reactstate
wording which will cause confusion, etc.Now you're mixing what
memoization
actually means... There's a big difference betweenmemoization
and how object reference works. If you remove all the details, they look alike but they use very different approach.In the very broader sense, what you say is fine if you don't fret the details. Simply try to understand why I'm pointing out what you're saying is NOT technically correct?
Props are state... I'm still not sure why you would claim anything else. You've done it over and over again and it is factually wrong. I've tried explaining to you in many different ways how React works and what the word "state" actually means... I am not sure what else to do at this point, except try to stay far away from any code that you write I guess.
Now I think you are being dense on purpose lol @thethirdrace tried to pinpoint the definition of state multiple times, and you are back saying 'props are state'.
Just let it go. You should not mindlessly use
useMemo
all the time, the same way that in programming you should just not do X 100% of the time. There's no silver bullet, and if you were supposed to always useuseMemo
don't you think it would say so in the docs? The docs only explainuseMemo
as an optimization tool, just like this article describes.Actually it is mentioned in the docs react.dev/reference/react/useMemo#...
What the docs fail to point out though is that you dont know. You dont know if you or someone else is going to use that piece of unmemoized state weeks/months later in another component as a dependency of a hook, or more specifically in a
useEffect
hook.This is not a theoretical discussion. Its a very real problem that causes bugs in React code right at this very moment. So yes, after 4 years of React hooks and seeing that this is the cause for 9/10 bugs in React code. I am absolutely convinced that leaving dirty/unmemoized state inside a component should very much be considered a bad practice.
If you can avoid creating bugs in the future, why would you refuse to do it out of some kind of weird conviction? Is it really too much effort to just type:
vs
Is it hurting you in any way? Because it is hurting me, that I have to keep fixing these kinds of easily avoidable bugs.
I read the link and nothing in that section goes beyond an example of how you could memoize the dependency of a hook. It is not mentioned in this section why you'd want to do that, just how to do it if you need it.
But if you zoom out your focus and read the whole page, the
usage
section mentions the biggest case: skipping expansive recalculations.And we're commenting here on dev.to on an article that points exactly at this.
Re-rendering is not a problem unless there's an actual noticeable performance problem. Re-rendering is not a bug.
See this excellent article that explains why you should fix the slow render before thinking about fixing re-rendering: kentcdodds.com/blog/fix-the-slow-r...
Also, the following article explains the cost of memoizing everything: kentcdodds.com/blog/usememo-and-us...
Both articles are written by Kent C. Dodds, author of Testing Library and an absolute beast of a teacher.
Also Nadia Makarevich has pretty awesome articles herself. You should read these 2:
I've linked a few sources in this post and the previous ones. You simply refuse to read them and point out to a section of the official documentation that doesn't say what you say it does 🤷♂️
Memoization has a cost. It's just a matter of applying it when the cost is less than not using it. It makes total sense, why would you make your app slower and eat memory like crazy if you can avoid it? 🤔
So to answer the question in your previous post is: Yes, it's hurting me, and everyone, to use memoization where it's unnecessary.
Unless there's a real measurable performance problem, what you see as a bug is not a bug.
And I say this as a performance freak. I'm the guy that bothers everyone at work non-stop about performance. I rarely use memoization because we simply rarely need it. I architect the
application state
, yes I consciously meanapplication state
here, in a way as to not cause those problems. I'm very sorry you have to deal with those kinds of bugs. The solution is a better architecture, not a slower and memory hungry app/site.Memoization has nothing to do with increased memory usage 🤦
Nadia Makarevich argument is: if you have atleast one piece of dirty state in your component, go ahead and create more dirty state... What kind of attitude is that? Her example is dirty:
It's easily fixable, do this instead:
Or if you need other state, memoize:
If you dont and
OtherComponent
has auseEffect
(literally any side effect) that depends on your dirty state, you just screwed someone in the future:This is a simple example, in reality the dirty state that you produce gets passed down through many levels of the component tree until nobody knows what is dirty and what is clean. Pretty sure that Kent C. Dodds and hopefully also Nadia Makarevich have realized this by now and changed their ways.