DEV Community: Kushagra Dhawan

Kookie Blocks: Higher-Level Components for Kookie UI

Kushagra Dhawan — Fri, 20 Feb 2026 07:59:00 +0000

Kookie Blocks is a collection of pre-built patterns on top of Kookie UI. Same design system, one layer higher.

The Gap

Kookie UI gives you primitives. Buttons, cards, inputs, sidebars, shells. These are the building blocks, and they work well. But every time I started a new project, I found myself rebuilding the same patterns.

Documentation sites need a shell with a sidebar, a content area, and a table of contents. The sidebar needs sections, navigation items, search. The content area needs proper typography, code blocks with syntax highlighting, component previews. The table of contents needs to track scroll position and highlight the current section.

AI interfaces need streaming markdown. Rendering markdown is straightforward. Rendering markdown that's still being written is not. Incomplete syntax mid-stream. Re-renders on every token. Code blocks that flicker because the closing backticks haven't arrived yet. Bold text that breaks because the second ** hasn't come through.

Marketing pages need heroes, footers, testimonials. These aren't complex, but they take time to get right every time.

I kept building these patterns from scratch. Each project started with the same work before I could get to the actual product.

The Solution

Kookie Blocks is that layer between primitives and products. It takes Kookie UI's components and composes them into patterns you can use directly.

The blocks fall into a few categories.

Marketing. Hero, Footer, Testimonial. The pieces you need for a landing page. Drop them in, pass your content, done.

Application. Page Header, Section Header, Empty State. Common UI patterns that show up in almost every app. Consistent layout, consistent spacing, consistent typography.

AI. This is where some of the harder problems live.

Markdown Components creates component mappings for react-markdown and MDX using Kookie UI components. Headings, paragraphs, code blocks, lists, tables, all styled with Kookie UI's typography and spacing. Use this utility to render markdown content that looks like it belongs in your app.

Streaming Markdown handles the hard parts of rendering AI-generated content. It handles incomplete markdown gracefully during streaming. Block-level memoization means completed blocks don't re-render when new tokens arrive. The component is designed for real-time updates where content is still being written.

Documentation. This is the most complete category.

Code Block handles syntax highlighting, copy buttons, line numbers, language labels. Docs Shell provides the overall layout for a documentation site. Docs Sidebar handles navigation with sections, items, and collapsible groups. Docs Page structures content with proper spacing and typography. Table of Contents tracks scroll position and highlights the current section. Preview Block displays live component previews with customizable backgrounds, perfect for showcasing UI components in documentation.

The Interconnectedness

This is the part I find interesting.

Kookie UI provides Shell, a layout primitive for application frames. Kookie Blocks uses that Shell to build Docs Shell, adding the specific layout and behavior documentation sites need.

Kookie UI provides Sidebar, a flexible navigation component. Kookie Blocks uses that Sidebar to build Docs Sidebar, adding documentation-specific patterns like section grouping and active state tracking.

Then Kookie UI's own documentation site is built with Kookie Blocks.

The libraries feed into each other. Kookie UI is the foundation. Kookie Blocks builds on it. Then Kookie UI uses Kookie Blocks for its own docs. Kookie Blocks uses Kookie Blocks for its own docs. Kookie Flow uses Kookie Blocks for its docs.

When I improve something in Kookie UI, it flows up into Kookie Blocks. When I improve something in Kookie Blocks, all the documentation sites get better. When I'm building docs and notice something missing, I add it to Kookie Blocks, and every other docs site gets it too.

This wasn't planned from the start. It emerged as I kept building. But it's become one of the things I like most about this setup. The system is self-reinforcing. Each piece makes the others better.

Where It's Used

Kookie Blocks powers the documentation for Kookie UI, Kookie Blocks itself, and Kookie Flow. My portfolio site uses pieces of it. Kookie AI uses the streaming markdown and markdown components.

Every time I build something new, the patterns go into Kookie Blocks. Every project that uses Kookie Blocks gets those patterns for free.

Still Extremely Early

Everything is in alpha. The APIs are still changing. Some blocks are more complete than others. The documentation blocks are fairly mature because I've been using them heavily. The marketing blocks are newer and less tested.

