Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted about 1 month ago

Product List With Cart

Jonathan Peters•230
@QMS85
A solution to the Product list with cart 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 I'm Most Proud Of...

  • Accessibility & User Experience:
    The implementation includes excellent accessibility features like ARIA labels, semantic HTML, keyboard navigation, focus management, and screen reader support. The cart functionality is smooth with real-time updates and visual feedback.

  • Responsive Design:
    The CSS grid layout adapts well from mobile (375px) to desktop (1440px) with proper responsive images using the <picture> element and different image sources for different screen sizes.

  • Clean Code Architecture:
    The JavaScript is well-organized with clear separation of concerns - state management, DOM manipulation, and event handling are properly structured. The cart state management is robust and handles edge cases well.

What I'd Do Differently Next Time...

  • State Management:
    I'd implement a more structured state management pattern (like a simple reducer pattern) instead of directly mutating the global cart array. This would make state changes more predictable and easier to debug.

  • Error Handling:
    Add more comprehensive error handling for the JSON fetch, image loading failures, and edge cases like network interruptions.

  • Performance Optimization:
    Implement virtual scrolling or pagination for large product lists, and add image lazy loading to improve initial page load performance.

  • Testing:
    Add unit tests for the cart logic and integration tests for the user interactions to ensure reliability across different scenarios.

What challenges did you encounter, and how did you overcome them?

Looking at this Frontend Mentor Product List with Cart project, here are some of the main challenges I encountered and how I overcame them...

  • Complex State Management:
    Managing cart state across multiple UI components (product cards, cart display, modal) was challenging. I solved this by creating a centralized cart array and dedicated functions like updateCartDisplay() and updateProductCard() that sync all UI elements whenever state changes.

  • Dynamic Event Handling:
    Adding event listeners to dynamically generated product cards required careful handling. I overcame this by creating a dedicated addProductEventListeners() function that runs after each render, ensuring all interactive elements have proper event handlers.

  • Responsive Image Implementation:
    The design required different images for mobile, tablet, and desktop. I solved this using the <picture> element with <source> media queries, allowing the browser to automatically select the appropriate image based on screen size.

  • Modal Accessibility:
    Creating an accessible modal with proper focus management was complex. I addressed this by implementing focus trapping, ARIA attributes, keyboard navigation (ESC to close), and preventing body scroll when the modal is open.

  • CSS Grid Layout Challenges:
    Making the layout work smoothly from mobile to desktop required careful planning. I used CSS Grid for the main container and products grid, with proper fallbacks and responsive breakpoints to ensure the layout adapts gracefully.

  • Real-time Cart Updates:
    Synchronizing quantity changes between product cards and cart display required precise state management. I solved this by creating helper functions that update both the visual state and internal data simultaneously.

The project taught me the importance of planning state management upfront and building reusable, accessible components from the start rather than retrofitting them later.

What specific areas of your project would you like help with?

Looking at this Product List with Cart project, here are the specific areas where I'd appreciate feedback or help:

Performance & Optimization Areas:

  1. State Management Architecture
    The current global cart array and direct DOM manipulation pattern works but could be more scalable. Should I implement a more structured state management pattern like a reducer or observer pattern for better predictability?

  2. Event Listener Memory Management
    I'm re-attaching event listeners every time addProductEventListeners() runs after re-rendering. Is there a more efficient way to handle dynamic event delegation without potential memory leaks?

  3. Image Loading Strategy
    Currently using responsive <picture> elements, but with 9 products each having 4 image variants (36 images total), should I implement lazy loading or image preloading strategies for better performance?

Accessibility & UX Concerns:

  1. Screen Reader Experience
    The cart quantity updates use aria-live="polite" but I'm unsure if the screen reader experience is optimal when rapidly changing quantities. Should I debounce the announcements?

  2. Focus Management in Modal
    Basic focus trapping is implemented, but should I add more sophisticated focus management like cycling through focusable elements with Tab/Shift+Tab?

Code Quality Questions...
6. Error Handling Robustness
The fetch for data.json has basic error handling, but should I add retry logic, loading states, or more graceful fallbacks for network failures?

  1. CSS Grid Responsiveness:
    The layout works well from mobile to desktop, but should I add more intermediate breakpoints or use container queries for better adaptation to various screen sizes?

Specific Code Review Request:
I'd particularly appreciate feedback on the updateCartDisplay() and renderCartItems() functions - are they doing too much work and should they be split into smaller, more focused functions?

These are the areas where I feel the implementation could be improved for better maintainability, performance, and user experience.

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 Jonathan Peters'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.