Author: Ben Teese

Out at Shine's various client sites, our teams often meet to discuss the pros and cons of various technical solutions. And in the past, there was one particular Shine manager who, if he was in attendance, would regularly pipe up and ask the question: what's the problem we're actually trying to solve?

Server-side rendering a React app is a miracle on-par with childbirth and modern air travel.

OK, that opening sentence was a little over-the-top. I apologise to birth mothers and those in the aviation industry.

Let me start again: server-side rendering a React app is...kind of cool.

That said, it can be a little tricky to get started, especially if you're trying to do it with an existing app.

In this post I’ll explain one way you can implement server-side rendering (SSR) for an app that's using  React Router v4 and Redux Thunks.

Along the way we'll discuss the fundamental difference between JavaScript clients and servers, how it forces us to change the way we do routing, and the small "missing-link" that enables us to bridge React Router v4 with Redux thunks.

We'll build up a simple example to demonstrate. I'm going to assume you've got some knowledge of:

  • React
  • Redux
  • React Router v4

However, you are not required to have knowledge of:

  • Childbirth
  • Aeronautics

Let's do this.

EDIT: The initial version of this post stated that the TypeScript compiler won't emit code if it finds errors in the source. This is not correct. By default, the compiler will emit code even if it detects errors, unless the --noEmitOnError flag has been set. This post has been updated accordingly. I've recently been working on a project that uses TypeScript. I also have been playing with Flow on a personal project. In this post I want to talk about why I think these tools are important, some of the fundamental differences between them, and why the choice of which one to use might best be determined by the broader toolchain that you are working within, rather than just the particular technical merits of one or the other.

I just spent a couple of days at the YOW! Connected conference and had a great time, despite nursing a bit of a cold. There were a tonne of great talks at the conference covering a wide range of topics, but in this post I'm going to briefly reflect on one specific trend that interested me at the event: the way in which UI platforms are advancing to adopt modern languages, and are even influencing each other in the process. The end-result: they're all moving towards languages that are both functional and statically typed.

Full disclosure: This year I was a member of the programme committee for the conference. So in writing this post, there's a bit of a risk that I'm creating an echo chamber for myself. All I can really say in my defence is that I hadn't consciously made these connections in advance - it was only afterwards that I saw a trend!