Build components that stay simple

A reusable component should make the next piece of work easier to understand. That usually starts with a clear responsibility and a small public API.

Build the concrete version first

It is easier to find a useful abstraction after a real example exists. Build the card, use it in a second place, and notice which differences actually matter.

A blog card might need a title, summary, date, and destination. It probably does not need a configuration object describing every possible arrangement of those pieces.

Keep content separate from presentation

When content has a consistent shape, several views can use it without duplicating information. The homepage can show a short selection while the archive shows the whole collection.

type PostSummary = {
  title: string;
  description: string;
  slug: string;
};

The type explains what the view needs. The component decides how that information appears.

Let repetition earn an abstraction

Two components that look similar may have different responsibilities. Sharing a border style is easy. Sharing an API that must support unrelated behavior can make both components harder to change.

Prefer a little repetition over an abstraction whose purpose is still unclear. Extract the stable part once the real boundary becomes visible.