An example UI built with React and Tailwind, scaffolded using Create React App.
The code for this project can be found on GitHub at https://github.com/emilybennet/react-fe-example, and a live demo is available via GitHub Pages at https://emilybennet.github.io/react-fe-example/.
- Clone the GitHub repo.
- Install dependencies via
npm install. - Start the development server with
npm start. - Band JSON files live in
./src/band-jsonand are manually set in./src/App.tsx. - Happy hacking! 😊
With both time and Create React App (CRA) constraints, I opted for basic state management via React’s useState hook and Tailwind CSS for styling.
Personally, I’ve always liked CSS-in-JS for colocating styles with components. But with Styled Components entering maintenance mode and the many benefits of utility-first styling (smaller builds, reduced duplication, shared language), Tailwind has become my default — though Yak looks like a promising future-friendly alternative. 👀
- Automated testing. Unit tests were next on my list before time ran out 😅 — but they’re essential for long-term stability.
- Migrate off CRA. CRA was officially deprecated in Feb 2025. Additionally, some of CRA's legacy dependencies introduce downstream version conflicts and potential vulnerabilities, which can make long-term maintenance and tooling upgrades more difficult. Migrating to Vite or Next.js (depending on the app’s scope) would offer more flexibility and modern tooling.
- Improved form validation. Right now, validation relies on basic HTML attributes. That works, but for consistency across browsers and better dev ergonomics, a combo like React Hook Form and Zod would be ideal.
- Input masking. Fields like credit card number and expiry could be more intuitive. We could handle formatting manually or explore libraries like Cleave.js or imask.
- Internationalization (i18n). To serve a broader audience, we could integrate translation support. i18next is a popular and flexible option for React apps.
- Custom quantity stepper. The current number input works fine (and is accessible), but it doesn’t fully match the mock. A custom control with always-visible +/- buttons would better match the spec and UX expectations.
Thanks so much for taking the time to get to know me and for reviewing this project!