React Components: A Template

Colin Standefer
Frontend Weekly
Published in
4 min readAug 7, 2016

I started studying React a few weeks ago and even built with a team an app solely with React called Loqal, which can be seen here: http://loqal.herokuapp.com/

While I haven’t mastered it by any stretch of the imagination, I’ve become acquainted with it more than just in passing, so I thought I’d write about a very basic template for a component and its associated files and explain a couple things about it. The following template serves as a good model, in my experience so far, to start from.

For this post, I’m only going to work with one component, its ReactDOM script, and an HTML file.

First, let’s look at Exhibit A.

Right now, if we were to open up a server like localhost:3000, this page would render a blank page.

First, let’s go line-by-line through this code starting with the App Component.

Line 1, I’m just importing React itself for this file to function properly.

Line 3 is where the fun begins. Here I’m creating the Component App’s body using ES6 syntax. This allows for a lot of shorthand, one being that methods don’t need the function keyword like so:

render: function() {   return etc.}

Instead, look at the initial ES6 example, and you’ll see that ES6 makes it known that with the () that you’re attaching a function to the method “render”.

Next, on lines 5–7, I’m calling a constructor function and passing in super(). What that does is define what “this” is for the component’s use of “this”, which from my spartan experience is essential.

In lines 9–16, where we’ll spend most of our time, I’m calling a render function to return whatever JSX I want this component to show on the page. JSX is HTML-like, but it isn’t HTML. It’s actually trans-piled JavaScript, which makes certain potential hang-ups’ solutions make way more sense. I’m actually kind of cheating here as far as explaining things go by automatically creating a <div> tag to wrap around whatever potential JSX might be in there.

So why did I put that <div> there as a placeholder, if nothing else? The reason is we’re going to need it if there is more than 1 JSX element, say a <p> and another <p> containing different things that are supposed to be together, but separate. That “return” still operates like a normal JavaScript “return” and can only accept and return one element. Each JSX element is actually a trans-piled JavaScript function that looks like this when written out longhand (assume a <p> tag whose inner HTML is “Hello World”:

return React.createElement(‘p’, null , ‘Hello World’)

If we used 2 separate <p> tags, it would be asking the “return” to return 2 functions, like so:

return React.createElement(‘p’, null , ‘Hello World’), React.createElement(‘p’, null , ‘Hello World 2’)

Basic JavaScript doesn’t like this, so naturally React JavaScript still doesn’t like this. By the way, those 3 arguments for that createElement function are the element you’d like to create, any props you’re going to pass it, and what you want it to contain and render.

So how do we get around the above predicament? We wrap everything we’re trying to return in a <div> so the return is actually just returning that <div> regardless of how little or how much is contained within it, hence why I just set up the Component template like the initial example. Just a reasonable habit to have.

The parentheses following the return , which wrap the JSX are actually unnecessary as well; however, you can’t utilize whitespace without the parentheses and the JSX will need to immediately follow the return not allowing for a line break, which to me allows for cleaner and more readable code.

Lastly, for our App Component, we export it, which will allow us to use it in other React files, in this case our script.js, which you can see here:

On the first 2 lines, we’re requiring the necessary dependencies for this file to work.

On line 4, we’re calling the method “render” on the ReactDOM and passing in as 2 arguments:

  1. The React Component we’re wishing for it to render. This should be the largest container component, which contains all other components as children, grandchildren, etc.
  2. Where we want this to render. Here we’re saying render it to the element with the ID “app”.

If we look at the HTML file,

it looks essentially empty with the exception of the <div> with the id of “app”. This is one of the really cool things about React in that we build all of the HTML-like JSX into our components and piece them together to be rendered by the largest container in a singular <div> in the actual HTML

So finally if we add inside the <div> of our App Component an <h1> saying “Hello World!” and a <p> tag saying “Nice blog post, Colin!”,

what will be rendered is exactly what you’d expect: A CSS-less h1 and a p right below it saying exactly that in all of its bland glory.

--

--