Coder Legion - Recent posts tagged components

The BOM Is a Technical Document, Not Just a Shopping List

Fri, 28 Aug 2026 09:35:53 +0000

When a prototype works, teams often freeze the BOM too early. The electrical value may be correct, but the package, temperature grade, lifecycle status, approved vendor, moisture sensitivity, and replacement rules are still undefined. That is where many production delays begin.

What a production-ready line should contain
For each critical component, record the manufacturer part number, package and footprint, electrical limits, temperature grade, compliance requirements, lifecycle status, approved sources, and acceptable alternates. For capacitors and inductors, include voltage, ripple current, bias or saturation behavior, and tolerance. For semiconductors, add gate charge, thermal resistance, switching limits, and any firmware or configuration dependency.

The word “equivalent” is not enough. A substitute can match the pinout and still have a different RDS(on), gate threshold, startup time, leakage current, thermal path, or protection behavior. Qualification should compare footprint, electrical limits, functional behavior, thermal performance, and compliance evidence.

This is especially important for power switches and connectors. A MOSFET selection reference can help organize the initial search, but the final decision must use the converter waveform, junction-temperature estimate, and gate-drive conditions from the real design.

Add lifecycle risk before the purchase order
A BOM review should ask four questions:

Is the part active, NRND, EOL, or already obsolete?
Is the quoted lead time based on normal stock or allocation?
Can an alternate be approved without a PCB respin?
Which parts must be bought through an authorized channel with lot traceability?
The answers affect design, procurement, and manufacturing at the same time. MOZPCB’s component-sourcing workflow describes a useful approach: identify hard AVL lines, flag long-lead and lifecycle risks, document approved substitutes, and verify the kit against the released BOM before assembly.

Small markings can cause large errors
Prototype repair work also exposes a basic problem: many SMD components are tiny or unmarked. A resistor marked 472 is 4.7 kΩ under the common three-digit code, while an MLCC may have no marking at all. EIA-96 codes add another layer of interpretation. When the board, BOM, and placement file disagree, measure the part and verify the manufacturer data rather than guessing. The SMD resistor code calculator is a quick cross-check for common markings.

Design for the assembly process
A good BOM is connected to the assembly drawing, centroid file, stencil notes, polarity rules, DNP lines, MSL handling, and inspection plan. For fine-pitch or mixed-technology boards, the manufacturing package should state the intended reflow sequence and the acceptance criteria for AOI, X-ray, and functional test. PCB assembly guidance is relevant when the design is moving from a hand-built prototype to a repeatable small-batch process.

Finally, keep a change record. When a part is replaced, record why it changed, what was tested, and which production revisions are affected. A BOM that captures those decisions becomes a reliability tool—not just a list of prices.

References
Octatronics technical resources
MOZPCB component sourcing

Beyond CSS-in-JS: From Element Styles To Component Themes

Wed, 26 Aug 2026 04:30:40 +0000

I started Fluentic Style with a small idea:

I wanted React Native-style composition in React web.

<View style={[base, active && activeStyle, props.style]} />

That kind of style composition always felt practical to me.

You have a base style.
You add another style when some state is active.
You still let styles come from props.

So the first Fluentic idea looked like this:

<div css={[base, active && selected, props.css]} />

That was the starting point.

I wrote about it here:

Bringing React Native Style Composition to React

But the more Fluentic evolved, the clearer it became that the real problem was never just CSS-in-JS or build-time extraction.

What felt missing was a better pattern for component-level styling, and for theming that can move from app-wide defaults down to a specific component.

The bigger question became:

Can a styling system cover the everyday path from styling one element, to styling reusable components, to component themes, to app-wide themes, while still keeping debugging and production extraction usable?

That is the version of Fluentic I am building now.

Not just another CSS-in-JS syntax.

More like an attempt to connect the parts of styling that often feel split apart.

The Problem Is Not Only Putting CSS In JS

CSS-in-JS gave frontend developers something useful.

It made styles feel closer to components.
It made dynamic styling easier.
It made local styling easier.
It made React UI feel less split between a component file and a separate stylesheet.

But daily app styling is bigger than:

How do I put CSS on this DOM element?

That is one layer.

A real app usually moves through several layers:

element style
component style
component variant
component theme
app-wide theme
production output
debugging

Many styling approaches are good at one or two of those.

Some are great for quick element styles.
Some are great for app-wide tokens.
Some are great for utility classes.
Some are great for local CSS files.
Some are great for runtime dynamic values.
Some are great for extracted CSS.

But in real app work, I kept wanting those layers to connect better.

That became the bigger Fluentic goal:

style composition from elements, to components, to component themes, to app-wide themes

without turning each layer into a separate styling system.

Start With One Element

The smallest case should stay small.

If I only need to style one element, I should be able to write one style and attach it.

import { style } from '@fluentic/style';

const saveButton = style({
  borderRadius: 8,
  padding: '8px 12px',
});

<button css={saveButton}>Save changes</button>;

If that element needs hover, media, or state styles, it should still stay attached to the same style idea:

const saveButton = style({
  borderRadius: 8,
  padding: '8px 12px',
}).hover({
  backgroundColor: '#f3f4f6',
});

<button css={saveButton}>Save changes</button>;

For teams that like utility-class authoring, Fluentic can also work closer to that style:

const saveButton = cx(
  'inline-flex',
  'items-center',
  'rounded-md',
  'px-3',
  'py-2',
).hover('bg-slate-100');

<button css={saveButton}>Save changes</button>;

So Fluentic does not start by forcing every use case into components, themes, or design-system structure.

Sometimes you just need to style an element.

That should be easy.

Then The Element Becomes A Component

The next problem appears when that styled element becomes reusable.