I'm still figuring out the right abstractions. Where should the boundaries be? How much should each block do? How flexible versus how opinionated? These questions don't have obvious answers, and I'm learning as I go.

But it's already saving me time. Instead of rebuilding a docs site from scratch, I import Docs Shell and Docs Sidebar and start writing content. Instead of solving streaming markdown again, I use the component that already handles it. Instead of styling code blocks for the fifth time, I use Code Block.

That's the point. Solve the pattern once, use it everywhere.

kookieblocks.com

github.com/KushagraDhawan1997/kookie-blocks

Kookie User Interface: Building my own Design System

Kushagra Dhawan — Tue, 17 Feb 2026 10:05:55 +0000

I was using Radix Themes every day, and it did a lot of things right. It gave me components that were accessible out of the box, strong defaults, and a toolkit that let me move fast. The components worked reliably, the API felt intuitive, and I could trust that what I built would function for users. As I used it for real products, I found myself needing different choices: different patterns, different design decisions, and different opinions about how a design system should work.

KookieUI began as a fork of Radix Themes. I took the infrastructure they built and changed what sits on top of it. The underlying system remained, but I made considerable changes to the design layer: the tokens, the patterns, the opinions about spacing, sizing, theming, and component behavior. It's about taking something that works well and reshaping it to match how I think design systems should function.

The Gap

Radix Themes is a complete design system with its own opinions. Where I differed was in those opinions.

When I started using it for real applications, I noticed places where I wanted different choices:

Variants needed unification. A "surface" card looked different from a "surface" button. The shadows meant different things across components. The visual language needed consistency. Some components had "classic" variants, others had different options. The system needed clear rules for when to use what.
Theming needed extension. Radix had a panelBackground token for cards and tables. Dialogs, popovers, and dropdowns needed their own theming approach. The system needed per-component control so every surface could match the theme intentionally.
Sizing needed alignment. Each component had its own scale: cards went up to 5, buttons to 4, dropdowns to 3, selects to 2, avatars to 12. A size-1 button inside a size-1 card needed to feel related. The proportions needed to be systematic across all components.
Motion needed consistency. Some transitions, like segmented controls, felt smooth and polished. Others, like tabs, snapped instantly with no easing. The system needed a consistent motion language.
Accessibility needed enforcement. The core accessibility was excellent. Screen readers worked, keyboard navigation was solid. Icon buttons needed enforced aria-labels. Tooltips needed to be native. Icons needed consistent sizing across components.

Radix Themes delivered a complete system with its own choices. KookieUI is my version of those choices, built on the same infrastructure but shaped differently.

The System

KookieUI is a fork of Radix Themes with different design opinions. The infrastructure stays the same. What changed is the design layer.

Patterns before parts. I start with spacing, radius, shadow, color, typography, and motion. These rules apply everywhere, and components inherit them consistently. When you use a size-2 button, it uses the same spacing scale as a size-2 card. When you apply a "surface" variant, it means the same thing across every component.

Material system for backgrounds. I replaced panelBackground with material, a system that defines how components render against whatever background they sit on. Material is more flexible and works across more use cases.

At the theme level, you can decide: translucent or solid. This affects how the entire system feels.
At the component level, you can override defaults. A dialog might need to be more opaque than a dropdown.
Dialogs, panels, and buttons each get defaults that convey depth and elevation intentionally.

Unified tokens. Sizes, radii, typography weights, and color scales all match across components. Every scale is systematic and intentional. If you see a size-3 anywhere in the system, it means the same thing everywhere. This consistency makes the system predictable and learnable.

Accessibility enforced. Icon buttons require labels, enforced at the component level. Tooltips are native and built in. Screen reader and keyboard support from Radix are extended with the details that matter in day-to-day use. The accessibility is built in and enforced by the API.

Extended patterns and components. I added toggle buttons, toggle icon buttons, more typography weights, and layout primitives like shell, split view, and sidebars. Even new patterns like AI chat interfaces fit inside the same rules. The goal is to fill gaps where teams need patterns beyond what Radix Themes provided.

