11 lessons learned as a React contractor

I didn’t know I was looking for it, but when I found it something clicked.

Here’s the bullet point version of my journey to React

• I’ve been writing code for 18 years, professionally for about 13
• For 6 of those years I was a dedicated Flash developer
• After Steve Jobs’ open letter all the Flash work went away
• Remembered I could write HTML, CSS and JS, brushed up those skills
• I struggled with the major Javascript frameworks for a while, they felt like they were hiding too much logic and in a pre NPM world were monolithic brittle beasts
• Left my full time job to start contracting, mostly prototyping
• Watched a few conference demos of React
• October 2015, I bluffed my way onto a React project and loved it
• January 2016, I changed my job title on LinkedIn to React developer…

and these are some of the things I learned

1: Multiple simple components are better than one highly customisable one

Being able to change a React component’s behaviour based on the props you pass it is one of its great features. However, it can be easy to fall into a habit early in a project of building a few really generic components that can be used in lots of places.

Once you get into the meat of a project and you start fleshing out all the edge-cases of how your components need to be used, you can find yourself chasing your tail fixing bugs where component A is used in scenario X, only to find it’s created more bugs in scenario Y and Z.

My tip: if a composable component is causing bugs, break it into more simple single use components, even if you’re repeating code.

2: Always raise an Issue or Pull Request if you find bugs in libraries

You can’t use React without using open source software, whether it’s the core React project or any of the 1000’s modules available on NPM. If you find a bug, raise an Issue in the project’s repo — if you fix a bug, even better, but raise a Pull Request and get that fix merged. Chances are you’re not the only person who’s going to want that bug fixed.

My tip: give back, even if it’s just fixing typos in documentation.

3: Implement a build process first, then React

I know it sounds like an unlikely scenario, but I started a contract to build a React component, only to discover the Backbone project it was to used in, was being compiled without dependency compilation. Implementing React components in Backbone is fairly straightforward, with Redux you can even communicate between the two. However, they can only communicate if they’ve been compiled together with Browserify or Webpack.

My tip: if you’re implementing React in an existing project, migrate your build process to Browserify or Webpack first.

4: Raw SVG >= D3 for simple data visualisations

D3 is great for data visualisation, but if what you’re building is simple, maybe just rendering some raw SVG is all you need to get the job done.

My tip: learn a few SVG basics and you can push it quite a long way before having to rely on anything else. The Front End Center Youtube channel just happened to drop a great video on inline SVG a few days ago, you should check it out!

5: When all you have is two weeks, keep it lean

If all you’re doing is rendering, all you need is React and React-DOM.

Ain’t nobody got time for that Redux bullshit! Redux is great for handling state in big projects with multi-level UI, if what you’re building is fairly simple, you can get away with just passing props and callbacks. If the project ends up growing, you’ll know when it’s time to start implementing Redux and at that point it should be fairly easy to add.

My tip: boilerplate projects can be useful, but if you’re trying to keep it lean, start with React & React-DOM then work from there.

6: Relying on CSS animation alone to move a lot of elements can be slow

I can’t tell you exactly when you’re going to see a marked reduction in frame rate, maybe 30 elements or 300, but there are things you can do to help. Take advantage of React’s virtual DOM and make sure you’re only rendering or re-rendering components that really need it.

That might mean, calculating what components are visible in the viewport and only rendering those.

My tip: test on lower spec machines, but also test with extreme data to see how well things run when they’re pushed to the limit.

7: Boilerplates are a great starting point, but…

If you’re trying to learn a library or framework, boilerplate projects can be a great starting point. If your company has built its own boilerplate, great!

However, don’t be fooled into thinking boilerplates are the solution to everything. Eventually you’re going to realise it doesn’t quite do what you need, and if you’ve not built the project from the ground up it can be very daunting. Also if it’s a large highly featured boilerplate there’s a chance you might accidentally rebuild features it already has.

My tip: only use boilerplates for what they’re good at — getting a project started quickly. Don’t be afraid to break them, twist them and generally misuse them to your will.

8: Maintain a predictable Components, connected Components and Container pattern

When building with Redux, it’s best to limit the number of components that have access to the store to ensure there’s as much reuse of actions/reducers as possible.

Components should be dumb, only relying on their props.

Connected Components have access to app data via Redux and have some complex business logic, but render their own DOM and some sub-components.

Containers are thin composers that take data and only render other Components.

My tip: keep the naming and connectedness consistent

9: Strict linting is a blessing and a curse

I’ve worked on different projects with the full spectrum of linting, from no linting at all to git hooks that will reject your pushes if you miss a single dangling comma.

I think we can all agree that code quality is about more than just making sure you’re using the right number of tabs or spaces. There’s some delight in opening a file and it looking pretty, it gives your OCD a chance to chill and you can focus on writing the code.

Linting also helps catch errors like reassigning consts and speeling errors, even the classic “Undefined is not a function”.

My tip: embrace the toughest linting rules your team can stand. I use ESLint for my JS and scss-lint in Atom for my Sass. To make the transition easier, you can switch certain rules off. If you want to go hardcore and block people pushing bad code, pre-push will run NPM scripts during the pre-push git hook.

10: Retrofitting Universal React rendering into an existing Express project is doable…

…but you might gain a few grey hairs trying to do it!

There’s quite a few blog posts about how to setup a universal app, but most are assuming you want a Single Page App, few show how to just render a single React component into an existing multi-page Express app.

My tip: ReactDOMServer is your friend, just imagine that the components are page fragments and you’re just passing them to the template to render.

11: Learning Sagas may melt your brain

Sagas are a Redux middleware based on Generators which are a new feature in ES6. Generators “define an iterative algorithm by writing a single function which can maintain its own state.” which in practice is different to the normal flow of Javascript, because a function can pause during its execution while another Promise based block of code is run.

I may not be the first or the last to say this, Sagas melted my brain!

Once I’d managed to get them working and my brain had resolidified, I started writing some tests for the Sagas and my brain melted again.

I did eventually bend them to my will and wrote a whole suite of tests for the project. Had I armed myself with a thorough understanding of Generators to start with things might have been different.

My tip: If you’re using Sagas for the first time and no one on the project can explain how they work, make sure you have a deep understanding of Promises and Generators before you dive in

That’s just a highlight reel of things I’ve learned this year. It’s been an exciting year for me, working on lots of different types of project and learning lots along the way.

Looking forward to 2017 there are a couple of things that are on my list to explore, first is that React Native side project I started that I’ve been meaning to look at again and the other is styled-components.

If you want to fact check my LinkedIn profile you can, I’m also on Twitter if that’s a thing you enjoy.

Happy 2016!