13

In a component that does not override shouldComponentUpdate, is there any difference between forceUpdate and setState?

Update: I already know what the docs say and that forceUpdate is not the recommended way to do it. I am just trying to gain a deeper understanding of what is going on. I'd like to know why? And I already know that setState merges the passed object (state "delta" - kind of like an sql update) with the current state object.

Suppose a simple use-case: no need for undo or time-travel functionality. No need to do pointer comparison inside shouldComponentUpdate. In fact, no need to use shouldComponentUpdate at all.

In that case, it appears to me, that mutating state and calling forceUpdate() is a perfectly valid way to use React. From a black box perspective, these two techniques appear to have the exact same effect:

Technique #1: this.state.x = 10; this.forceUpdate();

Technique #2: this.state.setState({x:10});

Again, I already know that some people prefer to never mutate state. And to use the functional programming style. I was just wondering if there is any technical reason to avoid Technique #1. Or am I missing something?

Dave Ford
  • 1,956
  • 5
  • 19
  • 25
  • 1
    there is no similarity between these two, they are totally difference, setState is used to update the state variables and then react triggers the re-rendering and by forceUpdate() we can tell React that the component needs re-rendering. check this:http://stackoverflow.com/questions/35284105/forceupdate-vs-this-setstate-with-a-callback – Mayank Shukla May 08 '17 at 07:27
  • There are certain disadvantages of using technique 1: You can check this on https://stackoverflow.com/questions/47237556/react-what-are-disadvantages-of-completely-replacing-setstate-with-direct-thi/47237601#47237601 – Shubham Khatri Jan 21 '18 at 16:35

3 Answers3

30

General about setState()

The setState() function is typically used to update the component state with one or more new state properties. This is the typical way of mutating your state and managing view updates.

From the official docs:

setState() enqueues changes to the component state and tells React that this component and its children need to be re-rendered with the updated state. This is the primary method you use to update the user interface in response to event handlers and server responses.

General about forceUpdate()

The forceUpdate() function is just a way to force a re-render of the component and its children in question. It does not mutate the state at all.

You should avoid to use this function, when possible, as it deviates from the React mindset where your state and props are solely responsible for keeping your application logic up-to-date with your view.

From the official docs:

By default, when your component's state or props change, your component will re-render. If your render() method depends on some other data, you can tell React that the component needs re-rendering by calling forceUpdate().

Normally you should try to avoid all uses of forceUpdate() and only read from this.props and this.state in render().

The differences

It's important to note that forceUpdate() will skip checking the logic in shouldComponentUpdate() (if you have any), where as setState() does not skip it.

An interesting note here is that the following 2 lines will always yield the same results:

this.setState(this.state);
this.forceUpdate();

...unless shouldComponentUpdate() can return false as explained above.

Other than the above, there is no functional difference between the two.

Chris
  • 57,622
  • 19
  • 111
  • 137
  • How's about performance? Basically, if a child component has new state, it rerender again? – TomSawyer Sep 01 '17 at 17:44
  • 4
    @TomSawyer, Strictly speaking performance, `forceUpdate()` would probably be faster because it skips running `shouldComponentUpdate()`. As as I explained above. It will trigger the render of all child components, yes. That said, please do use `setState()`. – Chris Sep 01 '17 at 18:00
1

In the book FullStack React, there is a chapter that makes a basic Timer application. In this chapter they use forceUpdate() to re-render the UI with the following explanation:

“You might ask: Wouldn’t it be more efficient if we did not continuously call forceUpdate() on timers that are not running? Indeed, we would save a few cycles. But it would not be worth the added code complexity. React will call render() which performs some inexpensive operations in JavaScript. It will then compare this result to the previous call to render() and see that nothing has changed. It stops there — it won’t attempt any DOM manipulation.” Excerpt From: Anthony Accomazzo, Ari Lerner, David Guttman, Nate Murray, Clay Allsopp and Tyler McGinnis. “Fullstack React.” iBooks.

I take that to mean that if it's feasible to use setState then you should for absolute maximum performance, but if the operation in question is not expensive and will save you from a lot of code complexity then it might be okay to use forceUpdate() to re-render the UI. That is of course my interpretation, you should probably read through this book to get more context from it and perhaps it will help you make up your own mind.

brff19
  • 760
  • 1
  • 8
  • 21
-1

Flutter is a framework that is based the React architecture.

I think this Flutter blog post actually gives the best answer to this question:

Avoiding Empty State Callbacks

Note: Flutter's "empty setState call" is roughly analogous to React's forceUpdate.

Dave Ford
  • 1,956
  • 5
  • 19
  • 25