4

Say I have React component that renders a set of buttons,I store the information for the buttons in an object, with a label and a method to run when they are attached.

The buttons do not need to react to any changes, and will never change themselves.

Is it a bad practice to store the information for these buttons in the state? These are the current solutions I have come up with so far.

1. Storing Buttons in State

class Header extends Component {
  constructor() {
    super();
    this.state = {
      buttons: [
        {
          label: 'Save',
          method: this.save
        },
        {
          label: 'Edit',
          method: this.edit
        }
      ]
    }
  }

  // Class Methods
  // ...
  // End of Class Methods

  render() {
    <ButtonGroup buttons={this.state.buttons} />
  }
}

2. Storing Buttons outside of React's State

class Header extends Component {
  constructor() {
    super();
    this.buttons = [
      {
        label: 'Save',
        method: this.save
      },
      {
        label: 'Edit',
        method: this.edit
      }
    ];
  }

  // Class Methods
  // ...
  // End of Class Methods

  render() {
    <ButtonGroup buttons={this.buttons} />
  }
}

3. Using a Stateless Functional Component (applicable only if no class methods are needed and no other state is used)

function save() {
  ...
}

function edit() {
  ...
}

const buttons = [
  {
    label: 'Save',
    method: save
  },
  {
    label: 'Edit',
    method: edit
  }
];

const Header = () => (<ButtonGroup buttons={buttons} />);

What the question really boils down to is:

  • Is it a bad practice to store data in the state that will not change, and remain constant?
  • Will using state for constants effect performance?
  • Is there a reason to store data that won't change within the state, If I do have state elsewhere, is it easier to just use the state for everything?
tomhughes
  • 4,597
  • 2
  • 24
  • 33
  • https://stackoverflow.com/questions/44684481/is-the-constructor-still-needed-in-react-with-autobinding-and-property-initializ . No need of explicitly defining the constructor when you don't need props to initialize your component – simbathesailor Jan 15 '18 at 10:53
  • 2
    1 and 2 seem identical to me – Chris Jan 15 '18 at 10:56
  • 1
    Props is generally the easier way, in case you want to reuse your component at a later time. If you will always render the same "hardcoded" buttons, then why not simply leave them in the render method? – Icepickle Jan 15 '18 at 10:56
  • @stack26 I was under the impression that without transforming class properties, setting state explictly without defining the constructor will only work in the latest Chrome. – tomhughes Jan 15 '18 at 10:56
  • @Chris Aplogies, cocked up when formatting, replaced it now. – tomhughes Jan 15 '18 at 10:57
  • if Es6 is not supported in your browser, and you are not using babel-transpilers, then you class keyword itself will throw the error. – simbathesailor Jan 15 '18 at 10:58
  • I think the problem is a component with this signature: `` I'd have something more like `` – brub Jan 15 '18 at 11:30

1 Answers1

6

Quick answers to your questions:

Is it a bad practice to store data in the state that will not change, and remain constant?

Somewhat, yes. The state is meant to store the current "state" of your UI. If a specific UI component never changes it doesn't really make sense to talk about "states", because there is only one.

Will using state for constants effect performance?

No.

If there a reason to store data that won't change within the state, If I do have state elsewhere, is it easier to just use the state for everything?

There isn't really, but even if it was considered a valid practice, I would argue that you are sacrificing readability and structure in your code because you wouldn't be distinguishing between the static and dynamic stuff in your UI.

Based on the snippets provided, I would strongly suggest either (2) or (3). I would consider both of these good practices depending on where you want to store the data (within or outside your component) and if flexibility is important.

Chris
  • 57,622
  • 19
  • 111
  • 137