A button is not always just one DOM node.

It can have parts:

function Button(props) {
  return (
    <button>
      <span>{props.icon}</span>
      <span>{props.children}</span>
    </button>
  );
}

Now the styling question changes.

There is a root.
There is an icon.
There is a label.

Maybe a loading indicator.
Maybe an action area.
Maybe a wrapper around some third-party element.

Frontend teams already think in these names:

root, icon, label, content, trigger, item, control, thumb, track, portal

The old HTML/CSS way would usually name those parts with classes:

.button { ... }
.button__icon { ... }
.button__label { ... }
.button[data-danger] .button__label { ... }

That is understandable.

But in a component system, the component owns the inside.

So when the outside needs to style those parts, React APIs often grow shapes like this:

<Button
  className="danger-button"
  iconClassName="danger-icon"
  labelClassName="danger-label"
>

or:

<Button
  classes={{
    root: 'danger-button',
    icon: 'danger-icon',
    label: 'danger-label',
  }}
>

or:

<Button
  styles={{
    label: { fontWeight: 700 },
  }}
>

These are practical. I have written APIs like this many times.

But the repeated shape is clear:

the component has parts, and outside code needs a supported way to style those parts

Fluentic’s answer is style.slot(...).

A slot is a normal style for the component itself, but it also gives that component part an identity that outside styles can target later.

const buttonStyles = {
  root: style.slot({
    borderRadius: 8,
    padding: '8px 12px',
  }),

  icon: style({
    flex: '0 0 auto',
  }),

  label: style.slot({
    fontWeight: 700,
  }),
};

Notice that not every internal element needs to be a slot.

icon can stay private with style(...).

root and label become public styling targets with style.slot(...).

That is the first important split:

use style(...) for ordinary element styles
use style.slot(...) when a component part should be styleable from outside

Component Themes Are Not The Same As App Themes

Once a component exposes slots, outside code needs a way to provide styles for those slots.

That is where style.scope(...) comes in.

A scope groups changes for public component parts:

const dangerButton = style.scope([
  buttonStyles.root({
    backgroundColor: '#dc2626',
  }),

  buttonStyles.label({
    color: 'white',
  }),
]);

The component receives that as a theme-like input:

type ButtonProps = {
  children: React.ReactNode;
  icon?: React.ReactNode;
  theme?: StyleTheme;
};

Then the component prepares the styles it will render:

function Button(props: ButtonProps) {
  const css = combineStyle(
    buttonStyles,
    bindScope(buttonStyles.root, props.theme),
  );

  return (
    <button css={css.root}>
      {props.icon ? <span css={css.icon}>{props.icon}</span> : null}
      <span css={css.label}>{props.children}</span>
    </button>
  );
}

This is different from passing a raw class name into each part.

The outside says what it wants to change:

<Button theme={dangerButton}>Delete</Button>

The component still decides where those styles attach.

That is why I think of scopes as component-facing themes.

They are not only global colors.

They can change slots, tokens, states, media rules, and multiple component parts together.

App-Wide Themes Need A Different Layer

App-wide theming is related, but it is not exactly the same problem.

Sometimes the app wants to define shared values:

const color = createTokens({
  surface: '#ffffff',
  text: '#111827',
  accent: '#2563eb',
  danger: '#dc2626',
});

A style can use those tokens:

const page = style({
  backgroundColor: color.surface,
  color: color.text,
});

Then an app theme can override those token values:

const darkTheme = createTheme([
  color.surface('#0f172a'),
  color.text('#f8fafc'),
]);

That is app-facing theming.

It answers:

What should surface, text, or accent mean in this part of the app?

A component theme answers a different question:

How should this component’s public parts or component-specific tokens change?

Fluentic supports both.

Use createTheme(...) when the theme only changes token values.

Use style.scope(...) when the theme needs to affect component slots, component tokens, states, media conditions, or multiple parts together.

This distinction matters because app-wide themes and component themes often live in different realms.

A design system may define app tokens.

A component library may expose component tokens and slots.

An app may need to map app values into component values.

For example:

const button = createTokens({
  color: {
    surface: '#2563eb',
    surfaceHover: '#1d4ed8',
    text: '#ffffff',
  },
});

const appButtonTheme = style.scope([
  button.color.surface(color.accent),
  button.color.surfaceHover(color.accent),
  button.color.text('#ffffff'),
]);

The app theme controls what color.accent means.

The component theme says how the button should use that app value.

That is the kind of bridge I wanted Fluentic to support.

Not app theming over here, component theming over there, and manual glue in between.

One styling path that can connect them.

Variants Become Scopes Too

Component variants are usually where styling logic starts getting busy.

A variant like this looks simple:

<Button size="sm" tone="danger" />

But internally it may affect several parts:

root padding
label font size
icon size
background color
hover color
disabled color

Without a shared styling shape, that often becomes a matrix of class names or conditionals.

In Fluentic, a variant can be a scope:

const compactButton = style.scope([
  buttonStyles.root({
    gap: 6,
    paddingBlock: 6,
    paddingInline: 10,
  }),

  buttonStyles.label({
    fontSize: 13,
  }),
]);

const dangerButton = style.scope([
  buttonStyles.root({
    backgroundColor: '#dc2626',
  }),

  buttonStyles.label({
    color: 'white',
  }),
]);

And because scopes are values, they compose:

<Button
  theme={[
    compact && compactButton,
    danger && dangerButton,
    props.theme,
  ]}
>
  Delete
</Button>

This is where Fluentic starts feeling bigger than element-level CSS-in-JS.

The same composition idea can move from:

<div css={[base, active && selected]} />

to:

<Button theme={[compact && compactButton, danger && dangerButton]} />

The shape stays familiar.

The layer changes.

