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
With functional tests being an integral part of a webapp workflow, we should always try to find ways to make them run smoother and make our lives easier.
I’ve been working with Selenium Webdriver/WebdriverIO for years now, but I have always thought: “Wouldn’t it be great not to need a Selenium server running before starting my tests?”
This may seem like a minor problem, but it means having another tab open in my terminal, starting/stopping that process, and it all gets far more difficult when you try to automate it in a CI environment. In addition to that, you need Java installed to run the Selenium server (or you can use the selenium-standalone npm package, which removes the dependency from Java but still needs to be started/stopped). Continue reading
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.
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
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?