Open panzerdp opened 4 years ago
Comment written by jahglow on 11/22/2019 18:29:19
Why aren't you wrapping state handlers into a useCallback for memoisation? I know you're showing a simple use cases but in the real world scenarios if you pass the state handlers to child components (as the state is generally lifted to parent component for sibling components' use) they will be rerendered even though closure state variables in your handlers never changed on those renders. All because your handlers are recreated in every render, meaning children receive new props every time. And imagine this happens at the top of your 60 levels down tree. Happy rendering, Karl!
const [bar, setBar]=useState(2)
const [foo, setFoo]=useState(0);
const handleClick = useCallback(()=>{setFoo(foo+bar)},[bar,foo])
Comment written by Dmitri Pavlutin on 11/22/2019 19:03:10
In production, it makes sense to add the optimization you mention.
But for the sake of explanations I always keep the code examples as simple as possible.
Comment written by SG on 12/12/2019 03:48:40
Hi,
On later renderings of the component, getInitialState()
is not invoked, skipping the expensive operation.
What if the bigJSONData that is coming as props is updated and the component that depends on this update needs to be re-rendered? If the getInitialState()
is not invoked, the doesn't it renders the old data, which is wrong I guess?
Comment written by Dmitri Pavlutin on 12/16/2019 07:35:46
Lazy state initialization happens once during initial rendering.
In case if you have expensive computation that depends on a prop, a better option is `useMemo()` hook.
Comment written by sal on 02/19/2020 09:47:06
Hey man, just wanted to say this is one of the best tutorials I found online in many years. even though you're focusing on one state hook (which might be the reason why it's good) you explained it clearly and in details with use cases and code examples... bravo!
Comment written by Dmitri Pavlutin on 02/19/2020 16:02:51
Thanks @disqus_iRZHBfg0SY:disqus! I'm glad you like the guide.
Comment written by Sagar Pawar on 02/20/2020 07:41:07
Instead of using multiple times usestate you can write a object inside useState.
Ex. [state,setState] = useState({
key1:value1,
key2:value2
})
and whenever you want to change the specific object in state you can setState like:
setState({
...state,
key2:value2
})
or you can write a function inside it to get the prevState.
i think this would be better solution for using multiple useState in functional component.
so that you can handle multiple object wisely
Comment written by Dmitri Pavlutin on 02/20/2020 08:00:12
It doesn't make much sense to merge multiple states since it makes difficult to update the state. Imagine updating a state value by invoking the monster `setState({ ...state, key2:value2})` every time.
Make your states decoupled and as independent as possible. Such design opens a window for refactoring (if you'd like to extract the state management into a separated hook), and is easier to update and generally understand.
Moreover, if you find yourself adding multiple `useState()` (usually more than 2), a good idea is to think about refactoring in favor useReducer(), which fits better in managing complex state and state update actions.
Comment written by Sagar Pawar on 02/20/2020 09:22:08
Got it ! Thanks.@rainsoft:disqus
Comment written by wly185 on 04/21/2020 03:31:49
helpful article :)
Comment written by Dmitri Pavlutin on 04/23/2020 14:07:52
Thanks!
Comment written by Pavan Kumar on 07/24/2020 12:32:38
Hi Dmitri Pavlutin, thanks for writing simple and informative blog.
I have one doubt related to refs. You mentioned that
changing the reference doesn’t trigger component re-rendering.
If component is not re-rendered then how updated ref's current property gets reflected on UI. React has changed the DOM node.
Comment written by Dmitri Pavlutin on 07/28/2020 10:58:02
Hi @disqus_g8g4MXMWFk:disqus,
A good practice is to use for rendering the props or state. References are useful for storing side-effects state that should be persisted between re-rendering.
For example, storing the id of a timeout function `setTimeout()` makes sense to do inside of a reference. You use the id stored in the reference to cancel the timeout, however, would not use it to directly to render content.
Comment written by Pavan Kumar on 07/28/2020 12:17:12
Thanks for the reply. @rainsoft:disqus .
Comment written by Александр Малоштан on 09/17/2020 20:53:40
Thanks for the article!
I however don't understand, what
>Multiple useState() calls are correctly invoked in the same order:
means. As opposed to what? There's no counter-example for that point
Comment written by Devon Reid on 09/25/2020 16:59:43
Really good advice thank you
Comment written by Devon Reid on 09/25/2020 17:03:22
Yes I have a few confusion regarding that part as well...
Comment written by Dmitri Pavlutin on 09/26/2020 05:31:30
As opposed to:
function Bulbs({ someBool }) {
let on, setOn, count, setCount;
if (someBool) {
[on, setOn] = useState(false);
[count, setCount] = useState(1);
} else {
[count, setCount] = useState(1);
[on, setOn] = useState(false);
}
//...
}
Hi for you Dmytro! Could you, please, explain the connecting of updating state via useState hook and closures that discussed in this popular StackOverflow post. https://stackoverflow.com/questions/54069253/usestate-set-method-not-reflecting-change-immediately Are they talking about stale state and their effect on re-rendering or something else? Сan't understand the main idea
Great blog about useState() hook
Great blog about useState() hook
Thanks @petranb2!
This article is an incredible reference about useState()
.
Thank you so much for great content. ;)
This article is an incredible reference about
useState()
. Thank you so much for great content. ;)
Thanks @marcelgsantos!
I was a bit confused, why function as useState argument not getting invoked after every re-render. After some tests I found that if you pass a function to useState, React will only call the function when it needs the initial value (which is when the component is initially rendered). Thank you for this post!
Hi @panzerdp. Just an out of the box question, do you have any specific reason for updating the state like this,
setMovies([
...movies.slice(0, index),
...movies.slice(index + 1)
]);
Instead of, doing it like this?
const moviesClone = [...movies]
moviesClone.splice(index, 1)
setMovies(moviesClone)
Thanks.
Hi Dmitri:
Could you make your demos open in the new tab ? That way, we can read the doc and do the demo, then and there.
Thanks. Naras.
Hi Dmitri,
You are an awesome instructor. I am learning so much in web development just by reading your blogs!!!!!
Thank you so much.... And never stop explaining things :)
Hi Dmitri, your article helped me understand and avoid ‘gotchas’ of useState. Thanks, have great day 😃
Hi Dmitri, your article helped me understand and avoid ‘gotchas’ of useState. Thanks, have great day 😃
Thank @antonymott! Have a wonderful day too!
Hi Dmitri,
You are an awesome instructor. I am learning so much in web development just by reading your blogs!!!!!
Thank you so much.... And never stop explaining things :)
Thanks @RamShankarKumar!
Hi @panzerdp. Just an out of the box question, do you have any specific reason for updating the state like this,
setMovies([ ...movies.slice(0, index), ...movies.slice(index + 1) ]);
Instead of, doing it like this?
const moviesClone = [...movies] moviesClone.splice(index, 1) setMovies(moviesClone)
Thanks.
Hi @raghav4!
It's a matter of personal taste. Use the approach you like as long as it doesn't alter the original array.
Written on 11/09/2019 10:58:37
URL: https://dmitripavlutin.com/react-usestate-hook-guide/