And finally, here is the app I am working on: the editors at Pocket choose and schedule recommended stories for Pocket and Firefox users and they have to do it through a tool that was put together a while ago. Over time the old curation tool was not enough to meet the needs of the editors to select, edit and schedule the stories and so additional tools were introduced, such as a spreadsheet (!) to keep track of all the articles.
The new React frontend I'm building should make all the old curation tools obsolete and cut down on time spent on manual data entry as well. I am building an MVP - a minimum viable product - that is, the absolute minimum of functionality the folks at Pocket will be happy to go live with. In the months after my internship ends, new features are planned, such as a full-text search.
Now to the implementation details. The app is written in TypeScript, not JavaScript. Initially there was a learning curve and things were progressing slowly as I figured out how to keep TypeScript happy. There are a number of React libraries used on this project that are new to me - Material-UI for layout, Apollo Client to connect to a GraphQL API.
I'm also new to testing frontend code - I chose React Testing Library for this project and I couldn't be happier with it. I initially thought I'd be using Enzyme which is what is shipped with Material-UI but I quickly learned that a) I dislike relying on snapshots for testing and b) in a matter of days, I stopped caring if my snapshots didn't match the saved version because I knew - or thought I knew - that it was only because I renamed a property somewhere or moved components around. By contrast, React Testing Library and other packages from this family (i.e. Vue Testing Library) come with a philosophy of not testing the implementation details.
Another aspect of this app is that it uses a private API - at the moment nobody outside this project can clone the repository and run the code - it will die at the first hurdle of trying to connect to the API. The way to fix that is to build a default API that ships with the app so that it can be run locally without access to actual Pocket data.
The default API is what I'm working on at the moment - effectively building a mock backend for this app with the help of a famous Faker.js library. While searching for a viable - and quick! - solution for the mock API, I stumbled across Frontend First Development - as always, there's someone on the internet that's faced this problem before and found a solution.