Kerry Clements

Time Tracking Dashboard

Case study

Overview

This project started in 2022 as one of my first attempts at React, built around a Frontend Mentor time tracking dashboard challenge. I picked it up again in 2026 to finish what I started and modernise the codebase.

2022 - where I left it

I built this during a period when React was still new to me. My bootcamp had touched on the fundamentals but data wiring was not something I had got comfortable with yet. I got the layout working (all six cards, the grid, the colour-coded tops) but the timeframe switching was never wired up. All the data was hardcoded as strings directly in the JSX. I knew it was unfinished but I had just started a full time job, and with that and family commitments, personal projects had to wait.

The code sat on GitHub, undeployed, for four years.

2026 - coming back to it

I have been going through old repositories, tying up loose ends. When I opened this one I was immediately confused by how it worked. I tried npm run dev out of habit before realising it needed npm start, it was still using Create React App, the older React build tool that has since been replaced by Vite. When I got it running I was pleased with how the layout looked, but looking at the code told a different story. Hardcoded strings in the JSX, no data file, no interactivity. I could see exactly where 2022-me had run out of road.

What I changed

The first job was modernising the stack. I migrated from CRA to Vite, upgraded from React 17 to React 18, and added TypeScript throughout. TypeScript was unfamiliar to me in 2022 but I spent three and a half years using it professionally at Scalable Software, so that part felt natural.

Once the stack was sorted I added the FEM data file, defined typed interfaces for the activity data and a TimeFrame union type, and wired up the Daily / Weekly / Monthly switching with useState. I also moved the category colours and previous period labels into a constants file rather than scattering them through the JSX.

The last piece was some accessibility improvements - replacing non-interactive div elements with semantic button elements, adding aria-pressed to the timeframe nav, and adding aria-label to the card menu buttons.

Accessibility

After deploying I ran a Stark audit against the live site and found five contrast violations. Daily and Monthly in the timeframe nav were failing because text-indigo-400 was too close to the bg-indigo-900 background. The fix was straightforward, switching inactive buttons to text-indigo-200 gave enough separation to pass.

The trickier ones were "Report for", "Jeremy", and "Robson" in the profile card. The text was white but the background was bg-indigo-500, which only gives around 3:1 contrast against white, not enough for normal-sized text. Darkening the background to bg-indigo-700 brought it up to roughly 5.9:1 and cleared all three violations. It was a good reminder that white text is not automatically safe, the background matters just as much.

What I learned

Coming back to old code is a useful exercise. It is easy to feel like you have not progressed, but looking at code you wrote four years ago and immediately seeing what is wrong with it is actually a sign of growth. The things that stumped me in 2022( data wiring, component structure, TypeScript) are things I now reach for without thinking. Professional experience closed that gap more than anything else.

Try it

timetracking.kerryclements.com

View the code on GitHub