Building single page Apps with React.js

Building single page Apps with React.js
☞

  • If you have frequently changing state or props that you pass down to a component as spread attributes, you may be unnecessarily re-rendering your component.
  • So something to keep in mind when deciding whether a component needs all the changing props and state it may receive.
  • import ClassNames from ‘classnames’ class Icon extends Component { getClassNames() { return ClassNames([ ‘fa’, {fa-`this.props.name`}, this.props.className ]); } render() { return ( ); } }
  • class Icon extends Component { getClassNames() { let classes = `fa fa-${this.props.name}`; if (this.props.className) { classes += ` ${this.props.className}` } return classes; } render() { return ( ); } }
  • I’m very glad I stumbled upon the concept of container components because I’m positive it saved me from creating some very messy React code.

I thought I would write up a few words on my experience with React so far (about 5 months of the publish date of this post) and some conventions

@javascript_devv: Building single page Apps with React.js

I thought I would write up a few words on my experience with React so far (about 5 months of the publish date of this post) and some conventions I’ve come to rely on to make my workflow faster and more organized. So if you are new to React, hopefully this post will help save you some time.

I’m very glad I stumbled upon the concept of container components because I’m positive it saved me from creating some very messy React code. For those still a bit new to the React game, why React is so great is because we can piece together a view like a set of legos. Once you start to develop reusable components, you realize how awesome this is. But where does the initial data come from? Where do we source our original props that we pass down to these lego pieces? Enter container components.

I won’t go into great detail of what a container component is because this post already does a great job of it, so be sure check it out. As mentioned in that post, the big win with container components is that we separate our data-fetching from our rendering concerns. This allows us to continue on our quest of creating reusable components that don’t need to worry about how to get the data it needs, it just gets it, through props. Reusability!

Classnames is a utility library by Jed Watson (who also has some other excellent projects that I’ve come to rely upon including react-select). After you are past getting your feet wet with React, you’ll eventually come across the not so fun aspect of dealing with what CSS classes you want to include for a given component depending on props and state. Classnames makes this process much cleaner.

Let’s take this simple Icon component that extends font-awesome icons.

Without Classnames we’d need to do something such as:

. Yuck.

Lets use Classnames now:

Much cleaner. This is a simple example, but once you get more than a couple if statements in there, you’ll find classnames really helps keep things concise.

Spread attributes is a React feature that makes it very easy to pass down props or state to child components.

So instead of this:

You can simply do:

Using this spread syntax allows you to easily pass props and state down to child components.

One caveat – since writing this post, I came across an issue when using PureRenderMixin.

From the documentation:

Under the hood, the mixin implements shouldComponentUpdate, in which it compares the current props and state with the next ones and returns false if the equalities pass.

If you have frequently changing state or props that you pass down to a component as spread attributes, you may be unnecessarily re-rendering your component. This recently bit me in a recent project where I was re-rendering a very heavy component that created sluggish re-renderings. So something to keep in mind when deciding whether a component needs all the changing props and state it may receive.

While this is a no-brainer for readability when dealing with deeply nested components, I also like to do this with components that render just one set of tags.

So instead of this:

I choose to do this:

statements on separate lines.

When you reach the render method, it’s easy to pack in a ton of markup and logic, and before you know it, half of your component’s code lives in the render method. Not a huge deal, but it hurts readability. Let’s take a contrived bs example that isn’t very beefy with the markup, but let’s pretend it is:

To help keep things easier to reason about, one approach you can take it to load up a bunch of render methods based on each section of markup. For example:

Now the final render return is very concise and easy to reason about, and all relevant logic and markup is contained within it’s own method.

Building single page Apps with React.js