Author: Ben Teese

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.

14 December, 2017 /

Learn more >

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.
05 January, 2017 /

Learn more >

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!

10 October, 2016 /

Learn more >

Every couple of months I'm in a meeting where a couple of developers start arguing about which HTTP status codes to use in their RESTful API, or where they decide to not use HTTP status codes at all and instead layer their own error-code system on top of HTTP.

In my experience, HTTP status codes are more than adequate for communicating from servers to clients. Furthermore, it's preferable to stick with this standard, because that's what most client and server-side HTTP libraries are used to dealing with.

When it comes to which status code to use, the truth is that most of the time it doesn't matter, just so long as it falls within the correct range. In this post I'm going to outline what the important ranges are, and when you should use each one.

If you control both the client and server, these guidelines should do just fine. If you're writing a more generic RESTful service where other people are writing the clients, you may have to be a bit more nuanced. Either way, this rule-of-thumb is a good starting point to work towards the simplest solution possible for your particular problem.

03 June, 2016 /

Learn more >

The ES6 spaceship has landed and promises are amongst the first new features to come down the ramp. I'm very excited about this. This is because I love promises. They've been lurking around for years in different incarnations, but now that we've settled on a standard, I think now's the time to learn them if you haven't already. So in this post I'm going to talk about what promises are, why they're awesome, and how you can start using them right now.
08 May, 2015 /

Learn more >

[caption id="attachment_6264" align="alignnone" width="500"]berlin_-_old_and_new A clash of the old-school and new-school[/caption] Over the last couple of years at Shine we’ve built a number of Single Page Apps (SPAs) for large businesses. An app we recently built had to integrate with Oracle Access Manager (OAM), an Identity Management System (IDM) from everybody's favourite enterprise software company. In this post I'm going to talk about a strategy that we used to successfully work around mismatches between the way that SPAs and OAM do things.
04 February, 2015 /

Learn more >

1_5_3_1_Chicken_Egg We love Git Flow. It's awesome to have a standard release process where everybody is using the same terminology and tooling. It's also great to have out-of-the-box answers to the same questions that get asked at the start of every project. For example:
  • "How are we going to develop features in isolation?"
  • "How are we going to separate release candidates from ongoing development?"
  • "How are we going to deal with hotfixes?"
Now it's enough to just say 'We use Git Flow', and everybody's on the same page. Well, mostly. Whilst Git Flow is terrific for managing features and separating release candidates from ongoing development, things get a little hazier when it comes time to actually release to production. This is because of a mismatch between the way that Git Flow works and another practice that is common in large development projects: immutable build artifacts.
07 January, 2015 /

Learn more >

Show more
Loading...