Trainline replatforming: our front-end journey

screen-shot-2016-12-16-at-12-47-28

We recently started working on rebuilding the desktop version of the Trainline website. It is a big deal for the front-end engineering team because we have to make sure every choice is justified so that the user experience is never compromised. I am writing this blog post to explain how we went about selecting our front-end tech stack and why we made these choices. Continue reading

How we implemented a single-page application using React

BuyNowWeb is our latest offering for Train Operating Companies in the UK to sell train tickets. The solution consists of white-labelled web and mobile applications. This post will look into how we implemented a React-based, white-labelled, single-page application.

Nowadays user devices are much more performant. This has made it possible to run application logic on the client side. JavaScript support in modern browsers has come a long way and websites are providing rich user experience comparable with native applications. Because single-page applications can provide a very engaged user experience, we have architected our application to utilise the capabilities of user devices. React became our technology choice because it is a simple and deterministic way of building a user interface composed of small reusable components. Continue reading

Handling API calls in Redux with Redux API middleware

The context

It is very likely that, at a given point during the development of a client-side web app, it will be necessary to communicate with the server side using a RESTful API. If your stack is based on React/Redux, you may have found yourself wondering about where the ideal spot is to call your API and how to handle your application state based on the outcome of the interaction. Continue reading

Use proxyquire to mock your React components

Testing React components has become trivial as more and more of them are now stateless functions.

The new shallow renderer and tools like Enzyme make it possible to render a component “one level deep” when testing, without even rendering it in some sort of DOM, while still having a great api to traverse the components’ output and assert facts on its behaviour.

Given all these great tools that we have, what happens when we have a container component that renders sub-components (child components) based on some sort of rule/logic?
How do we handle those dependencies to keep our unit tests free from dependencies?

Continue reading