Lists & Dynamic Rendering

When building the POS system's inventory interface, I wasn't displaying one or two productsโ€”I was rendering hundreds of menu items, retail products, and variations across multiple restaurant locations and retail stores. Hardcoding each <ProductCard /> would have been impossible. I needed to dynamically generate UI from data arrays.

This is where React's list rendering becomes critical. Whether you're displaying 10 products or 10,000, the pattern is the same.

The Problem: Too Much Repetition

Imagine rendering just 5 products manually:

function ProductCatalog() {
  return (
    <div>
      <ProductCard name="Mohinga" price={3500} stock={24} category="Breakfast" />
      <ProductCard name="Shan Noodles" price={4000} stock={15} category="Lunch" />
      <ProductCard name="Tea Leaf Salad" price={3000} stock={0} category="Appetizer" />
      <ProductCard name="Samosa" price={1500} stock={45} category="Snack" />
      <ProductCard name="Mandalay Noodles" price={3800} stock={12} category="Lunch" />
    </div>
  );
}

Now imagine 500 products. Impossible to maintain. What if prices change? What if you need to add a product?

The Solution: Map Over Arrays

JavaScript's .map() method transforms arrays. In React, we use it to transform data arrays into component arrays:

What's happening:

  1. products.map() iterates over each product

  2. For each product, we return a <ProductCard /> component

  3. We spread the product data as props

  4. key={product.id} helps React track which items changed (more on this soon)

Understanding Keys

Notice the key prop? It's required when rendering lists. Let's understand why.

Why Keys Matter

When your list changes (items added, removed, or reordered), React needs to figure out what changed. Keys help React identify which items changed.

Without keys:

With keys:

Key Rules

โœ… Use unique, stable IDs

โŒ Don't use array index (usually)

Why is index bad? If items reorder, the index changes, but React thinks it's the same item. This causes bugs with state and performance issues.

When index is okay: If your list never reorders, filters, or changes, index is fine. But 99% of the time, use IDs.

Real Example from POS System

In my POS, products come from the Inventory Service with UUIDs:

Passing Whole Objects as Props

Instead of spreading individual properties, pass the entire object:

The ProductCard component receives it:

Filtering Lists

In the POS system, users filter products by category, availability, or price range. This is just array filtering before rendering:

The pattern:

  1. Store filter state (selectedCategory)

  2. Filter the array before mapping: products.filter(...)

  3. Map over the filtered array

  4. Show empty state if no results

Multiple Filters

Real-world apps often have multiple filters. Here's a more complex example from the POS:

Sorting Lists

In the POS admin panel, I needed to sort products by name, price, or stock level:

Important: [...products].sort() creates a copy before sorting. Never mutate props or state directly!

Nested Lists

Sometimes you need nested lists. In the POS, products are grouped by category:

Key points:

  • Outer loop uses category as key

  • Inner loop uses product.id as key

  • Each level needs unique keys within its scope

Conditional Rendering in Lists

Display different components based on data:

Empty States

Always handle empty lists gracefully:

Or inline:

Complete Example: POS Product Catalog

Here's the full implementation from the POS system:

Key Learnings

โœ… List Rendering Pattern

โœ… Keys Are Required

  • Use unique, stable IDs

  • Don't use array index (usually)

  • Keys must be unique among siblings

โœ… Filter Before Mapping

โœ… Sort Creates New Array

โœ… Always Handle Empty States

  • Show helpful message when array.length === 0

  • Guide users on what to do next

Common Mistakes I Made

โŒ Forgetting keys

โŒ Using index as key with dynamic lists

โŒ Mutating array before rendering

โŒ Not handling empty arrays

Next Steps

We can now render dynamic lists of products, but users still can't search or filter by typing. In the POS system, the search bar is the most-used featureโ€”users type product names to find items quickly.

Next, we'll learn about forms and user input, building a search interface with controlled components and validation.

Continue to: Forms & User Input

Last updated