repeated-component-alignment

Solid

Any component rendered many times — cards, list rows, table cells, nav items, tiles, KPI widgets, feed entries — is a fixed slot model, not a free-form box. The same slots appear in the same place in every instance and stay aligned across siblings even when text and values vary in length. Reserve space for optional slots, pin anchor elements (CTA, price, value), clamp overflowing text, and give the full value back via title/tooltip. Use when building or reviewing any repeated component whose content length differs between instances.

Web & Frontend 54 stars 9 forks Updated yesterday MIT

Install

View on GitHub

Quality Score: 87/100

Stars 20%
58
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Repeated Component Alignment When a component is rendered many times — a card grid, a list, a table, a nav menu, a row of KPI tiles, a feed — it stops being a single box and becomes a **pattern**. The value of a pattern is rhythm: the eye learns the layout once and scans the same slot across every instance (the title row, the price row, the action row). Variable content length breaks that rhythm unless the component is built to absorb it. The principle is general. A **card** is the most common case, but the same rule governs list rows, table cells, nav items, tiles, comment entries, dashboard widgets, search results — anything repeated. Treat each as a **fixed slot model**, not a free-form container. The goal: **content of any length, instances that look identical.** This is partly content production (write to a target length) and partly layout engineering (build slots that tolerate the variance). This skill covers the layout half and where the two meet. --- ## The Slot Model Name the slots once and treat them as a contract every instance honours. A product card, as a worked example: ``` ┌──────────────────────┐ │ [media] │ ← fixed aspect ratio │ │ ├──────────────────────┤ │ ● Badge │ ← optional slot, space reserved │ Title │ ← clamp to N lines │ Subtitle / meta │ │ │ │ Description text… │ ← flexible slot, grows │ │ ├──────────────────────┤ │ €19.99 ...

Details

Author
dembrandt
Repository
dembrandt/dembrandt-skills
Created
4 months ago
Last Updated
yesterday
Language
JavaScript
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

design-patterns

Flutter design patterns — Composition, Repository, MVVM, Strategy, Observer, Singleton, Factory. Use when user asks "implement pattern", "use composition", or when designing reusable features.

1 Updated today
IuliaIvanaPatras
Web & Frontend Solid

layout-paradigms-and-consistency

A layout is not a neutral container — choosing the right layout paradigm (feed, board, table, canvas, master-detail, dashboard, gallery, timeline, map, single-focus, narrative long-scroll) is a design decision that shapes how content is understood. Landing and marketing pages get a product narrative framework — hook, problem, USP, value props, proof points, how it works, stakes, CTA — used to review whether the page carries a visitor to a decision. Once chosen, the same paradigm and page skeleton must be reused consistently across the application so users build one mental model. This is consistency at the macro scale, above component and token consistency. Use when deciding the overall structure of a screen, designing page templates, or reviewing whether screens across a product feel like one coherent application.

54 Updated yesterday
dembrandt
Web & Frontend Solid

component-family-consistency

Buttons, inputs, pills, badges, calendars, and other interactive components form a visual family — they share the same border-radius, colour logic, shadow scale, border style, and spacing rhythm. Inconsistency between them breaks the sense of a coherent product. Use when building or reviewing a component library, design system, or any set of UI components.

54 Updated yesterday
dembrandt