# Frontend repo improvements

## Tests
Before any major improvements can be made safely, I think we should write a full suite of tests (Cypress, Selenium, whatever) covering the majority of the flows through the FMS.

This will not only give us a suite of tests that we can run against the product periodically, but would also be a good learning exercise for everyone on the team, as there are definitely parts of the site that noone knows about!

We can then also extract a small suite of smoke tests from this that we can run against PR's to ensure safety around releases.

This would also hopefully flag up some currently broken/unused bits of functionality that we could remove.

## Repository shape
Moving to a Lerna (or alternative) managed monorepo with each app powered by Create React App, as proposed by Luca, would allow us to make future changes to the apps in an easier manner. We would also benefit from the Webpack configurations being a bit more standardised, and Webpack would not rebuild every single app on changes, which should improve the developer experience.

## React upgrades
Upgrading React would obviously be a good idea, in terms of product health, performance, and hiring/retaining talent (no-one wants to work with fossils).

This has been attempted in the past, with one of the major stumbling blocks being our ancient monkey-patched version of React Router.

Along with the monorepo change above, we could take some of the pain out of the upgrade process by upgrading the apps one by one.

Upgrading React would also mean we could use some of the newer features of React, such as hooks, which would allow us to gradually remove our dependency on `recompose` HOCs (make the components a bit nicer in the process).

## Flow
Morgan proposed removing Flow when he joined. A bit of work was done on this, but we should either just remove Flow or use it properly. I have no strong feelings either way on this.

## Recall
I would vote to get rid of this. I spiked replacing it with GraphQL & Apollo, which didn't seem too onerous, and would allow us to use both at the same time while we migrate.

The spike was for the supplier page, and took us from about 10-15 queries to just 1. Apollo handles all of the caching & record stores, so we could remove a large bunch of code by making this change, and could speed up the app for our users.

## Immutable.js
Another large library that we could remove with the above change. I'm not sure if we can use Immutable.js alongside Apollo out of the box, but currently we half use it and half don't, so I don't think removing it would be too much of a hardship.

If we were to move to Apollo, immutable records wouldn't really give us much benefit, as Apollo keeps track of whether or not a re-fetch is required.