redux Tag

Shine’s TEL group was established in 2011 with the aim of publicising the great technical work that Shine does, and to raise the company’s profile as a technical thought-leader in the community through blogs, local meet up talks, and conference presentations. Every now and then (it started off as being monthly, but that was too much work), we curate all the noteworthy things that Shiners have been up to, and publish a newsletter. Read on for this month's edition.

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.

One of the hottest JavaScript libraries out there right now is React. Whilst there are many good reasons for React being so popular, the main reason my team picked React for our new project is because of the commonality between React and React Native. The concepts and the language are the same, so if you can write React, then you can write React Native. There is also the benefit of being able put both in the same project and then share business logic between them, which is precisely what we need to be able to do.

There are a number of ambitious projects out there that aim to eliminate duplication between platforms by using a common set of React primitives. react-native-web, ReactXP and react-primitives spring to mind. However, these rely on not only a common set of components, but also a common approach to things like styling and animations.

Whilst we wait for the dust to settle on which is the best generic solution to use, my team has come up a simple approach that extends upon a pattern that is already quite well known in the React community. In this post I'll outline this approach.

In this article I will show you how to write safer TypeScript code by leveraging a feature called strictNullChecks. It's quite easy to miss because it's turned off by default, but can help a lot to produce more robust code. I'll also briefly introduce another lesser-known feature of the language called type guards. Some Java full-stack developers (like me) always wanted to have statically typed JavaScript. I remember when starting a new project with GWT and being quite amazed by the possibility of using Java on both sides. Nowadays, many new languages are trying to be a replacement of JavaScript. TypeScript is one of them. I got my first experience with TypeScript when trying early betas of Angular 2. I quite liked a concept of adding static types to JavaScript. However, I also see developers trying to keep the freedom of JavaScript. Fortunately, TypeScript gives developers flexibility to decide what way they want to go and how they want to mix static vs dynamic types. To experiment with these tradeoffs, I decided to use TypeScript for a new React/Redux project. The application is a web SPA which is the front end for a typical SAAS. Users can register/login, adding credit cards, managing api keys, see billing information, etc. All the examples in this article will be from that project and have React+Redux context.