KookieUI makes components behave consistently, as if they were designed together as a coherent system.

At Womp

KookieUI started as my personal project. As I worked on it, I realized I could use it for Womp to solve real problems.

The migration is ongoing. Some areas of the product run on KookieUI, others are still being migrated. Even in this partial state, the benefits are clear.

Here's what changes when you have a system like this:

Speed. Engineers get design details from the system. Update the dependency, and the new design flows in automatically. Consistency conversations are eliminated. The system handles design coherence, so engineers focus on functionality.
Principles in code. Spacing and motion rules live in the system itself as defaults. When someone uses a component, they get the right spacing automatically. When they need to override it, the system guides them toward the right choices.
Direct contribution. I push design changes directly into KookieUI code, which means the team can move faster while maintaining polish. A design improvement I make on Monday can be in production by Tuesday, with full engineering implementation included.
Clear ownership. Through KookieUI, design controls the design layer. If something looks wrong, the system needs to encode it. That responsibility belongs to me as the consulting design lead. Engineers implement design from the system. This creates clarity.

The migration is uneven. Some areas look and feel more coherent than others. The trend is clear: KookieUI gives design a way to lead through code.

Still Learning

KookieUI continues to evolve. I'm still figuring out:

How to extend the system with new patterns while maintaining flexibility. Every new component I add has to fit the existing rules, but sometimes the rules need to evolve. Balancing consistency and flexibility is constant work.
How to refine motion and interaction so every component feels equally polished. Some components have smooth, thoughtful transitions. Others still feel a bit mechanical. Getting the motion language right across the entire system is harder than I expected.
How to keep the system flexible enough to evolve while remaining dependable. Teams need components that work predictably. They also need a system that can grow with their needs.

Some days it feels like too much structure. Other days there are still gaps. That tension is part of building a design system.

Closing

Radix Themes gave me a solid foundation. KookieUI is my fork with different opinions built on that foundation.

It's about noticing where I wanted different choices, and then implementing them. It's about codifying rules so design intent stays intact through implementation. It's about giving the design team a way to own how design shows up in the product through code. KookieUI remains open source because Radix Themes is open source.

KookieUI is early and uneven. Some parts feel mature and stable, others are experimental. Step by step, it's making Womp faster, more consistent, and more deliberate. The team moves quicker because design decisions are encoded and consistency is enforced. I can iterate on design directly in code.

That's enough reason for me to keep building.

New Component: Shell, a Layout Engine for Modern Apps

Kushagra Dhawan — Mon, 16 Feb 2026 09:28:26 +0000

Every application rebuilds the same layout. Sidebar on the left, maybe a header, content in the middle, perhaps an inspector panel on the right, sometimes a bottom panel for terminals or logs. Then you wire up the state—open, closed, pinned. Then responsive behavior—overlay on mobile, fixed on desktop. Then resize logic with drag handles and snap points.

It's 500-1000 lines of layout code that has nothing to do with your actual product.

I got tired of writing it.

What I Wanted

Declare your layout, don't build it.

I wanted to say "I need a sidebar that's overlay on mobile, fixed on desktop, resizable, with a thin icon-only mode" and have it work. Not wire up media queries, not manage state, not calculate positions. Just declare the intent.

<Shell.Root>
  <Shell.Sidebar
    presentation={{ initial: 'overlay', md: 'fixed' }}
    defaultState={{ initial: 'collapsed', md: 'expanded' }}
    resizable
  >
    <nav>Navigation</nav>
  </Shell.Sidebar>
  <Shell.Content>
    <main>Your app</main>
  </Shell.Content>
</Shell.Root>

That's what Shell does. It's a layout engine that handles the infrastructure so you can focus on what goes inside the boxes.

Seven Slots

Shell provides seven layout slots:

