Building Reusable Post Components

Overview

This lesson explains how to design and implement reusable post components — compact, accessible, and SEO-friendly card-like blocks that represent user posts, articles, or listings. Reusable components speed up development, improve consistency across interfaces, and are ideal for CMS-driven sites where thousands or millions of posts are rendered from templates.

Why reusable post components matter for real businesses

Consistency: A single component ensures uniform visual language across product pages, blogs, and feeds.
Efficiency: Developers and editors reuse the same markup and styles — fewer mistakes, faster publishing.
Performance: Smaller, predictable DOM structures are easier to optimize for loading speed and caching.
SEO & discoverability: Structured content and accessible markup help search engines index content reliably.
Scalability: When your site grows to thousands of posts, components make maintenance and A/B testing straightforward.

Design goals for the component

Keep the component:

Semantically correct (use headings, time, author markup).
Accessible (keyboard focus, ARIA where needed).
Visually simple and brand-consistent (use primary & secondary colors).
Small and responsive (works on mobile and desktop).
Easy to plug into any templating system (server or client rendered).

Complete example: HTML + CSS + small JS for counters

Copy this component into your CMS template. It uses semantic HTML, demonstrates brand colors (green primary, wood-like light brown secondary), and includes accessible attributes.

<!-- Post Card Component -->
<article class="post-card" role="article" aria-label="Post card">
  <header class="post-card-header">
    <h2 class="post-title">How to reduce page load time on heavy JavaScript pages</h2>
    <p class="post-meta">
      <span class="post-author">By Jane Doe</span>
      <time datetime="2025-10-19" class="post-date">Oct 19, 2025</time>
    </p>
  </header>

  <div class="post-excerpt">
    <p>A practical guide to profiling and splitting JavaScript bundles, lazy-loading non-critical code, and improving Lighthouse scores.</p>
  </div>

  <footer class="post-card-footer">
    <ul class="icons-list" role="list" aria-label="Post interactions">
      <li>
        <button class="icon-btn" aria-label="Likes">
          <svg width="16" height="16" viewBox="0 0 24 24" aria-hidden="true">...</svg>
          <span class="icon-number">120</span>
        </button>
      </li>
      <li>
        <button class="icon-btn" aria-label="Comments">
          <svg width="16" height="16" viewBox="0 0 24 24" aria-hidden="true">...</svg>
          <span class="icon-number">35</span>
        </button>
      </li>
      <li>
        <button class="icon-btn" aria-label="Shares">
          <svg width="16" height="16" viewBox="0 0 24 24" aria-hidden="true">...</svg>
          <span class="icon-number">18</span>
        </button>
      </li>
    </ul>
  </footer>
</article>

Small JS example to increment counters (for client-side demos). In a real CMS, counts should come from the backend.

<script>
document.addEventListener('click', (e) => {
  const btn = e.target.closest('.icon-btn');
  if(!btn) return;
  const number = btn.querySelector('.icon-number');
  if(number){
    const value = parseInt(number.textContent || '0', 10);
    number.textContent = value + 1;
  }
});
</script>

How to integrate into real CMS workflows (practical examples)

Here are anonymized, generic scenarios showing how businesses use the component:

News Portal: The editorial CMS renders a post-card for each story on listing pages. Editors update the excerpt and image in the CMS; developers reuse the same template across category pages.
Online Marketplace: Product listings use the same card structure (title, seller, stats). Frontend engineers adapt the component to fetch and display dynamic metrics (views, saves, purchases).
Educational Platform: Course lessons and user submissions are presented as cards; instructors can approve content and the component shows counts for likes and comments to prioritize moderation.

Accessibility & SEO best practices

Apply these rules to make components search-engine friendly and usable:

Use semantic HTML: <article>, <header>, <time>, <h2> for titles — search engines use these for indexing.
Provide datetime on <time> elements for precise indexing and rich snippets.
Keep interactive elements keyboard-focusable (button over clickable <div>).
Include ARIA labels for icon-only buttons to explain their purpose to screen readers.
Lazy-load images and heavy media (use loading="lazy") to improve page speed.

Performance tips

Keep components small — avoid embedding large inline SVGs repeatedly; use symbol/sprite or external files.
Cache numeric metrics server-side and update asynchronously to avoid blocking page render.
Use CSS variables for brand colors so you can theme components globally.
Minify and bundle CSS/JS used by the component, but avoid bundling rarely used code into the critical path.

Variant patterns and extension ideas

Common ways to extend the base component without breaking reuse:

Compact variant: For sidebars or widgets — show only title and counts.
Media variant: Add a thumbnail image (use <figure> and <img> with alt text).
Promoted variant: Add a badge (e.g., "Sponsored" or "Editor’s pick") while keeping markup the same.

Testing checklist

Before publishing the component to production, verify:

Screen reader navigation — headings and buttons are announced correctly.
Keyboard navigation — tab order and focus states behave predictably.
Responsive appearance — mobile, tablet, and desktop breakpoints.
SEO rendering — server-side metadata and <time> elements are present.
Performance — Lighthouse score for the template page is acceptable for your users.

Copy-ready templates for editors

Provide CMS editors with small editable fields so they can reuse the component without editing code:

title — post title
author — author display name
date — published date
excerpt — short summary or teaser
likes/comments/shares — numeric metrics maintained by the backend

Editors can paste the excerpt into the CMS WYSIWYG; content managers should avoid editing structural classes.