Stateless Components ... how many is too many?

<%= @topic_view.topic.title %>
<%= @topic_view.topic.average_rating %> <%= @topic_view.topic.posts.count { |p| !!p.custom_fields['rating'] } %>

I have a single component, which contains state written like this:

  renderEdit () {
    return(
      <div className="component-daily-workouts workout-main">
        <div className="workout-mode-header">
          <WorkoutHeader
            {...this.props}
            edit={this.state.edit}
          />
        </div>
        <div className="workout-short">
          <strong>{this.props.code}: </strong>{this.props.codeDesc}
          {this.props.descriptionShort}
        </div>
        <div className="workout-long">
          {this.props.descriptionLong}
        </div>
      </div>
    )
  }

Is there any benefit to pulling out certain pieces as stateless components when in my code above they are not written as additional classes but part of an existing stateful class? I’m having trouble refactoring my application to incorporate stateless components and want to make sure I’m not doing it needlessly within existing components with state.

  renderEdit () {
    return(
      <div className="component-daily-workouts workout-main">
        <div className="workout-mode-header">
          <WorkoutHeader
            edit={this.state.edit}
            {...this.props}
          />
        </div>

        <ShortWorkouts
          {...this.props}
        />
        <LongWorkouts
          {...this.props}
        />
       
      </div>
    )
  }

const ShortWorkouts = props => (
  <div className="workout-short">
    <strong>{props.code}: </strong>{props.codeDesc}
    {props.descriptionShort}
  </div>
)

const LongWorkouts = props => (
  <div className="workout-long">
    {props.descriptionLong}
  </div>
)
1 Like

Would need to see more code, its entirely context sensitive. The refactored code looks better, it’s much easier to read, but don’t go nuts and refactor everything down to the smallest atomic piece. Practically, although sometomes the reason for doing it is for performance/code flow reasons, in large part it is to make things more manageable. If you shove everything in one file, it’ll be easier to deal with state in some respects because its global w/r/t the mega component in the file; you don’t have to pass everything around. But it makes it very difficult to edit or refactor.

If you have a react file that’s significantly longer then the height of your screen then there’s often going to be that issue – you need to keep all that state in your head while you write it, which is hard (using classes means there’s a lot more boilerplate, so it’s more common there).

One thing I would definitely say is try not to do this:

{...this.props}

It is occasionally necessary (for example: you have a generic child component you need to pass possibly unknown props through), but otherwise it heavily obfuscates meaning, makes it harder to test, and makes the code very difficult to follow. What you’re doing is explicitly coupling the component to some parent state. It getting close to inheritance (which is something you should not need in React). Prefer something like:

const ShortWorkouts = ({ code, codeDescription, description }) => (
  <div className="workout-short">
    <p><strong>{code}: </strong>{codeDescription}</p>
    <p>{description}</p>
  </div>
);
<ShortWorkouts code={props.code} codeDescription={props.codeDesc} description={props.descriptionShort} />
3 Likes

wow love that perspective, ill see how that goes and post more if i need to later today…actually ill post the whole code, ii took some short cuts here