Debugging Still Has To Follow The Whole Path

A nice authoring API is not enough if generated CSS becomes a dead end.

That is one of the places where I think styling tools often ask developers to accept too much friction.

You write nice code.

DevTools shows generated class names or injected CSS.

Then you have to guess where the rule came from.

Fluentic emits atomic CSS, but not only for output size or dedupe.

Atomic CSS also gives a useful debugging unit:

one generated rule can map back to one styling decision

For example:

style({
  backgroundColor: '#2563eb',
}).hover({
  backgroundColor: '#1d4ed8',
});

A generated hover background-color rule should be able to point back to the backgroundColor inside .hover(...).

For slots and scopes, the trace should stay meaningful too.

If this wins:

const dangerButton = style.scope([
  buttonStyles.label({
    color: 'white',
  }),
]);

the generated color rule should be able to lead back to the scoped label override.

That is why Fluentic keeps debug metadata and sourcemap information in development.

The debug story should follow the same path:

style → slot → scope → generated CSS → source trace

If component styling is part of the model, debugging component styling has to be part of the model too.

Production Extraction Should Fit The Same Model

The other big requirement is production.

A runtime-only CSS-in-JS library can be convenient, especially in small apps.

But production apps need more.

They need extracted CSS.
They need SSR and framework integrations.
They need predictable output.
They need the runtime to do less work when the build can prepare things ahead of time.

Fluentic’s compiler and bundler plugins extract the static style declarations from patterns like:

style(...)
style.slot(...)
style.scope(...)

and emit extracted atomic CSS plus prepared JavaScript output.

But real apps still have runtime-known choices:

<Button
  theme={[
    compact && compactButton,
    danger && dangerButton,
    props.theme,
  ]}
>
  Delete
</Button>

The build can prepare CSS from the style declarations.

The runtime still resolves which themes, scopes, token values, and prop-driven choices apply during render.

That is important.

I do not want a system where extracted CSS only works for the boring cases, and the moment a component becomes dynamic you move to a different styling model.

The goal is one authoring model:

build extracts what can be prepared
runtime resolves what the app decides while rendering

Syntax Should Be Flexible, But The Path Should Stay Connected

CSS-in-JS discussions often become syntax discussions.

Objects.
Tagged templates.
Utility classes.
Inline styles.
Generated classes.
CSS files.

I understand why. Syntax is what developers touch every day.

Fluentic started object-first:

const card = style({
  padding: 16,
  borderRadius: 12,
});

But Fluentic now also supports Tailwind-like class-name authoring:

const card = cx('rounded-xl', 'bg-white', 'p-4');

It also supports Tailwind-style object presets and custom transforms.

A design system can create its own vocabulary:

const panel = ui({
  row: true,
  center: true,
  gapX: 12,
});

The point is not that every team should write styles the same way.

The point is that different syntaxes can still feed the same Fluentic path.

Once they become Fluentic styles, they can still participate in:

element styling
slots
scopes
token themes
component themes
atomic CSS output
production extraction
sourcemaps
debug metadata

That is the practical reason custom transforms matter.

They are not only a syntax trick.

They let a team adapt the authoring vocabulary without leaving the rest of the styling system behind.

Frameworks Need Bridges, Not A New Styling Model

Fluentic started with React.

React is still the main focus.

But modern frontend is not only one JSX/runtime story.

Next.js App Router brings server components, server/client rendering, HMR, streaming concerns, development CSS, sourcemaps, and production extraction.

SolidJS has its own compiler-centered JSX path.

Preact has a different prop shape.

So Fluentic is moving toward a stable styling core with framework-specific bridges.

React can use Fluentic’s JSX runtime, or it can use a cssProp compiler transform.

Next.js gets a deeper integration for App Router, RSC development styling, debug CSS, sourcemaps, and production extraction.

SolidJS client-side support uses a css prop transform before Solid’s compiler.

The goal is:

keep the style path stable, adapt the framework handoff

That keeps Fluentic from being only a React runtime library.

The style ideas can stay the same while the JSX integration changes per framework.

What Fluentic Currently Has

Fluentic Style is still new and currently in beta.

But it already covers much more than my first small idea.

Authoring:

style(...) object styles
cx(...) class-name authoring
Tailwind-like class-name preset
Tailwind-style object preset
custom style functions
custom transforms

Element and component composition:

css prop arrays
conditional styles
style.slot(...) for public component parts
style.scope(...) for component themes and slot overrides
combineStyle(...)
bindScope(...)

Theming:

createToken(...)
createTokens(...)
createTheme(...) for token-only themes
style.scope(...) for component themes, slot overrides, and token mapping

Build and debug:

atomic CSS in development and production
production CSS extraction
prepared JavaScript output
debug metadata
sourcemap support
development utilities for inspecting generated styles

Frameworks:

React
Next.js App Router
SolidJS client-side support
Preact-oriented adapter path

That is far beyond the original idea.

The first goal was:

bring React Native-style composition to React web

The current goal is closer to:

make everyday styling composition work from element styles to component styles to component themes to app-wide themes, with debugging and production output still part of the same story

That is the part that keeps me building it.

Closing

I do not think existing CSS-in-JS approaches are wrong.

I do not think CSS is broken.

A lot of styling approaches are useful, and I still use many familiar patterns.

Fluentic is my attempt to connect the parts that I kept seeing split apart:

quick element styling
component styling
component theming
app-wide theming
style composition
generated CSS debugging
production extraction
framework integration
flexible authoring syntax

It is still beta, and I expect the API to keep improving.

But the direction is clear now.

Fluentic is no longer only my attempt to bring React Native-style arrays to React web.

