0

I found a similar discussion to my question here but wanted to dig deeper.

I have yet to find any React documentation that discusses whether static variables (that are unchanging but need to be used for a React view) should be stored as a state variable or be rebuilt each time the component is rerendered.

Let's say that I have a React component that takes in a prop, which is a list, and I want to map this list to a certain output. In my use case I am turning the list into the format for the options my component's select picker will use. Once this list is made, it does not need to change. All options will remain the same for the rest of the component's use.

It feels weird to throw it into state, although it just seems more efficient. Let's go through two approaches.

Approach #1: Store option list in component state.

class Component extends React.Component {

    constructor(props) {
       this.state = {
          options: props.list.map(some => computation)
       }
    }

    render() {
        return ( <SelectPicker options={this.state.options} /> )
    }

}

Approach #2: Recreate variable upon each rerender.

class Component extends React.Component {

    constructor(props) {
        ...
    }

    render() {
        const options = this.props.list.map(some => computation)

        return ( <SelectPicker options={options} /> )
    }

}

The latter seems more correct, in that since the options array is never meant to change, it is only meant to be initialized once, and it doesn't make sense to put a watcher on it for being part of state. The former just seems more efficient, as we only compute this value once, rather than recomputing it every single time the component is rerendered. Yes React will compare the state between rerenders, but won't it compare the options list references? Whereas the latter example will completely rebuild a new list? Tbh, neither of these seem like the "clean" approaches to this.

Omar
  • 19
  • 4
  • State is for values that change over time, that cannot be derived from state or props. Therefore option 2 would be the more "React" way of handling it. – Brian Thompson Apr 12 '22 at 13:34
  • The better option is neither. In your constructor function, set `this.options` to the mapped array and then access it with `this.options` in your render method. This avoids creating the same array over and over again. It's perfectly fine to set values on `this.` directly, the point of state is that if a state variable changes the `render` method is called again. – Samathingamajig Apr 12 '22 at 13:39

1 Answers1

2

The better option is neither. In your constructor function, set this.options to the mapped array and then access it with this.options in your render method.

class Component extends React.Component {

    constructor(props) {
       this.options = props.list.map(some => computation);
    }

    render() {
        return ( <SelectPicker options={this.options} /> )
    }

}

This avoids creating the same array over and over again. It's perfectly fine to set values on this. directly, the point of state is that if a state variable changes the render method is called again.

Samathingamajig
  • 11,839
  • 3
  • 12
  • 34
  • Good point! I thought about this but when I read through React practices and documentation, they read that Facebook engineers have never found a reason to use "this" variables in React other than to clear Timeouts for example. I guess I'll just do what works for me and my team though, this seems like a good way to me. – Omar Apr 13 '22 at 15:56