CatLover App exercise

[tkexercise]

CatLovers App (GWI Interview Task)

What this solves

Allows users to browse random cat images, explore breeds, and keep a list of favourites, all backed by TheCatAPI.

Getting started

Note

I suggest to use nvm for better compatibility and run nvm use before installing

1. Copy .env.sample to .env and add your VITE_CAT_API_KEY (If you don't have it, there is no pagination or using favorites).
2. npm install
3. npm run dev

Note: The key was left intentionally in the env.sample file for reviewer's convenience (for the exercise) and because this is used by the client either way. In any other case it shouldn't be included in the repo.

Please read more info in the README.md file in the repo for the project details.

Live demo

https://exercise-beta-ashen.vercel.app/

Key features

Home (Random Cats)

• Fetches 12 random images on load (looked better with 12 and can be updated in constants)
• Click the heart icon to favourite
• Click an image to open modal with breed details (or the “rare cat” notice if none)
• Shareable URL always points to /cats/:id. We can utilise canBookmark to disable it in Favorites if we want to have urls specific to each view.

Breeds

• Lists all breeds from API
• Click a breed name to view details plus that breed’s cat images
• Cat images inside breed modal work exactly like home page

Favourites

• Persists favourited images in context (and user_id in localStorage)
• Unfavourite or open modal from this page
• Shareable URL still uses /cat/:id.

Error handling and loading

• Errors are handled in the components that fetch data and show a reusable friendly message
• Loading states are shown while fetching data

Performance and caching

• React Query caches results for 5 minutes
• Stale‐while‐revalidate pattern keeps UI snappy on refetch
• Memoized where it made sense and could lead to possible performance bottleneck

Testing and CI

• Unit tests with Vitest and React Testing Library core functionality and components.
• MSW stubs TheCatAPI in tests for reliable snapshots
• GitHub Actions workflow runs lint, type-check, and test on every PR

Structure

My goal was to strike the right balance between folder structure and component separation for a v0.1 project. In a larger team or enterprise app I’d adopt a more granular layout, but here I’ve kept things simple to make code reviews easier.

src/
├── assets/ # Static assets
├── components/ # UI components
├── constants/ # Application constants
├── contexts/ # React contexts
├── hooks/ # Custom React hooks
├── layouts/ # Page layouts
├── providers/ # Context providers
├── services/ # API services
├── testing/ # Test configuration
└── types/ # TypeScript type definitions

Libraries

• Vite: bundler & local dev server, plus basic config files scaffolded out of the box
• React and React Router
• @tanstack/react-query for data caching: Used in the past, with great results.
• Axios for HTTP calls: my go to library for API calls.
• Tailwind CSS: Blazing fast prototyping. I have worked a lot in the past with utiliy based CSS frameworks so it's a no brainer for me. I have also designed such frameworks in the past.
• TypeScript
• @tabler/icons-react: just an easy way to add icons to the project.

Next steps (in priority order)

1. Introduce a more granular component architecture suited for a team/organization
2. Write end-to-end tests with Cypress on key flows (favourite/unfavourite, share link)
3. Extract reusable “CSS components” by utilising Tailwind’s @apply directive
4. Add Storybook for component previews and visual tests if the project is big or we have more than one teams working on it.
5. Analyse user behaviour and performance of home page in case we need to use a library like react-window.
6. Move some constant values to env variables when it makes for multiple environment support. For example BASE_URL etc.
7. Dockerize the app especially if the rest of our stack is.

---

Thank you for taking the time to review it.