Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted 24 days ago

Rest Countries Explorer built using React, Vite, and Tailwind CSS

fetch, react, react-router, tailwind-css, vite
Partha Dey•120
@ParthaDey5
A solution to the REST Countries API with color theme switcher challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


What are you most proud of, and what would you do differently next time? 🌟 What You Can Be Proud Of
  • Precise deployment with GitHub Pages, including handling tricky routing issues with BASE_URL and nested paths
  • Maintaining custom CSS class names (like Blue950) exactly as intended, even when I tried to meddle 😅
  • Implementing dark mode, region filtering, search, and border navigation flawlessly—and not just functionally, but with polished responsiveness
  • Debugging like a pro, tracking down everything from broken links to MIME errors to CORS issues

This wasn’t just coding—it was full-stack problem-solving, from dev to deployment.


🔁 What You Might Do Differently Next Time
  • Set up the base path and routing structure earlier, so less rework is needed when deploying
  • Use environment-specific configs, like a .env.production to streamline the BASE_URL logic
  • Consider using useNavigate() for smoother navigation without nesting <Link>s, especially for back buttons
  • Add a README earlier in the project, documenting decisions as they evolve to make handoff and submission smoother
What challenges did you encounter, and how did you overcome them? 💥 Challenges Faced & How I Solved Them

1. Routing errors on deployment
When deploying to GitHub Pages, I encountered broken routes and nested path issues like /country/Afghanistan/country/Iran....
→ I resolved this by configuring BrowserRouter with the correct basename using import.meta.env.BASE_URL, and adjusted <Link> paths to be absolute where necessary.

2. Incorrect asset loading paths
Initially, assets like main.jsx and index.css failed to load on GitHub Pages due to mismatched URLs.
→ I updated vite.config.js to set the base path to my repository name and ensured index.html used relative paths (/src/main.jsx) that Vite rewrote correctly on build.

3. CORS and MIME-type issues during local file testing
Trying to open index.html directly (via file://) led to browser blocks and script failures.
→ I switched to serving the project with npm run dev for development and npm run preview for testing builds.

4. ClassName overwrites affecting dark mode styling
Early on, auto-formatting tools or helper suggestions changed custom class names like Blue950, breaking dark mode.
→ I maintained strict control over class names and double-checked that none of my custom Tailwind tokens were overwritten.

5. GitHub Pages deployment confusion
At first, the live URL didn't appear in the Pages settings.
→ I ensured the dist/ folder was pushed correctly using the gh-pages package, and verified Pages settings pointed to the correct branch and folder.

What specific areas of your project would you like help with? 🔍 Areas I’d Love Feedback On

1. Routing Strategy with basename
I used BrowserRouter with basename={import.meta.env.BASE_URL} to handle GitHub Pages routing. Are there best practices I’ve missed here, especially for avoiding nested path issues in multi-page apps?

2. Link Navigation in Nested Views
My border country links were originally relative and caused broken URLs. I fixed them using absolute paths like /country/${name}. Is this the best approach, or would useNavigate() or other methods be more elegant?

3. Vite + GitHub Pages Deployment Workflow
I configured Vite with a base field and used gh-pages for deployment. I’d love insight into whether this setup could be simplified or improved for larger projects.

4. Styling Strategy in Tailwind
I use custom colors like Blue950/Grey50 and a custom dark mode via Context. I’d appreciate any feedback on how to improve readability, reusability, or scalability of my utility-first approach.

5. Code Structure and Separation
Currently, components and pages are in a flat src/ layout. Should I be refactoring into feature-based folders or splitting out logic like filtering/search into custom hooks?

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

No feedback yet. Be the first to give feedback on Partha Dey's solution.

Join our Discord community

Join thousands of Frontend Mentor community members taking the challenges, sharing resources, helping each other, and chatting about all things front-end!

Join our Discord

Stay up to datewith new challenges, featured solutions, selected articles, and our latest news

Frontend Mentor

  • Unlock Pro
  • Contact us
  • FAQs
  • Become a partner

Explore

  • Learning paths
  • Challenges
  • Solutions
  • Articles

Community

  • Discord
  • Guidelines

For companies

  • Hire developers
  • Train developers
© Frontend Mentor 2019 - 2025
  • Terms
  • Cookie Policy
  • Privacy Policy
  • License

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

How does the accessibility report work?

When a solution is submitted, we use axe-core to run an automated audit of your code.

This picks out common accessibility issues like not using semantic HTML and not having proper heading hierarchies, among others.

This automated audit is fairly surface level, so we encourage to you review the project and code in more detail with accessibility best practices in mind.

How does the CSS report work?

When a solution is submitted, we use stylelint to run an automated check on the CSS code.

We've added some of our own linting rules based on recommended best practices. These rules are prefixed with frontend-mentor/ which you'll see at the top of each issue in the report.

The report will audit all CSS, SCSS and Less files in your repository.

How does the HTML validation report work?

When a solution is submitted, we use html-validate to run an automated check on the HTML code.

The report picks out common HTML issues such as not using headings within section elements and incorrect nesting of elements, among others.

Note that the report can pick up “invalid” attributes, which some frameworks automatically add to the HTML. These attributes are crucial for how the frameworks function, although they’re technically not valid HTML. As such, some projects can show up with many HTML validation errors, which are benign and are a necessary part of the framework.

How does the JavaScript validation report work?

When a solution is submitted, we use eslint to run an automated check on the JavaScript code.

The report picks out common JavaScript issues such as not using semicolons and using var instead of let or const, among others.

The report will audit all JS and JSX files in your repository. We currently do not support Typescript or other frontend frameworks.