Skip to content
Peter Mouland edited this page Sep 24, 2016 · 4 revisions

After trying, and sometimes failing, to implement ideas I had seen on other Starter-Apps I decided to write my own, unique type of starter-app. React-lego was born to help put the building blocks together.

Existing Starter apps not good enough, eh?

There are many great starter apps out there that will help you build awesome React apps quickly. I found that although these apps might have every tech that I wanted, they also had some that I didn't. Most of the time I just wanted to improve my existing app, but as starter-apps are often written in very different ways, it can be hard to compare each app to try and work out how to add one specific bit of functionality.

How's React-Lego different then?

With React-Lego I've tried to keep the starter app as small as is professionally possible. I've then created a new branch each time I wanted to add a new piece of tech. This allows interested folk to use Github to compare the base branch (normally master) with the new branch and only see those changes they are interested in.

Other changes may have also occurred, styling or component tweaks, but this is real-life and these changes are required in real apps. If the component change doesn't apply, keep reading and scrolling until you get to a file that gets your interest.

But this starter app isn't so small!

The Master branch has be written with the foresight of knowing what tech I want to add in the future: It's been written so it's easy to expand. This does mean that it could have been smaller, but I am hoping that you'll see some well established practises and be able to understand it as it is. Any smaller the code would be very similar to other apps as well as not being production-ready.

Some of the good practises I've tried to follow are that it is :

  • Well tested,
  • universal,
  • highly modular components

How 'Real-world' is the example app?

I have assumed people looking here already know how to build a simple client-side ToDo app. With this in mind, I tried to make something that requires the use of external API's. This makes the whole thing a little more complicated but also opens up the opportunity to add new technologies as way of improving and speeding up the user experience.

The example app is a simple trivia game based on Star Wars API. The master branch does the api call client-side, not only because this keeps the base app easier to understand, but also because the data isn't visible when the app first loads. This allows us to lazy-load in data just before it will be required.