DEV Community

Cover image for React hooks: get the current state, back to the future

React hooks: get the current state, back to the future

Sebastien Castiel on February 19, 2019

This article is not recent, but still relevant! And I still often see developers having trouble with this concern. I talk about this topic and a lo...
Read full post
Collapse
 
dan_abramov profile image
Dan Abramov •

So this might seem unexpected in this case. But let's consider an equivalent case that looks a bit more concrete than a counter.

handleFollowClick() {
  setTimeout(() => {
    alert('Followed: ' + this.props.user.name);
  }, 5000)
}
Enter fullscreen mode Exit fullscreen mode

Do you see the bug in this code? If the user prop changes before the timeout finishes (e.g. because you navigated to a different profile), you would "follow" the wrong person!

How would you fix it? With a class, one way to fix it is to destructure early:

handleFollowClick() {
  const {user} = this.props;
  setTimeout(() => {
    alert('Followed: ' + user.name);
  }, 5000)
}
Enter fullscreen mode Exit fullscreen mode

Many people wouldn't notice the difference, but this code takes care to remember which user you referred to at the time of the click.

So how does this relate to Hooks? With Hooks, the code behaves like the second snippet by default. You always get the values in the event handlers that were actually rendered.

function handleFollowClick() {
  // There is no "this", the "user" is always
  // the one corresponding to this event handler.
  setTimeout(() => {
    alert('Followed: ' + user.name);
  }, 5000)
}
Enter fullscreen mode Exit fullscreen mode

As you described, a ref is a way to "escape" that snapshot time in time and peek into the future. In many cases you don't want it; but it's there for when you need it. It takes time to adjust to a new default though.

Collapse
 
scastiel profile image
Sebastien Castiel •

Thanks Dan, it kind of confirms (and explains very well) what I suspected 🙂

Collapse
 
dan_abramov profile image
Dan Abramov •

I wrote up a more detailed explanation. overreacted.io/how-are-function-co...

Collapse
 
dance2die profile image
Sung M. Kim •

Great post, Sébastien~

The problem statement & the steps to get the "current" prop (not the closed prop) was fun to read 🙂

In case anyone wants a runnable code, here it is.

Collapse
 
stavares profile image
Scott C Tavares •

I have been writing OO code in Java for nearly three decades, I have been writing functional code for about three months now so excuse me if this sounds like I'm just ignorant of a few things. My first question is, isn't it functional programming's goal to not maintain state information between method calls? Second is, if you combine this with TypeScript, don't you now just have plain ol' Java again?