Black Swan Bistro — Part 3

Refactor Repeated Patterns into Components

Tutorial Introduction

This part is a refactor lesson. You are not starting the bistro site again. You are taking the Part 2 homepage and making its repeated structures more consistent, easier to reuse, and easier to extend.

That matters because the next major project step is multi-page structure. If every card, footer link, and call-to-action is slightly different before you create more pages, those small differences multiply quickly. A calm refactor now saves mess later.

What You Will Build

By the end of this lesson, your bistro homepage should still look familiar, but the code underneath it should be cleaner. You will create reusable structures for:

• the site header and navigation
• menu and featured-dish cards
• call-to-action sections
• the site footer
• shared component CSS that can be used again in Part 4

Refer back to the Project Brief

Open the Black Swan Bistro Project Brief again before you refactor. Look at the wireframes and identify which elements repeat across pages.

Those repeated areas become your reusable components. Header patterns, menu cards, footer groups, CTA sections, and repeated headings are all easier to recognise when you compare the homepage to the menu, about, and contact layouts in the brief.

What Component Refactoring Means Here

In this lesson, a component means a repeatable HTML pattern with CSS that supports it. It is not a Vue component, React component, or custom element. Those tools can come later. First, you need the underlying thinking.

A useful component has three parts:

• a stable outer wrapper, such as .menu-card
• named internal parts, such as .menu-card__title and .menu-card__meta
• flexible content that can change without changing the component structure

Step 1: Create a Pattern Inventory

Before writing new code, scan your Part 2 homepage and list the repeated patterns. This prevents you from inventing components too early. You only refactor what the page has already shown you it needs.

Step 2: Define Component Contracts

A component contract is a small agreement with yourself: this pattern has a name, these are its internal parts, and this is the kind of content it expects. The contract keeps the component predictable when you reuse it later.

For example, a menu card might use this contract:

<article class="menu-card">
  <p class="menu-card__eyebrow">Chef favourite</p>
  <h3 class="menu-card__title">Charred pumpkin risotto</h3>
  <p class="menu-card__description">
    Roasted pumpkin, sage, parmesan, and toasted pepitas.
  </p>
  <p class="menu-card__price">$28</p>
</article>

The exact food changes. The structure does not. That is the point.

Step-by-Step Refactor

Now move through the homepage one pattern at a time. Keep the changes small. A good refactor should make the code clearer without changing everything at once.

1. Refactor the Navigation

The navigation is one of the most important reusable structures because it will appear on every page in Part 4. Start by making the header structure consistent.

<header class="site-header">
  <div class="container site-header__inner">
    <a class="site-logo" href="index.html">Black Swan Bistro</a>

    <nav class="site-nav" aria-label="Main navigation">
      <ul class="site-nav__list">
        <li><a class="site-nav__link" href="index.html">Home</a></li>
        <li><a class="site-nav__link" href="menu.html">Menu</a></li>
        <li><a class="site-nav__link" href="about.html">About</a></li>
        <li><a class="site-nav__link" href="contact.html">Contact</a></li>
      </ul>
    </nav>
  </div>
</header>

Notice the class names. They describe the pattern itself, not where it happens to sit on the homepage. That makes the same structure easier to reuse on future pages.

2. Refactor Menu and Featured-Dish Cards

In Part 2, you may have used a broad class like .card. That is useful for early layout, but now the bistro has a more specific repeated pattern: .menu-card.

<div class="menu-card-grid">
  <article class="menu-card">
    <p class="menu-card__eyebrow">Seasonal</p>
    <h3 class="menu-card__title">Southwest gnocchi</h3>
    <p class="menu-card__description">
      Potato gnocchi, roasted capsicum, basil oil, and parmesan.
    </p>
    <p class="menu-card__price">$26</p>
  </article>

  <article class="menu-card">
    <p class="menu-card__eyebrow">Signature</p>
    <h3 class="menu-card__title">Black swan linguine</h3>
    <p class="menu-card__description">
      Squid ink pasta, prawns, chilli, lemon, and herbs.
    </p>
    <p class="menu-card__price">$32</p>
  </article>
</div>

The grid arranges the cards. The card component owns the internal structure. Keep those jobs separate.

3. Refactor Call-to-Action Blocks

CTA blocks usually combine a heading, a short explanation, and a link. They may look different depending on where they appear, but the structure is often similar.

<section class="section cta-block">
  <div class="container cta-block__inner">
    <div>
      <p class="eyebrow">Bookings</p>
      <h2 class="cta-block__title">Reserve a table for this weekend</h2>
      <p class="cta-block__text">
        Join us for local produce, thoughtful wine, and a relaxed dining room.
      </p>
    </div>

    <a class="button" href="contact.html">Book now</a>
  </div>
</section>

You do not need to turn every section into a complex component. This is a light component: consistent enough to reuse, simple enough to understand.

4. Refactor the Footer

The footer is another shared site pattern. It should not be rebuilt differently on each page later. Give it the same treatment as the header: a stable wrapper, internal layout, and named parts.

<footer class="site-footer">
  <div class="container site-footer__inner">
    <p class="site-footer__brand">Black Swan Bistro</p>

    <ul class="site-footer__links">
      <li><a href="menu.html">Menu</a></li>
      <li><a href="about.html">About</a></li>
      <li><a href="contact.html">Contact</a></li>
    </ul>
  </div>
</footer>

Organise the Component CSS

Component refactoring is not only about HTML. Your CSS should also show the difference between global foundations, layout helpers, and components.

/* 1. Foundations */
:root {
  --color-cream: #f7efe2;
  --color-ink: #1f1b18;
  --color-red: #8f2f23;
  --space-4: 1rem;
  --space-6: 1.5rem;
}

/* 2. Layout helpers */
.container { width: min(1100px, 92%); margin: 0 auto; }
.section { padding: 3rem 0; }

/* 3. Components */
.site-header { border-bottom: 3px solid var(--color-red); }
.site-header__inner {
  display: flex;
  justify-content: space-between;
  align-items: center;
  gap: var(--space-4);
  flex-wrap: wrap;
}

.menu-card {
  display: grid;
  gap: 0.75rem;
  padding: var(--space-6);
  background: white;
  border: 1px solid rgba(31, 27, 24, 0.18);
}

Component Accessibility Check

Reusable code can spread good decisions or bad decisions. Before you reuse these patterns in Part 4, check the basics:

• Navigation uses a real <nav> element with an accessible label.
• Navigation links are real links, not clickable <div> elements.
• Headings stay in a sensible order inside cards and sections.
• Interactive links and buttons have visible hover and focus states.
• Card content still makes sense if the CSS does not load.

Prepare the Site for Part 4

Part 4 expands the bistro into a multi-page site. Before moving on, your homepage should have a small set of shared patterns ready to copy into the next pages.

Short Recap

In Part 3, you turned visible repetition into reusable structure. The goal was not to make Black Swan Bistro more complicated. It was to make the code more honest about what the page already contains: repeated navigation, repeated cards, repeated calls to action, and repeated footer content.

That gives the project a stronger foundation. When you add more pages, you will not be inventing the header, footer, and card structure from scratch each time.

Student Reflection Questions

1. Which repeated pattern was easiest to refactor into a component?
2. Which component needs the clearest internal class names to stay readable?
3. Where did separating layout CSS from component CSS make the code easier to understand?
4. What should stay the same when a component is reused on another page?