React Craftsmanship Part 1 — Get it Written

  • Chris Wallace
  • Wed Jan 24 2018

“A happy new year and happy new project time! Back on the pet project bandwagon to build something new and exciting!”

“A happy new year and happy new project time! Back on the pet project bandwagon to build something new and exciting!”

This was my general feeling starting off my Christmas break. This year I decided 2017 would be the year I rebuild my site (for the 4th time…) and harness all the new tech insight I had gained over the past 12 months. I was well into React by now and started identifying good practices.

Surely file -> new project wouldn’t be difficult would it? WRONG! Good grief getting started was tough!


The wonderful/terrible part of JavaScript is it’s non-prescriptive architecture options…
The wonderful/terrible part of JavaScript is it’s non-prescriptive architecture options…

The wonderful/terrible part of JavaScript is it’s non-prescriptive architecture options… Even after getting the boilerplate all setup I hit a massive wall and a killer question, “where do I start?!”. Let’s address the first fact about React, it’s to build applications, not websites. Arguably a website is an application but suddenly URLs are immaterial and full page renders are old hat.

My next question was “how do I manage my components?”. React components are deceptively simple to write, 30 seconds of key tapping and you’ve achieved a stateless functional component. However when you start nesting components you end up in a vicious cycle of nested components inside of components and try to justify the ‘reuse’.

My next question was “how do I do this without introducing a data layer?!”. React and Redux/Flux/MobX work well together, but each one comes with a load of middleware and even more boilerplate. Another job and I haven’t even started writing yet!

Then my final question was “do I need to write an api as well?!”. A full-stack react app has many moving parts, and the deeper you try and write an app, the larger the underlying task becomes.

So without writing a single line of code, suddenly I’ve got a very tall stack to climb in order to make the smallest of components data-driven (and don’t get me started on how to even deploy/containerize/host this nasty stack of pancakes!).

Suddenly I was at a cross-roads, I could waste valuable days getting a hacked-together stack working (locally), or flip the monopoly board over and ponder over it some more. It became apparent over the past few months I was experience ‘React fatigue’. I was worn out with technical terms, learning dozens of new concepts and judging the most skillful way of writing them for ‘the real world’, trying to come up with component strategies and hitting a wall each time. I was sick of the technology before I had even started using it in full force.

So finally I decided “screw it! Chris you can’t sprint this marathon! You need to tackle each challenge in isolation!” and that’s exactly what I’m doing.

1 yY x0utX0KDYJfCMl9iL9w

Being my own worst enemy, I said “To hell with me, let’s get something done!” Rather than running head first into developing my full stack application and build my new homepage with components refactored to the extreme. I’m taking it slow, getting some value churned out and figuring out how to optimise it as I go. I broke it down into the following achievable milestones (basically the layers of the application stack)

  1. Build out the UI in a flat component with all copy/content hard coded
  2. Componentise the solution to create a suite of reusable components
  3. Switch out the hard-coded copy/content with data-bound props, BUT have the data as a hard coded object
  4. Switch out the data-bind with a working redux layer, BUT still use the local hard coded data as ‘redux state’
  5. Switch out the hard coded local data with an api call, BUT migrate the hard-coded data to a new api service
  6. Switch out the hard coded api data with the real deal (aka content from my CMS)
  7. Build out the UI for the next page with the components in step 2. and repeat the loop.
  8. Publish the application and let the good times roll!

So how did I start? Phase 1 of this development approach focused solely React and CSS modules. Just getting a page crafted out using the framework and getting the page to look how I wanted it. I’m the type of person who responds well to visual feedback, so a static version of my homepage in React gave me assurance I’m making real progress.

So a few hours later and an occasional tweak I had a fully built out version of my page in React! (below is a sped up version of the build with some cheesy 80s montage music on top!)

Embedded content: https://www.youtube.com/watch?v=OKk6tgs1kAw

“Aren’t you creating tech debt in the process?”, well yes and no. The technical debt is optimizing and componentising my page so I can reuse pieces of the design on my next page. But that’s not tech debt, I can’t progress until I’ve cracked my component strategy. So I know the next part of my project is to rip the page apart again into reusable components.

That’s not to say I didn’t identify commonality along the way. Developing a navbar smells like it’s going to become its own component in time. So some well-placed comments and css class naming and I give myself a paper-trail for grouping markup and styling rules.

Related Technologies

  • git
  • javascript
  • c#
  • gitflow