Header — Fixed top bar for global navigation
Rail — Slim icon strip (think VS Code's activity bar)
Panel — Expanded navigation that pairs with Rail
Sidebar — Unified sidebar (alternative to Rail+Panel)
Content — Main content area (required)
Inspector — Right-side panel for properties, details, context
Bottom — Bottom panel for terminals, logs, output

Why seven? Because these cover roughly 95% of application layouts I've seen. VS Code uses Header + Rail + Panel + Content + Bottom. Figma uses Header + Sidebar + Content + Inspector. Linear uses Sidebar + Content. Notion uses Sidebar + Content.

The slots are composable. Use what you need, ignore what you don't. Shell figures out the layout math.

The Hard Decision: Composition Rules

Early on, I had to decide: should Sidebar and Rail+Panel coexist?

They're solving the same problem—left-side navigation—in different ways. Sidebar is a unified component with three states (collapsed, thin, expanded). Rail+Panel is a two-part system where the Rail (icon strip) and Panel (expanded nav) are separate components.

Letting them coexist would create invalid states. What happens if Sidebar is expanded and Panel is also open? They'd overlap or fight for space.

So Shell enforces composition rules. Sidebar OR Rail+Panel, never both. If you try to use both, you get a console warning.

// Valid
<Shell.Root>
  <Shell.Sidebar>...</Shell.Sidebar>
  <Shell.Content>...</Shell.Content>
</Shell.Root>

// Valid
<Shell.Root>
  <Shell.Rail>...</Shell.Rail>
  <Shell.Panel>...</Shell.Panel>
  <Shell.Content>...</Shell.Content>
</Shell.Root>

// Invalid — triggers warning
<Shell.Root>
  <Shell.Sidebar>...</Shell.Sidebar>
  <Shell.Rail>...</Shell.Rail>
  <Shell.Content>...</Shell.Content>
</Shell.Root>

This was a deliberate constraint. Invalid states should be impossible, not just discouraged.

Three Presentation Modes

How should a sidebar interact with content? It depends.

Fixed — The sidebar takes space in the layout. When it opens, content shrinks. When it closes, content expands. This is what you want on desktop where screen space is abundant.

Overlay — The sidebar floats above content as a modal sheet. Content doesn't move. This is what you want on mobile where you can't afford to shrink already-limited content.

Stacked — The sidebar positions above content without a modal backdrop. For floating panels that don't demand attention.

The key insight: presentation should be responsive. A sidebar that's fixed on desktop should become overlay on mobile. So Shell accepts responsive objects:

<Shell.Sidebar
  presentation={{ initial: 'overlay', md: 'fixed' }}
  defaultState={{ initial: 'collapsed', md: 'expanded' }}
>

This says: "On mobile, start collapsed and use overlay presentation. On medium screens and up, start expanded and use fixed presentation."

The responsive behavior is colocated with the component. You're not hunting through CSS files to understand how the sidebar behaves at different breakpoints.

State Management

Each pane manages its own state: open/closed, size, presentation mode. But sometimes you need to control it programmatically.

Shell supports both controlled and uncontrolled patterns:

// Uncontrolled — Shell manages state
<Shell.Sidebar defaultState="expanded">

// Controlled — You manage state
const [state, setState] = useState<SidebarMode>('expanded');
<Shell.Sidebar state={state} onStateChange={(s, meta) => setState(s)}>

For common actions, Shell provides a trigger component:

<Shell.Trigger target="sidebar" action="toggle">
  <MenuIcon />
</Shell.Trigger>

And a hook for programmatic control:

const shell = useShell();
shell.togglePane('sidebar');
shell.expandPane('inspector');
shell.collapsePane('bottom');

Resize System

Resizable panels are table stakes for professional apps. But the details matter.

Shell's resize system includes:

Drag handles with proper cursor feedback
Keyboard navigation (arrow keys adjust size)
Snap points (drag near 300px and it snaps to exactly 300px)
Collapse threshold (drag below minimum and it auto-collapses)
Size persistence (remember size across sessions via localStorage)

<Shell.Sidebar
  resizable
  minSize={200}
  maxSize={400}
  snapPoints={[250, 350]}
  snapTolerance={8}
  collapseThreshold={150}
  paneId="main-sidebar"
>

When you provide paneId, Shell automatically creates a localStorage adapter for persistence. Sizes survive page refreshes without any additional code. If you need custom storage (database, state management), pass a persistence adapter with load and save methods.

The Inset Pattern

Modern apps often use floating panels—sidebars with rounded corners and shadows that sit above a gray backdrop. Slack, Linear, and others use this pattern.

Shell supports it with a single prop:

<Shell.Sidebar inset>
  <nav>Floating navigation</nav>
</Shell.Sidebar>

When any pane has inset:

Shell's body gets a gray backdrop
The pane gets margin (creating gaps from edges)
The pane gets rounded corners

The inset prop handles positioning. For visual treatment (background, shadow), use the child component's styling. This separation keeps concerns clean.

What I Learned

The hard part of Shell wasn't writing code. It was deciding the API surface.

Every prop is a decision. Do I expose this? Do I make it the default? Do I let users override it? Each decision has downstream consequences.

Some things I learned:

Defaults matter more than options. Most users won't configure anything. The defaults need to be sensible. Sidebar defaults to overlay on mobile, fixed on desktop. That's right for 80% of cases.

Constraints enable creativity. By enforcing composition rules, Shell prevents invalid states. Users don't have to think about what happens if Sidebar and Panel are both open. They can't be.

Responsive behavior should be colocated. Putting presentation={{ initial: 'overlay', md: 'fixed' }} on the component is better than scattering media queries across CSS files. The component documents its own behavior.

State callbacks need metadata. When onStateChange fires, you need to know why. Was it a user toggle? A responsive breakpoint change? An initialization? Shell passes a meta object with the reason: init, toggle, or responsive.

Where It's Used

Shell powers:

Kookie Blocks documentation site
Kookie AI (the chat interface I'm building)
My personal site

It's new. I'm still finding edge cases, still refining the API. But it's in production across these projects, handling real usage.

Shell + Sidebar

Shell handles layout—where things go, how they resize, how they respond to breakpoints. But it doesn't handle what goes inside the layout slots.

That's where Sidebar comes in. It's a separate presentational component for building navigation menus: groups, menu items, sub-menus, badges, keyboard shortcuts. It adapts between expanded (full panel) and thin (icon rail) presentations.

They're designed to work together:

<Shell.Root>
  <Shell.Sidebar
    presentation={{ initial: 'overlay', md: 'fixed' }}
    defaultState={{ initial: 'collapsed', md: 'expanded' }}
  >
    <Sidebar.Root presentation={sidebarMode === 'thin' ? 'thin' : 'expanded'}>
      <Sidebar.Header>
        <Logo />
      </Sidebar.Header>
      <Sidebar.Content>
        <Sidebar.Menu>
          <Sidebar.MenuItem>
            <Sidebar.MenuButton isActive>
              <HomeIcon />
              Dashboard
            </Sidebar.MenuButton>
          </Sidebar.MenuItem>
        </Sidebar.Menu>
      </Sidebar.Content>
    </Sidebar.Root>
  </Shell.Sidebar>
  <Shell.Content>
    <main>Your app</main>
  </Shell.Content>
</Shell.Root>

Shell.Sidebar manages layout state (open/closed/thin, responsive behavior, resize). Sidebar manages navigation presentation (menus, groups, active states, sub-menus).

Two components, clear responsibilities, composable.

What's Next

Shell + Sidebar cover layout and navigation. I'm working on:

CommandBar — Command palette that integrates with Shell's state
NavMenu — Horizontal navigation for headers

The goal is a complete toolkit for building application interfaces. Shell is the foundation.

Closing

Every application needs layout chrome. Sidebars, panels, headers, resize handles, responsive behavior—it's infrastructure that has nothing to do with what makes your product unique. Shell encodes this pattern in KookieUI so teams get tested, accessible, composable layout primitives.

Teams can focus on what goes inside the boxes instead of building the boxes themselves. That's the value Shell brings to KookieUI.

Why Designers Should Own the Experience in Production

Kushagra Dhawan — Mon, 16 Feb 2026 09:25:26 +0000

I think it's time designers start owning their design in code, which is to say, owning the experience in production. I'm not saying it because I want designers to do more than what they already do, but because the end user doesn't get to use their designs as-is. What users feel and interact with is the implementation of their design, which is not entirely in their control - deadlines, speed, lack of focus on details - often ends up compromising exactly what is needed for design to feel good. Users never see the Figma file. They feel the implementation.

Why I took this on for Womp

As part of my work with Womp, I own the design layer in production. Womp is a startup without a dedicated design engineer. I sit across design, product, and code, so I took responsibility for the design layer in production. UI work does not sit in a frontend queue. The team can change the interface quickly and keep it consistent across releases.

I created KookieUI to fit the way the product gets built. The frontend imports components like Button from KookieUI, while I define their appearance, tokens, and behavior. When anything needs an update, I adjust KookieUI and publish a new version. The frontend team then updates the package, and the app adopts the new standard automatically.

What KookieUI is

KookieUI is the design system I built for Womp. It is large and growing. It lives next to product code and stays separate from application logic. It holds tokens, primitives, and patterns the team uses every day. It also carries best practices, accessible components, and the small engineering choices that make interactions feel clean.

KookieUI is a fork of Radix UI and it is open source. Radix gives a strong baseline. I add what the product needs. The focus is on contrast, focus states, motion, density, theming hooks, keyboard paths, and predictable behavior across states.

Where effort goes now

I started by strengthening primitives like buttons, inputs, dialogs, menus, tooltips. Reliable building blocks let the team move faster everywhere else. Now I want to invest in pattern components that carry real but less glamorous work:

App Shell for complex editor and creation flows
StackNav for deep, panel based navigation
Contracts and slots that let simple pieces work in richer contexts, for example adding an optional toolbar slot to Popover so tool groups feel integrated

Patterns reduce decision load and make changes flow through the product. They also let the team run smaller experiments because the base holds steady.

Why design belongs in production

If you ask someone uninterested in design to handle design, the result is not ideal. Do not do it. The person shaping the experience should also shape the code that delivers it.

Traditional handoffs solve the same problem twice. Design in Figma, cover edge cases, pass to engineering, cover code edge cases, ship, feedback, loop. When the design layer lives in code, you solve it once where the user feels it. You still review. You still test. The work sits in the right place.

How the layers work in practice

Design layer

Tokens for color, spacing, type, radius, and motion.
Primitives and patterns like Button, Input, Dialog, Tabs, Chatbar, App Shell, StackNav.
Interaction rules for states, keyboard paths, and focus.
Accessibility checks and visual checks.
Docs that sit next to the parts and explain intent, not just props.

Application layer

Data, state, routing, permissions, and errors.
Business logic, security, and platform concerns.
Feature flags and tracking.

How the work actually ships

The ideal is to add new UI patterns to KookieUI first, then use them in the app. Reality is simpler. Whoever is unblocked does it. If I am deep in product work, the feature team can build the UI inside the application layer to keep moving. Later, that work gets pulled up into KookieUI as a pattern, given proper contracts, tests and docs, and the local version gets replaced. This keeps velocity high while still growing the system.

What changed day to day

UI work moves without getting stuck.
Screens behave the same across the product.
The team has best practices, accessible components, and well engineered parts to rely on.

When shipping fast, teams often skip the details that lift an experience from a nine to a ten. Now that work happens inside KookieUI, in isolation, while engineering focuses on application logic. Both tracks move.

How the system stays healthy

Intent is written down in the docs next to the code. APIs stay clear and narrow. One-off styling in features is avoided. Keyboard paths and focus rules stay visible. Examples match real screens, not toy cases. When a component grows too many concerns, it gets split. When a token change is risky, it gets staged and rolled in steps.

If you want to try this

If you can teach designers to use code, do it. If that is not possible yet, at least separate the design layer from the application layer.

Building quality components is an orthogonal task to building features. Teams rarely estimate time for it in a feature sprint, so it gets missed. Shipping a well engineered component is not easy and it should not compete with a feature deadline.

Start with a primitive or headless library. If your design team is advanced, or you have UI engineers, build a separate component layer and treat it as your design system. Keep it in the repo. Give it owners. Pull patterns up from features when you have breathing room.

Closing

Design that feels good is design that survives the trip to production. Owning the design layer in code gives it that chance. KookieUI is how I do this for Womp. It helps the team move faster and gives time to raise the quality where people notice it.