I had been working on a header design for an upcoming rework of several of our apps. I wanted a “unified” look and feel, because sometimes when you’re dealing with different developers over several years making intranet apps without adult supervision, things get a little Wild West. My original mockup was all pure HTML and CSS with a little Bootstrap for moral support, and overall it looks clean, functional, and responsive.

My goal here was to translate it into React, although the final product probably won’t be written in React. The mockup is, by nature, non-functional, but I wanted to make it somewhat functional for testing purposes. After all, if all I needed was a static display, choosing React over HTML would be the definition of overkill.

[I obviously can’t spill specifics or post identifying screens on account of the app being corporate-owned and all that, so specifics have been scrubbed from the code].

Setup

The first order of business was to build a new testing site:

npm create-react-app [APP-DIRECTORY-NAME]

This will create APP-DIRECTORY-NAME within the current working directory (so cd and md your filesystem before you run it) and will download the initial scaffold for a fully-functional React application. You could do all of this yourself, manually, but there’s some considerations you’ll have to…consider…like getting the right parsers in place and eventually set up for deployment. Using create-react-app is an easy way to get things started so you can hit the ground running.

Breakdown

Next, I had to sit down and think about what I needed to do to the existing design to make it “React-able”. React’s claim to fame is that it’s component-based, meaning that you don’t just start coding at the top and work your way down. Instead, you code discreet blocks of display and supporting functionality in the same file. For my design, I had the app, which contained the header, which contained the header title and the header user information.

At the very top is the index.html file, which contains what you’d expect in a properly formed HTML file. Rather than layout out scaffolding there, we include a single div tag with the ID of “root”. The ID value isn’t magical; we can call it whatever we want. Next, we have an index.js file which oddly enough is not referenced in the index.html file, but it does refer to that lone div by its ID value. Within that index.js file we have a reference to an App.js file, which is where we start our actual layout.

App.js doesn’t do much. It just returns a tag called Header, which is defined in the header.js file as seen below.

If you look close, and if you know HTML, you’ll see two tags in there that aren’t standard: HeaderTitle and HeaderUser. Those tags are generated by two other files named…wait for it…HeaderTitle.js and HeaderUser.js. That’s kind of irrelevant, though, because at the top of App.js you can see that I’m importing those files under the relevant names. I could have called them Fishlips and Kettledrum for all the app cares.

Next comes the HeaderTitle.js. This file creates a title for the app next to our company logo.

It’s straightforward and doesn’t do anything.

Finally, we have the HeaderUser.js.

This file does do something. It’s taking some data that it receives…somehow…and is displaying the name of the recognized user. This appears on the same row as the app and logo, but off to the extreme right.

I can’t really display the whole thing in a single block, because that’s not how React works. Instead, each component above exports it’s contents so that it can be imported into another file. Once imported, we can refer to the contents by using standard HTML tag notation. This means we can re-use the components as many times as we need to in a single file.

I’m going to pull the reins here, and next post we’ll go through each file and explain the structure.