It is an attempt to make styling feel more complete for component-based apps: from one element, to a reusable component, to local component themes, to app-wide themes, while still caring about CSS output, DevTools, production builds, and framework realities.

Useful links:

11+ Shadcn Combobox Components for Better Searchable Experience

Mon, 22 Jun 2026 13:45:32 +0000

Selecting an option from a dropdown sounds simple until your application needs to handle hundreds of records, users, countries, timezones, or categories.

Traditional select components work well for small lists, but they quickly become difficult to use as your data grows. Users end up scrolling through endless options, slowing down workflows and creating unnecessary friction.

That's where a combobox becomes a better choice.

A combobox combines a searchable input field with a dropdown menu, allowing users to find and select options faster. Instead of manually browsing a long list, users can simply type a few characters and instantly narrow down the results.

For React and Next.js developers, Shadcn UI provides a flexible foundation for building modern combobox experiences. Since the components are fully customizable, you can adapt them to match your application's design system while maintaining accessibility, keyboard navigation, and excellent user experience.

In this collection, you'll find some of the Best Shadcn Combobox components for modern web applications, including:

Searchable dropdowns
Country selectors with flags
User selection comboboxes
Multi-select checkbox comboboxes
Timezone pickers
Virtualized comboboxes for large datasets
Linear-inspired combobox patterns
Advanced filtering interfaces

Whether you're building a SaaS dashboard, admin panel, internal tool, onboarding flow, or customer-facing application, these Shadcn Combobox examples can help you create faster and more intuitive selection experiences.

Let's explore the best Shadcn Combobox components you can use in your next React or Next.js project.

Combobox with Icons

A searchable combobox that combines text labels with visual icons, helping users identify options faster without reading every item.

Icons improve recognition and make selections more intuitive, especially when working with tools, technologies, categories, or branded options.

Best For

Technology stack selection
Feature categorization
Product management dashboards
Tool and platform selectors

Key Features

Icon support inside dropdown items
Faster visual recognition
Searchable option list
Customizable item rendering
Accessible keyboard navigation

👉 Live Preview

Custom Country Check Icon Combobox

A country picker designed with custom selection indicators that provide clearer visual feedback than standard checkmarks.

This pattern helps users quickly confirm their selection while maintaining a clean and polished interface.

Best For

Registration forms
Billing and checkout flows
User onboarding
International applications

Key Features

Custom selected-state icon
Searchable country list
Clear visual confirmation
Mobile-friendly interaction
Tailwind CSS customization support

👉 Live Preview

Combobox with Add Button

This combobox combines option selection with item creation, allowing users to add new entries directly from the dropdown interface.

Instead of forcing users to leave the form, they can create and select items in a single workflow.

Best For

Tag management systems
CRM applications
Category creation workflows
Dynamic form builders

Key Features

Built-in add action
Quick item creation
Search and selection support
Reduced form friction
Improved workflow efficiency

👉 Live Preview

Timezone Combobox

Selecting a timezone can be challenging when hundreds of options are available. This combobox simplifies the experience with searchable timezone data and organized results.

It's an essential component for scheduling systems, booking platforms, and globally distributed applications.

Best For

SaaS applications
Scheduling platforms
Meeting management tools
Remote team software

Key Features

Searchable timezone database
Fast filtering
Global timezone coverage
User-friendly selection experience
Optimized for large option sets

👉 Live Preview

User Selection Combobox

A user-focused combobox that displays avatars, names, and selection indicators to make team management workflows more intuitive.

This pattern is commonly used in dashboards where users need to assign tasks, projects, permissions, or responsibilities.

Best For

Team collaboration tools
Project management software
Task assignment workflows
Admin dashboards

Key Features

Avatar support
User profile display
Searchable member directory
Clear selected states
Scales well for large teams

👉 Live Preview

Country Combobox with Flags

A country selector enhanced with flag icons to improve recognition and reduce selection errors.

Visual cues help users identify countries faster compared to text-only dropdowns.

Best For

Signup forms
Profile management pages
Shipping and billing forms
International SaaS products

Key Features

Country flag support
Searchable country list
Fast country lookup
Clean dropdown layout
Improved international UX

👉 Live Preview

Virtualized Shadcn Combobox

Built for performance, this combobox uses virtualization to efficiently render thousands of options without slowing down the interface.

Only visible items are rendered, making it ideal for large datasets and enterprise applications.

Best For

Enterprise dashboards
Large databases
Analytics platforms
Internal business tools

Key Features

Virtualized rendering
Smooth scrolling experience
Handles massive datasets
Reduced memory usage
High-performance filtering

👉 Live Preview

Downshift Selection Combobox

A multi-select combobox powered by Downshift that provides advanced keyboard interactions and flexible selection patterns.

Users can select multiple items using checkbox-based interactions while maintaining accessibility standards.

Best For

Reporting filters
Search refinement panels
Settings pages
Data exploration tools

Key Features

Checkbox multi-selection
Accessible keyboard controls
Advanced filtering support
Flexible customization
Supports complex selection workflows

👉 Live Preview

Shadcn Linear Combobox

Inspired by Linear's clean interface design, this combobox focuses on speed, clarity, and minimal visual distractions.

The result is a streamlined selection experience that feels modern and highly responsive.

Best For

Task management apps
Productivity tools
Issue tracking systems
Modern SaaS dashboards

Key Features

Linear-inspired UI
Minimal visual design
Fast interaction patterns
Priority and status selection
Optimized user experience

👉 Live Preview

Multiple Selection Checkbox

Selecting multiple options should feel fast, not overwhelming. This multiple selection checkbox combobox allows users to search, filter, and select several items from a single dropdown without cluttering the interface.

Unlike traditional multi-select fields, selected items remain easy to manage, making it ideal for admin dashboards, filters, permissions management, and team assignment workflows.

