Getting with the Program: A First Foray into React
In the corridors of the Makers Academy, a certain technology is whispered about by my fellow students with a something approaching awe, if not fear. Like some kind of mythical beast, it is not truly understood but make no mistake — it is Scary and it is Hard. Only the bravest of Makers can possibly hope to learn and use it in their projects. The prize for doing so? Untold glory. Its name… React.
Being surrounded by these whisperings I’d understandably developed something of a complex about React. How did it work? Would trying to use it cause a project to fail? My natural curiosity for all technologies was in this case tinged with an irrational sense of unease.
It was in this state that I arrived at the beginning of Practice Projects Week, where my cohort and I would pitch ideas for week-long projects designed to give us an opportunity to build something in a small, self-organising team. Voting would take place, and an algorithm would place us into project teams according to our preferences.
Sensing this was a good opportunity to try something new, I made up my mind; this was the week where I would find out what all the fuss was about and tackle React.
Making the Pitch
I decided to pitch a fairly straightforward idea for an app, one that would hold a decent amount of challenge but also be fertile ground for learning a brand new technology. We would build a Steam profile app where a user could authenticate via Steam, then see an overview of their account, games and achievements — data we would collect via the Steam Web API. I chose not to mention React in the pitch, lest I scare away potential team mates!
Pitch done, voting over, the team was assembled. Dylan, Ben, Frankie and I would be team Steami.
First order of business was to decide on our stack. Node.js, Express and MongoDB are not covered on the course, but I had taught myself the basics as an extra challenge during a previous weekend. I explained to the guys that I was confident I could show them how to get an app up and running in Express, and, if they were up for it, we could then have a go at React. Wide eyes. But if I thought we could do it, they were in.
It was on.
Universal Javascript
That afternoon the first step was project planning. User stories were written, an MVP agreed on and a Scrum board created. However, before we could create any meaningful development tasks on our board we needed a serious injection of knowledge — after all, just what exactly is React? And how would we need to structure our application?
All aboard the good ship Google, we landed upon an excellent tutorial by Luciano Mammino called React on the Server for Beginners: Build a Universal React and Node App. We agreed that we would all work through the tutorial that night and then re-convene in the morning to complete our planning with our newly gained knowledge.
That night was something of a revelation. Based on what I had learnt in the tutorial, by employing the principles of Universal Javascript, our app’s view rendering, routing and data retrieval would be equally capable of running on the server or in the browser. In other words, when our page was first loaded by the user, the server would recognise the route, render the view and pass it back. Pretty standard. However, after that, any navigation by the user would be picked up by the React Router now running in the browser, and the newly requested view would be rendered entirely without the assistance of the server. No need for a full page refresh. The added fact that the server and the browser would both be using the exact same Javascript code to achieve this was simply amazingly cool.
On the front end side, it was now clear how React components could be used to render each part of the site. We would simply need to carefully design each section of the app as a hierarchy of parent-child components. React Router could ensure that the correct layout and content components were chosen for a given route. Where data was needed, it could be loaded as state in a parent component and passed down to the children as needed. A few hour’s effort had yielded some very exciting new knowledge!
The next morning I was brimming with enthusiasm and eagerly explained to my team mates how our app could be architected using the concepts I’d learnt the night before. We were all electrified by the possibilities of this new approach. We split ourselves into pairs and one pair worked on wire-framing the React component structure while the other created and configured our initial Express server.
If our brains were not already over-stimulated, the day held in store much more to learn! We had never tested anything like React before, so had to learn the basics of Mocha, Chai and Enzyme. In addition, our build process required some fast up-skilling in Webpack and we decided to have a go at using JSX and Javascript ES6 syntax across our codebase. It turned out we could rely on Babel to translate this flashy new syntax into our old friend ES5, so that our app retained compatibility with older browsers. Perfect!
By the end of the day we were successfully rendering our first React components to the screen, exhausted, but happy.
Some Data Would Be Nice
Day three.
Since our app’s main focus was to gather and display data from the Steam API, we needed to figure out how to get this data into our React components. We knew that our components could be given state, and the state is where we would need to store the data retrieved from the API. But how? Today’s learning would be the React component life-cycle.
React components go through a specific set of steps every time they are mounted, rendered and updated. Each step is essentially a function that be used for whatever purpose is necessary at that time in the component’s lifecycle. For example, when first initialised a component will run the following functions:
GetDefaultProps → GetInitialState → ComponentWillMount → Render → ComponentDidMount
Cool! We just needed to figure out how to use this to our advantage. A crucial piece of knowledge that we unearthed was that when the state of a component is updated, the component runs a new update lifecycle and re-renders itself, and its child components, to the view. If we had a parent component for each section of the app that had responsibility for handling data, we could simply have it update its state when data was received. Thanks to React magic, when it re-rendered itself it would also re-render all its children, and the data would effectively cascade down the hierarchy where the presentation to the user could be handled.
Further research led us to land on Fetch as our library for making our API calls. It could run on the server as well as the browser, and would return a Javascript promise when given a new AJAX request to make. On completion of the promise, we could parse the received JSON and then update the state of our data containing component, triggering the wonderful re-rendering process of all the children. Whilst the app waited for the data to be received, we could show a simple ‘loading’ message, later to be changed into a nicely animated loading icon when we were out of MVP mode.
This all seemed very theoretical to us at this stage, and it was only when we worked through the first example, ironing out numerous bugs, and finally saw the data load to the screen that we knew we were on the right track. Many high fives followed. This is why we code!
Now we had all the building blocks we needed to flesh out the entire app. Our data container + children approach worked really well, and meant that data was only loaded in the places where it was needed, at the time it was required. We were now not testing theories but applying proven knowledge, and our app quickly took shape around us.
Sounds Easy?
It wasn’t. But neither was it as scary and hard as I had supposed. We were mentally exhausted by the end of the week but we had learnt so much, completed our MVP and been able to spend some additional time on a bit of styling. I won’t pretend there weren’t low points, frustrating bugs and some late evenings. However, we pulled together were really proud of what we had achieved at the end of the week.
If you have a Steam ID, feel free to log into our demo app and try it out, and you’re welcome to have a look at our Github repo :)
I’m now eagerly looking forward our final projects, where we will have two weeks to spend on an app of our choice. With the basics under my belt, I’m really excited to see what else can be achieved with React. After all, my complex is cured!