Home » Reactjs » Can you force a React component to rerender without calling setState?

Can you force a React component to rerender without calling setState?

Posted by: admin November 29, 2017 Leave a comment

Questions:

I have an external (to the component), observable object that I want to listen for changes on. When the object is updated it emits change events, and then I want to rerender the component when any change is detected.

With a top-level React.render this has been possible, but within a component it doesn’t work (which makes some sense since the render method just returns an object).

Here’s a code example:

export default class MyComponent extends React.Component {

  handleButtonClick() {
    this.render();
  }

  render() {
    return (
      <div>
        {Math.random()}
        <button onClick={this.handleButtonClick.bind(this)}>
          Click me
        </button>
      </div>
    )
  }
}

Clicking the button internally calls this.render(), but that’s not what actually causes the rendering to happen (you can see this in action because the text created by {Math.random()} doesn’t change). However, if I simply call this.setState() instead of this.render(), it works fine.

So I guess my question is: do React components need to have state in order to rerender? Is there a way to force the component to update on demand without changing the state?

Answers:

In your component, you can call this.forceUpdate() to force a rerender.

Documentation: https://facebook.github.io/react/docs/component-api.html

Questions:
Answers:

forceUpdate should be avoided because it deviates from a React mindset. The React docs cite an example of when forceUpdate might be used:

By default, when your component’s state or props change, your component will re-render. However, if these change implicitly (eg: data deep within an object changes without changing the object itself) or if your render() method depends on some other data, you can tell React that it needs to re-run render() by calling forceUpdate().

However, I’d like to propose the idea that even with deeply nested objects, forceUpdate is unnecessary. By using an immutable data source tracking changes becomes cheap; a change will always result in a new object so we only need to check if the reference to the object has changed. You can use the library Immutable JS to implement immutable data objects into your app.

Normally you should try to avoid all uses of forceUpdate() and only read from this.props and this.state in render(). This makes your component “pure” and your application much simpler and more efficient. https://facebook.github.io/react/docs/component-api.html#forceupdate

Changing the key of the element you want re-rendered will work. Set the key prop on your element via state and then when you want to update set state to have a new key.

<Element key={this.state.key} /> 

Then a change occurs and you reset the key

this.setState({ key: Math.random() });

I want to note that this will replace the element that the key is changing on. An example of where this could be useful is when you have a file input field that you would like to reset after an image upload.

While the true answer to the OP’s question would be forceUpdate() I have found this solution helpful in different situations. I also want to note that if you find yourself using forceUpdate you may want to review your code and see if there is another way to do things.

Questions:
Answers:

Actually, forceUpdate() is the only correct solution as setState() might not trigger a re-render if additional logic is implemented in shouldComponentUpdate() or when it simply returns false.

forceUpdate()

Calling forceUpdate() will cause render() to be called on the component, skipping shouldComponentUpdate(). more…

setState()

setState() will always trigger a re-render unless conditional rendering logic is implemented in shouldComponentUpdate(). more…


forceUpdate() can be called from within your component by this.forceUpdate()

Questions:
Answers:

When you want two React components to communicate, which are not bound by a relationship (parent-child), it is advisable to use Flux or similar architectures.

What you want to do is to listen for changes of the observable component store, which holds the model and its interface, and saving the data that causes the render to change as state in MyComponent. When the store pushes the new data, you change the state of your component, which automatically triggers the render.

Normally you should try to avoid using forceUpdate() . From the documentation:

Normally you should try to avoid all uses of forceUpdate() and only read from this.props and this.state in render(). This makes your application much simpler and more efficient

Questions:
Answers:

So I guess my question is: do React components need to have state in
order to rerender? Is there a way to force the component to update on
demand without changing the state?

The other answers have tried to illustrate how you could, but the point is that you shouldn’t. Even the hacky solution of changing the key misses the point. The power of React is giving up control of manually managing when something should render, and instead just concerning yourself with how something should map on inputs. Then supply stream of inputs.

If you need to manually force re-render, you’re almost certainly not doing something right.

Questions:
Answers:

I Avoided forceUpdate by doing following

WRONG WAY : do not use index as key

 this.state.rows.map((item, index) =>
                        <MyComponent cell={item} key={index} />
                    )

CORRECT WAY : Use data id as key .it can be some guid etc

 this.state.rows.map((item, index) =>
                        <MyComponent item={item} key={item.id} />
                    )

so by doing such code improvement your component will be UNIQUE and render naturally

Questions:
Answers:

You could do it a couple of ways:

1. Use the forceUpdate() method:

There are some glitches that may happen when using the forceUpdate() method. One example is that it ignores the shouldComponentUpdate() method and will re-render the view regardless of whether shouldComponentUpdate() returns false. Because of this using forceUpdate() should be avoided when at all possible.

2. Passing this.state to the setState() method

The following line of code overcomes the problem with the previous example:

this.setState(this.state);

Really all this is doing is overwriting the current state with the current state which triggers a re-rendering. This still isn’t necessarily the best way to do things, but it does overcome some of the glitches you might encounter using the forceUpdate() method.

Questions:
Answers:

No state worries to re-render

I was storing my data in state a lot when I started using react thinking I had to do this for rendering. That was very wrong. Turns out, you can even avoid doing complicated things like Flux and Redux too if you roll some simple immutable stores.

BaseView class to inherit from and handle store updates

import React, { Component } from 'react';
import { View } from 'react-native';

export default class BaseView extends Component {

  constructor(props) {
    super(props)
    this.state = {}
  }

  onChange = () => {
    this.setState(this.state) // dumb easy: triggers render
  }

  componentWillMount = () => {
    this.stores && this.stores.forEach(store => {
      // each store has a common change event to subscribe to
      store.on('change', this.onChange)
    })
  }

  componentWillUnmount = () => {
    this.stores && this.stores.forEach(store => {
      store.off('change', this.onChange)
    })
  }

}

How to use

import React, { Component } from 'react'
import { View, Text } from 'react-native'
import BaseView from './BaseView'
import myStore from './myStore'

class MyView extends BaseView {
  contructor(props) {
    super(props)
    this.stores = [myStore]
  }

  render() {
    return (<View><Text onPress={() => {
      myStore.update({ message: 'hi' + Date.now() })
    }}>{myStore.get().message}</Text></View>)
  }
}

Simple Store class example

var ee = require('event-emitter')
export default class Store {
  constructor() {
    this._data = {}
    this._eventEmitter = ee({})
  }
  get() {
    return {...this._data} // immutable
  }
  update(newData) {
    this._data = {..._this.data, ...newData}
    this._eventEmitter.emit('change')
  }
  on(ev, fn) {
    this._eventEmitter.on(ev, fn)
  }
  off(ev, fn) {
    this._eventEmitter.off(ev, fn)
  }
}

Store instance as singleton

import Store from './Store'

const myStore = new Store()
export default myStore

I think this does away with all the crufty frameworks needed for smaller apps where you don’t care about all the plumbing so much but I’ve also used this approach as apps have grown and so far so good.

You could easily build this out for ListStore where its an array. You can use immutable concepts for those as well, easy peasy.

Leave a Reply

Your email address will not be published. Required fields are marked *