Best For

User role management
Product filters
Category assignment
Tag selection systems

Key Features

Multi-select checkbox interface
Search and filter support
Clear selected state indicators
Keyboard accessible navigation
Works well with large datasets

This pattern is commonly used in SaaS dashboards where users need to select multiple records without leaving the current screen.

👉 Live Preview

Multiple Expandable Checkbox

When options are grouped into categories, a standard combobox can become difficult to navigate. This expandable checkbox combobox organizes selections into collapsible sections, helping users find what they need faster.

It's particularly useful for settings pages, advanced filters, and permission management systems where options naturally belong to different groups.

Best For

Settings panels
Permission management
Advanced filtering
Product configuration screens

Key Features

Expandable option groups
Nested checkbox selection
Better organization for large option sets
Improved discoverability
Mobile-friendly interaction

For applications with dozens or hundreds of selectable options, grouped expansion provides a cleaner and more scalable experience.

👉 Live Preview

Multiple Count Badge Combobox

This combobox improves multi-selection UX by displaying selected item counts directly inside the trigger. Instead of showing long lists of selected values, users immediately understand how many items have been chosen.

The count badge pattern keeps forms compact while maintaining clear feedback during the selection process.

Best For

Analytics dashboards
Reporting filters
Customer segmentation tools
Project management applications

Key Features

Dynamic selection count badge
Compact trigger design
Supports large multi-select lists
Clear visual feedback
Optimized for dashboard interfaces

This approach is especially useful when users frequently select multiple items and need a clean interface that scales gracefully.

👉 Live Preview

Final Thoughts

A well-designed combobox can significantly improve how users interact with your application. Instead of forcing users to scroll through long lists, comboboxes make searching, filtering, and selecting options faster and more intuitive.

Whether you're building a SaaS dashboard, admin panel, onboarding flow, project management tool, or customer-facing application, choosing the right combobox pattern can enhance usability while keeping your interface clean and efficient.

From simple searchable dropdowns and country selectors to advanced multi-select, virtualized, and user assignment comboboxes, Shadcn UI provides the flexibility to create experiences that fit your exact requirements.

The examples featured in this collection demonstrate how a combobox can go beyond basic selection and become a powerful part of your application's workflow. With full Tailwind CSS customization, accessibility support, and seamless React and Next.js integration, these components are ready for production use.

If you're looking to build faster, more user-friendly forms and dashboards, these Shadcn Combobox components are an excellent place to start.

Looking for More Shadcn Combobox Components?

Explore this growing collection of Shadcn Combobox examples, templates, and reusable components designed for React, Next.js, SaaS applications, admin dashboards, and modern web projects.

Modern Shadcn Collapsible Components for React & Next.js

Wed, 10 Jun 2026 09:16:29 +0000

A lot of developers get confused between collapsible & Accordion these two because visually they can look very similar. If you build dashboards or website with React, you’ve probably faced this problem.

A page starts simple, then more settings, filters, notes, and details get added. Before long, the interface feels crowded and harder to navigate.

That's where a collapsible component becomes useful.

Instead of showing everything at once, you can hide secondary content and let users expand it only when needed. The result is a cleaner interface without losing important information.

Good UI isn't about showing less content. It's about showing the right content at the right time.

Collapsible vs Accordion

Many developers use these terms interchangeably, but they're slightly different.

Collapsible → shows or hides a single content section
Accordion → manages multiple sections as a group

If you only need a simple expand/collapse interaction, a collapsible component is often the better choice.

A Few Tips from Real Web Projects

The component itself is simple, but small details can make it feel much better to use.

Here are a few things I usually keep in mind:

Use clear trigger labels like "Show More" or "View Details"
Add an icon so users know whether the section is expanded or collapsed
Keep animations fast and subtle
Don't hide information users need immediately
Avoid deeply nested collapsible sections
Keep the behavior consistent across your app

These small improvements make the UI feel more predictable and easier to navigate.

Popular Shadcn Collapsible Examples

These are some practical collapsible patterns that work well in React and Next.js applications.

RTL Collapsible

A collapsible component designed for Right-to-Left (RTL) languages such as Arabic, Hebrew, and Persian.

This variation follows RTL layout conventions, ensuring content, icons, and interactions feel natural for users reading from right to left.

Features

RTL language support
Proper icon and content alignment
Accessible keyboard navigation
Works seamlessly with shadcn/ui RTL configuration

Best for: Arabic, Hebrew, Persian, and multilingual React or Next.js applications.

A button that reveals extra actions or options.

Useful for:

filters
quick actions
compact controls

Folder Tree Collapsible

You can build simple explorer-like interfaces using nested collapsibles.

Great for:

CMS
admin tools
documentation viewers

Settings with Advanced Options Collapsible

Instead of overwhelming users with too many inputs, hide advanced settings.

Clean UI + better usability.

⬇️ Download the Code

Secret Keys / Sensitive Data Collapsible

Perfect for things like:

API keys
tokens
secrets

Users can reveal only when needed.

Changelog / Updates Collapsible

Instead of showing all updates at once, let users expand specific versions.

Cleaner and easier to scan.

Very common in dashboards.

You keep the sidebar compact, but still support deeper navigation levels.

⬇️ Download the Code

Collapsible Card

This collapsible component that lets users expand or collapse content with a click. Use the header icon to toggle visibility and keep your UI clean and organized.

⬇️ Download the Code

Basic Show / Hide Collapsible

The simplest use case.

Works well for:

FAQs
short descriptions
extra notes

Nested Collapsible (Grouped Content)

When you have structured data like:

categories
grouped settings
multi-level items

This pattern scales nicely.

⬇️ Download the Code

Where You'll Actually Use Collapsible Components

