Yes, made a comment in the vid I forgot to add it! But definitely!!

So true bro....i always try to keep state local so as to prevent the parent from unnecessarily re-rendering and consequently the children. Basically, if its not needed elsewher, keep it local.

​@@miraclenerdkidchiki6249how do you keep it local?

useMemo for expensive computation memo for preventing diffing a lot of markup unnecessarily when parent component re-renders, especially in loops useCallback for avoiding breaking children's memos when you need to pass callbacks to children with good amount of markup The saddest situation is probably when you need to close on some props and state in parent component's "action" callback, and pass that to the mapped children. One of the ways to fix it is this hacky hook: export const useEvent = Any>(cb: T): T => { const ref = useRef({ cb, wrapper: (...args: Any[]) => ref.current.cb(...args), }); useLayoutEffect(() => { ref.current.cb = cb; }); return ref.current.wrapper as T; }; This will have a stable reference and always fresh underlying callback. The only downside is that underlying callback and values it closed on will be one render behind latest if called from `useLayoutEffect` in child components, since child components run their effects first. Something like SolidJS would do granular updates for you, no matter where you put the state, but in react you need to think where to put state and how to split components to keep state-inflicted re-render cheap.

Not if they are send as props, tree it's split then...

in theory yes, but here we're passing state, which doesn't get re-created. Even if state is an object

@@cosdensolutions oh okay thanks sir will keep this in mind , so if it's an object from a parent passed down as a prop , then it would make sense to pass the primitive values I suppose

I also heard of that new upcoming algorithm where React can automatically optimize certain components...but i believe its still in the works and has not been released yet

can you link to that presentation? I've heard about this but never actually seen something concrete

yes it would, the point of useMemo here was to stop userStats from getting re-created if anything else than user changes. Ideally you only want it to change from user, not from anything else that might come up in the component. Usememo fixes that

Absolutely

map over 10k items in an array

that would make no difference in terms of performance here. It would only be better or worse depending on the project and how it's structured!

Accessing properties of an object will always be slower then accessing variables. Objects are also worse for the garbage collector since they have to be allocated and in memory, in edition to the values that they store. But keep in mind these things don't matter unless you have a lot of them, or is accessing them in a very tight loop.

@@Glinkis^

you can measure it manually, or use the react dev tools profiler

I wouldn't worry about that

there is a cost, not 100% sure how deep it is, but it's always better to do things by necessity to avoid any overhead

sure

solidjs

I think worrying about that kind of thing isn't worth it tbh. The idea of this video was how to use useMemo and useCallback properly, because those are bigger issues than the creation of objects and what not

not if it's state

not really, you usually pass objects as props for example if you have a user, or a post, or a comment, etc. It's a very common pattern

@@cosdensolutions you need to check how it is doing the comparison. it is always better to use primitive types than arrays/objects

For a state object it is fine to pass it as dependency as it's easier comparing by reference once instead of comparing each member. If any value changed inside the user state object the reference will change anyways by definition of how react works.

​@@YasinAkimura that maybe true, but a good practice, please dont

that's a fair point. I didn't have the opportunity to re-film this as I left for vacation the day after. For what it's worth, there is a visual comment inside the video saying my mistake, so some people should have seen it. I'll be more careful moving forward. Regardless, the rest of the video still applies and is valid, even with this mistake

Well not basic enough, I had to make the vid because a lot of people understood it wrong!

Quite often it's these "basic" stuff that a lot of us miss.