Once you start noticing them, you'll see collapsible sections everywhere.

They're commonly used in:

Dashboard interfaces
Admin panels
Internal company tools
Settings and preference pages
Documentation websites
Content-heavy screens with lots of details

Any time you need to show extra information without overwhelming users, a collapsible component is usually a good fit.

Why I Use Collapsible So Often

In most real projects, not everything needs to be visible all the time.

Collapsible helps to:

Reduce visual clutter
Keep important content upfront
Let users explore details when they want
Avoid modals for small interactions

It’s a small component, but it solves a big UX problem.

Final Note

Collapsible isn’t a fancy component but it’s one of the most useful ones.

It helps you design interfaces that feel lighter without removing information.

If you’re building with shadcn/ui, this is something you’ll end up using again and again.

Want More Shadcn Collapsible Components ?

If you're building with shadcn/ui, try experimenting with different layouts and combinations.

You can reuse the same collapsible logic across many use cases.

Check out more modern Shadcn Collapsible components to use in your projects.

Built Collapsible components ?

If you’ve built any interesting collapsible patterns, I’d love to see how you’re using them in your projects.

Share it with me on:

I’d love to review it and feature it here.

Searching Shadcn Blocks, Components & Templates for Your Projects

Here are some useful resources from the Shadcn ecosystem:

Building This Blog: A Modern Next.js Blog with Markdown

Tue, 21 Apr 2026 21:12:52 +0000

Building This Blog: an MDX‑powered Next.js blog

This blog is a small, opinionated setup for writing long‑form content that feels good to read and fun to build on.

Under the hood it uses static generation, MDX, and a theme‑aware UI that works in both light and dark modes.

Everything after the frontmatter is pure MDX. Components like Callout, Steps, architecture diagrams, flows, and charts are all React components rendered directly in the post body.

Stack I ended up with

I wanted something fast, simple, and easy to reason about over years—not weeks.

The site is a static App Router app. Routes like `/blog/[slug]`, `/til/[slug]`, `/technical-terms/[slug]` are statically generated at build time.


TypeScript keeps the content layer and components honest. Tailwind + CSS variables handle layout and theming.


All long‑form content lives in the repo inside content/, written as `.md` or `.mdx` files with frontmatter.


Views, upvotes, and UTM events are stored in Supabase and surfaced through a custom analytics dashboard.

How content works

All posts are simple files in the repo—no CMS required.

---
title: "Your Post Title"
description: "Post description"
date: "2024-01-20"
author: "Your Name"
tags: ["tag1", "tag2"]
category: "Category"
featured: true
---

Your content here...

Markdown (.md) posts go through a Remark pipeline and are rendered as HTML.
MDX (.mdx) posts are compiled at runtime in the page using next-mdx-remote/rsc, with a shared component map.

For posts that need diagrams, flows, or charts, I use .mdx and drop in components like ArchitectureCard, FlowStep, and DemoBarChart.

Authoring flow

Add a new `.md` or `.mdx` file to content/blog/ with frontmatter for SEO, tags, and images.


Run npm run dev and iterate on copy, diagrams, and layout until the post feels polished.


Push to the main branch. The build step generates static HTML for every route and updates search data + OG images.

Architecture of the blog

At a high level, the blog is just three pieces: browser, Next.js, and Supabase.

Readers get fully rendered HTML from the CDN, with minimal JavaScript on top for upvotes, analytics, and small interactions.


Next.js statically generates pages for blog posts, TIL entries, technical terms, and lists. It also exposes a few API routes for analytics.


Supabase stores per‑page views, upvotes, and UTM events that feed the analytics dashboard and charts.

Request–response flow for a page view

Here’s how a single blog page view flows through the system.

The CDN serves a pre‑rendered HTML page that was generated at build time.


Next.js hydrates the page; components like the upvote button, custom cursor, and view counter start working.


A lightweight request records the view / upvote in Supabase without blocking the reader.


Aggregated stats are used to power Recharts visualizations on the analytics page.

Visualizing traffic with charts

The same Recharts setup used in the analytics dashboard is available inside MDX posts.

Charts are plain React components exposed to MDX. They respect the global theme and use the same accent palette as the rest of the site.

Performance before and after

Static export plus small tweaks around assets made a noticeable difference in user‑facing numbers.

Why this setup works for me

Files as the source of truth – I can write posts in a text editor, version them in git, and refactor them like any other code.
Static by default – Most pages are static HTML, which is great for speed and reliability.
MDX when I need power – Architecture diagrams, flows, and charts are just components; I only reach for them when a post really needs them.
Theme‑aware UI – Components use the same CSS variables as the rest of the app, so they look good in both light and dark modes.

If you want to explore the implementation details, the full source code is on GitHub. You could clone it, point it at your own content folder, and have a similar blog running in minutes.

Atomic Design methodology: deconstructing web design into core components for cohesive, scalable systems

Mon, 19 May 2025 18:19:23 +0000

In this article, learn how to deconstruct interfaces into core components, creating unified, scalable systems using Brad Frost's Atomic Design methodology to enhance your web design skills effectively!

What is Atomic Design?

What never ceases to amaze me in tech is that when I discover something new, like a language, framework, or methodology, the people credited with its creation are still with us and working in the industry!

Brad Frost is one such individual who has significantly impacted the design community with his concept of Atomic Design. This methodology revolutionizes how we approach web design by breaking down interfaces into their fundamental building blocks, or "atoms." Doing so allows designers and developers to create more cohesive and scalable design systems. Atomic Design simplifies the design process and ensures consistency across various platforms and devices. Brad's work continues to influence modern design practices, demonstrating the lasting impact of innovative thinkers in the tech industry.

Atoms

Atoms are the most basic building blocks in Atomic Design. They are the smallest user interface elements, such as buttons, labels, input fields, and icons. Think of them as the fundamental pieces that you can combine to create more complex components.

In web design, atoms are like HTML tags—simple and standalone. Focusing on atoms ensures consistency and reusability across your design system. For example, a button atom can be styled once and used throughout your entire project, maintaining a uniform look and feel. Understanding atoms is crucial because they form the foundation for more complex components.

Molecules

Molecules are groups of atoms bonded together, serving as the next step in building a user interface. They combine two or more atoms to form a more complex component that maintains a simple function. For example, a search form molecule might consist of an input field atom and a button atom.

By grouping atoms into molecules, you create more functional and interactive components. Molecules help organize your design system by providing reusable patterns that can be used across different project parts. They are essential for building consistent and efficient interfaces, allowing you to manage and update multiple atoms simultaneously.

Above is an image of the header section of our Elfgorithm App, which consists of an SVG icon and a styled text element. This combination forms a molecule in the context of Atomic Design. The header is structured as follows:

The <header> element is styled with padding and flexbox properties to align its child elements (the icon and text) horizontally.
The SVG icon, representing a gift, is styled with specific dimensions, colors, and rounded corners to visually stand out.
The text element is styled with bold, italic, and specific color properties, with a portion of the text having a different color and weight for emphasis.

This cohesive unit serves a specific function, demonstrating how molecules in Atomic Design combine multiple atoms to create more complex and functional components.

Organisms

Organisms are more complex components in Atomic Design. They are composed of groups of molecules and/or atoms working together to form a distinct section of an interface. Organisms represent a more substantial part of the UI, such as a navigation bar, a product listing, or a user profile section. Organisms are crucial for creating structured and functional layouts, combining various smaller components to serve a specific purpose.

Using organisms, you can build more dynamic and interactive parts of your application, ensuring that the design remains consistent and scalable. They also allow you to manage and update multiple molecules and atoms collectively, making it easier to maintain the overall design system.

The image above illustrates an organism within the context of Atomic Design. This section, titled "How It Works," combines multiple molecules into a cohesive unit that serves a specific purpose. Each step in the process (Create a Group, AI Matches & Suggests, Enjoy the Exchange) is a molecule, consisting of a number icon, a heading, and a descriptive paragraph.

The entire section, with its heading and grid layout, forms a distinct part of the user interface, explaining the process in a structured and functional manner. This combination of multiple molecules into a larger, interactive layout is characteristic of an organism, representing a more substantial part of the UI.

Templates

Templates are a key part of Atomic Design. They represent page-level objects that place components into a layout and demonstrate the design's underlying content structure. They are essentially a combination of organisms, molecules, and atoms arranged to form a cohesive layout. Templates focus on the page's structure rather than the specific content, allowing you to see how different components fit together.

Using templates ensures that your design system is flexible and adaptable, accommodating various content types while maintaining a consistent layout. This helps visualize the final product's appearance and function, providing a blueprint for building actual pages.

Pages

Pages are the final stage in Atomic Design, where templates are filled with real content to create a fully functional and complete user interface. They represent specific instances of templates, showcasing how the design system looks and behaves with actual data.

Pages are crucial for testing the effectiveness of your design system, as they allow you to see how all the components work together in a real-world scenario. By using pages, you can ensure that your design is both visually consistent and functional as well as user-friendly. They provide a comprehensive view of the final product, helping you identify any issues or improvements needed before deployment.

“Atomic Design” by Brad Frost—An Event Apart Austin 2015

Brad Frost introduces atomic design, a methodology that breaks down interfaces into their basic elements to create scalable and maintainable design systems.

Real-World Use Case

AI: Work smarter, not harder! Effectively using AI as a tool rather than a substitute for your work is an excellent method to maximize efficiency without increasing effort!

Our tech lead, Shashi Lo, understands the proper use of AI and allows us to use it while we build our project. However, it comes with a caveat: you must be able to understand and explain to him how the AI-generated code works! Fair enough.

I was tasked with creating a Google Doc that organizes our forty components and counting, labeling each individual component as an Atom, Molecule, or Organism.

Since the main goal is to write documentation for each component, and we were waiting for this clarification before we began, I utilized AI to analyze each component and categorize them as Atoms, Molecules, or Organisms. This demonstrates the effectiveness of proper component naming conventions, as the AI successfully sorted them all accordingly.

However, it was not enough just to have AI label each component; I needed to understand why each component was labeled as it was. So, I took the AI assistance further and asked it to write definitions for each component.

Using AI as a tool in this manner saved our team time on the mundane task of manually labeling each component as Atoms, Molecules, or Organisms. With the Google Doc completed, with all the labeled components and their definitions, we can quickly approve or disapprove each labeled component and update if necessary, allowing us to finish this task and start the components documentation!

About Us

What is Gridiron Survivor?

Gridiron Survivor is an apprenticeship program created by Shashi Lo, a Senior UX Engineer at Microsoft. It aims to provide developers entering the tech industry with vital work experience. The program focuses on practical training in project management, coding practices, and team collaboration, offering mentorship and skills essential for success in their initial tech roles.

What is the Elfgorithm App?

Elfgorithm is an AI-driven Secret Santa app set to launch in winter 2025. It streamlines gift exchanges by removing the guesswork from Secret Santa activities. The app manages gift-giving details and provides personalized gift suggestions, ensuring you find the perfect presents for everyone.

Gridiron Survivor Sponsors

A very special thanks to our sponsors!

GitKraken: A popular Git client that provides a graphical interface to manage Git repositories. It is known for its user-friendly design and features that simplify version control, making it easier for developers to collaborate and manage their code.
Frontend Mentor: An online platform that offers front-end coding challenges. It helps developers improve their skills by providing real-world projects to work on, along with a supportive community for feedback and learning.
Vercel: A cloud platform for static sites and serverless functions. It is designed to optimize the workflow of developers by providing tools for building, deploying, and scaling modern web applications with ease. Vercel is known for its seamless integration with frameworks like Next.js.

Be sure to listen to the HTML All The Things Podcast!

I also write articles for the HTML All The Things Podcast, which you can read on their website: https://www.htmlallthethings.com/.

Be sure to check out HTML All The Things on socials!

Affiliate & Discount Links!

With CodeMonkey, learning can be all fun and games! CodeMonkey transforms education into an engaging experience, enabling children to evolve from tech consumers to creators. Use CodeMonkey's FREE trial to unlock the incredible potential of young tech creators!

With a structured learning path tailored for various age groups, kids progress from block coding to more advanced topics like data science and artificial intelligence, using languages such as CoffeeScript and Python. The platform includes features for parents and teachers to track progress, making integrating coding into home and classroom settings easy.

Through fun games, hands-on projects, and community interaction, CodeMonkey helps young learners build teamwork skills and receive recognition for their achievements. It fosters a love for coding and prepares children for future career opportunities in an ever-evolving tech landscape.

To learn more about CodeMonkey, you can read my detailed review article!

Affiliate Links:

Advance your career with a 20% discount on Scrimba Pro using this affiliate link!

Become a hireable developer with Scrimba Pro! Discover a world of coding knowledge with full access to all courses, hands-on projects, and a vibrant community. You can read my article to learn more about my exceptional experiences with Scrimba and how it helps many become confident, well-prepared web developers!

Important: This discount is for new accounts only. If a higher discount is currently available, it will be applied automatically.

How to Claim Your Discount:

Click the link to explore the new Scrimba 2.0.
Create a new account.
Upgrade to Pro; the 20% discount will automatically apply.

Disclosure: This article contains affiliate links. I will earn a commission from any purchases made through these links at no extra cost to you. Your support helps me continue creating valuable content. Thank you!

Conclusion

Brad Frost's atomic Design methodology offers a structured approach to building cohesive and scalable design systems. It starts with Atoms, the smallest building blocks, such as buttons and icons, which provide consistency and reusability across the design. Moving up, Molecules are formed by combining atoms to create more functional components, like a search form. Organisms take it further by grouping molecules and atoms into larger, functional interface sections, such as navigation bars.

Templates then arrange these components into page-level structures, focusing on layout rather than specific content. Finally, Pages brings templates to life by filling them with real content, resulting in a complete and testable user interface.

By following these principles, designers and developers can create efficient, consistent, and user-friendly interfaces that work seamlessly across various platforms!

Coder Legion - Recent posts tagged components

The BOM Is a Technical Document, Not Just a Shopping List

Beyond CSS-in-JS: From Element Styles To Component Themes

The Problem Is Not Only Putting CSS In JS

Start With One Element

Then The Element Becomes A Component

Component Themes Are Not The Same As App Themes

App-Wide Themes Need A Different Layer

Variants Become Scopes Too

Debugging Still Has To Follow The Whole Path

Production Extraction Should Fit The Same Model

Syntax Should Be Flexible, But The Path Should Stay Connected

Frameworks Need Bridges, Not A New Styling Model

What Fluentic Currently Has

Closing

11+ Shadcn Combobox Components for Better Searchable Experience

That's where a combobox becomes a better choice.

Combobox with Icons

Custom Country Check Icon Combobox

Combobox with Add Button

Timezone Combobox

User Selection Combobox

Country Combobox with Flags

Virtualized Shadcn Combobox

Downshift Selection Combobox

Shadcn Linear Combobox

Multiple Selection Checkbox

Multiple Expandable Checkbox

Multiple Count Badge Combobox

Final Thoughts

Looking for More Shadcn Combobox Components?

Modern Shadcn Collapsible Components for React & Next.js

Collapsible vs Accordion

A Few Tips from Real Web Projects

Popular Shadcn Collapsible Examples

RTL Collapsible

Features

Dropdown Styled Collapsible

Folder Tree Collapsible

Settings with Advanced Options Collapsible

Secret Keys / Sensitive Data Collapsible

Changelog / Updates Collapsible

Sidebar Navigation (Collapsible Menu)

Collapsible Card

Basic Show / Hide Collapsible

Nested Collapsible (Grouped Content)

Where You'll Actually Use Collapsible Components

Why I Use Collapsible So Often

Final Note

Want More Shadcn Collapsible Components ?

Built Collapsible components ?

Searching Shadcn Blocks, Components & Templates for Your Projects

Building This Blog: A Modern Next.js Blog with Markdown

Building This Blog: an MDX‑powered Next.js blog

Stack I ended up with

How content works

Authoring flow

Architecture of the blog

Request–response flow for a page view

Visualizing traffic with charts

Performance before and after

Why this setup works for me

Atomic Design methodology: deconstructing web design into core components for cohesive, scalable systems

In this article, learn how to deconstruct interfaces into core components, creating unified, scalable systems using Brad Frost's Atomic Design methodology to enhance your web design skills effectively!

What is Atomic Design?

Atoms

Molecules

Organisms

Templates

Pages

“Atomic Design” by Brad Frost—An Event Apart Austin 2015

Real-World Use Case

About Us

What is Gridiron Survivor?

What is the Elfgorithm App?

Gridiron Survivor Sponsors

My other related articles

Be sure to listen to the HTML All The Things Podcast!

I also write articles for the HTML All The Things Podcast, which you can read on their website: https://www.htmlallthethings.com/.

Be sure to check out HTML All The Things on socials!