DEV Community: Bassem Chagra

Migrating from Elastic EUI to MUI, Chakra, or Ant Design — The Complete Playbook

Bassem Chagra — Tue, 14 Apr 2026 10:52:09 +0000

If you're reading this, your team probably built something on Elastic EUI and now you're stuck. Maybe you're not an Elastic shop anymore. Maybe the 188kb bundle is killing your Lighthouse scores. Maybe you're tired of fighting the Elastic License.

Whatever the reason, you need to migrate — and the docs won't help you. This is what I learned mapping 45 EUI components to their MUI, Chakra, and Ant Design equivalents.

Why teams leave EUI

Bundle size. EUI ships approximately 188KB gzipped. MUI's tree-shakeable architecture lets you import only what you use, typically resulting in 40-60% smaller bundles.

Elastic ecosystem lock-in. EUI was designed for Kibana. Its design language, component behavior, and even its color palette reflect Elastic's brand. Teams building non-Elastic apps find themselves fighting the library's opinions.

License concerns. EUI uses the Elastic License 2.0 (ELv2), which is not OSI-approved. Some legal teams flag this as a compliance risk for SaaS products.

Community. Stack Overflow questions, blog posts, and community plugins are significantly fewer compared to MUI (93k+ GitHub stars) or Ant Design (91k+).

The hardest parts nobody warns you about

EuiProvider is a monolith

EUI wraps theme, i18n, toast notifications, and global component defaults in a single provider. You can't extract components one-by-one without either keeping EuiProvider alive (bloating the bundle) or breaking everything at once.

What to do: Map every component that depends on EuiProvider context before writing a single line of migration code. You'll be surprised how many "independent" components break without it.

EuiBasicTable pagination is invisible

EUI manages pagination state internally. MUI's DataGrid requires you to manage paginationModel state yourself — page index, page size, total count. Teams that relied on EUI's "just pass items and it works" discover they need to add 20+ lines of state management.

// EUI — pagination is automatic
<EuiBasicTable items={data} columns={columns} pagination={pagination} />

// MUI — you manage the state
const [paginationModel, setPaginationModel] = useState({
  page: 0,
  pageSize: 20,
});
<DataGrid
  rows={data}
  columns={columns}
  paginationModel={paginationModel}
  onPaginationModelChange={setPaginationModel}
  pageSizeOptions={[20, 50, 100]}
/>

Color tokens are lossy

EUI uses semantic color names (subdued, accent, success) that map to its own palette. MUI uses Material Design colors (primary, secondary, error). There's no 1:1 mapping — subdued has no MUI equivalent. You'll end up building a custom theme layer just to bridge the gap.

The date math dependency

EUI depends on @elastic/datemath and moment. If your app uses EuiSuperDatePicker's relative date expressions ("now-15m"), you need to keep these dependencies or rewrite the date parsing logic. MUI doesn't have anything equivalent.

TypeScript migration patterns

This is where senior engineers spend most of their time.

Generic type mapping (Data Tables)

EUI uses generics to enforce type safety on row items:

// EUI
import type { EuiBasicTableColumn } from '@elastic/eui';

const columns: Array<EuiBasicTableColumn<User>> = [
  { field: 'name', name: 'Full Name', sortable: true },
  {
    field: 'status',
    name: 'Status',
    render: (status: User['status']) => (
      <EuiHealth color={status === 'active' ? 'success' : 'danger'}>
        {status}
      </EuiHealth>
    ),
  },
];

// MUI equivalent
import type { GridColDef } from '@mui/x-data-grid';

const columns: GridColDef<User>[] = [
  { field: 'name', headerName: 'Full Name', sortable: true },
  {
    field: 'status',
    headerName: 'Status',
    renderCell: ({ row }) => (
      <Chip
        color={row.status === 'active' ? 'success' : 'error'}
        label={row.status}
        size="small"
      />
    ),
  },
];

Key differences:

EuiBasicTableColumn<T> → GridColDef<T> — different generic wrapper
name → headerName — column display name
render: (value) → renderCell: ({ row }) — receives params object, not raw value
MUI DataGrid requires @mui/x-data-grid as a separate package

Dealing with ExclusiveUnion

EUI uses a custom ExclusiveUnion utility to strictly prevent mixing button/anchor props:

// EUI — TypeScript Error! Can't have both onClick and href
<EuiButton href="/login" onClick={handleClick}>Login</EuiButton>

MUI handles this with the component prop:

// MUI — explicit about the underlying element
<Button component="a" href="/login">Login</Button>
<Button component={Link} href="/login">Login</Button> // Next.js Link

When migrating wrapper components, rewrite using MUI's typed component pattern:

// Before: EUI wrapper with ExclusiveUnion
type Props = EuiButtonProps; // includes ExclusiveUnion internally

// After: MUI wrapper with generic component type
type Props<C extends React.ElementType = 'button'> = ButtonProps<C>;

The 10 components with no direct equivalent

These will cost you the most time:

EUI Component	What to do
`EuiSuperDatePicker`	Build custom with two MUI DatePickers + relative date presets
`EuiGlobalToastList`	Use notistack or build a custom Snackbar queue manager
`EuiHealth`	Trivial — just a colored dot with `Box`
`EuiStat`	Build with `Typography` + `Box`
`EuiColorPicker`	Use react-colorful
`EuiMarkdownEditor`	Use @uiw/react-md-editor
`EuiCodeBlock`	Use react-syntax-highlighter or prism-react-renderer
`EuiComboBox` (full)	MUI Autocomplete covers 80% — async loading needs custom work
`EuiContextMenu` (panels)	MUI Menu doesn't support panel-based navigation — build custom
`EuiSelectable`	No direct equivalent — use custom interface with MUI Select

The migration strategy that works

After doing this across 45 components, here's the approach I'd use again:

Step 1: Audit. List every EUI component in your codebase. Count usage. Sort by frequency.

Step 2: Abstraction layer. Create wrapper components that currently re-export EUI:

// /components/ui/Button.tsx — Phase 1
export { EuiButton as Button } from '@elastic/eui';

// Phase 2 — swap the import, consumers don't change
export { Button } from '@mui/material';

Step 3: Leaf components first. Migrate buttons, badges, text, avatars — the components that don't depend on others. This builds confidence and momentum.

Step 4: Complex components last. Tables, modals, forms — these touch the most code and have the most API differences.

Step 5: Kill EuiProvider. Once all components are migrated, remove EuiProvider and @elastic/eui from your dependencies. Verify nothing breaks.

Interactive component reference

I built a searchable tool that maps all 45 EUI components to their MUI equivalents — including props, import changes, and which ones have no direct equivalent.

Try the interactive prop search table →

You can also paste EUI code directly into the converter and get MUI/Chakra/Ant Design output instantly:

Open the converter →

Or eject a production-ready component into your project:

npx @frontfamily/cli eject data-table -f react-mui

This guide is part of FrontFamily — a free tool for converting UI components between frameworks. 42 conversion paths, 219 verified component mappings, 18 ejectable patterns.

Nobody Teaches You How to Build Kibana Plugins. So I Packaged Everything I Know

Bassem Chagra — Thu, 05 Feb 2026 10:00:24 +0000

I Built a Tool That Does My Job (And I'm Giving It Away for Free)

Last month I caught myself explaining how to set up Kibana plugin authentication for the fourth time. Same patterns. Same mistakes the other developer was about to make. Same "oh wait, you also need to handle multi-tenancy" moment 20 minutes in.

I thought: what if I just... packaged everything I know into something reusable?

So I built a Claude Code plugin for Kibana development. It's on GitHub. It's free. And honestly, I'm not sure if this was smart or if I just automated myself out of a job.

Here's the story.

The Problem Nobody Talks About

Try Googling "how to build a Kibana external plugin."

Go ahead. I'll wait.

You'll find Elastic's official docs (sparse), a deprecated Yeoman generator from 2018, and a bunch of Stack Overflow posts from people who gave up. That's basically it.

When I started building Kibana plugins at UNIBERG, my main learning resource was... reading Kibana's source code. The actual Kibana repo. 200,000+ files. Searching for patterns. Hoping the internal plugin I was looking at was doing things the "right" way and not some legacy hack that hadn't been cleaned up yet.

There's no tutorial. No course. No "Kibana Plugin Development for Dummies." You just figure it out.

Which is fine — I actually enjoy that kind of thing. But after 6+ years of figuring it out, I had a lot of knowledge sitting in my head (and scattered across about 40 different notes.md files) that could save someone months of pain.

Why a Claude Code Plugin?

I'd been using Claude Code for a while. One day I looked at the plugin docs and realized the structure was weirdly similar to what I already knew from Kibana plugins. Manifest file. Directory structure. Configuration. Except way simpler.

Claude Code plugins are basically: a JSON manifest, some markdown files for commands/skills/agents, and that's it. No compiled code. No build step.

My first thought: "I could put my entire Kibana knowledge base into a skill file and Claude would just... know it."

My second thought: "That can't actually work."

It did.

What I Actually Built

Started on a Saturday afternoon. Figured it'd take a couple hours.

It took two full days. And then another week of adding stuff because I kept thinking "oh, and this pattern too."

The plugin has:

10 slash commands — /scaffold generates a full plugin skeleton (server + public + types + manifest). /route creates server routes with proper @kbn/config-schema validation. /component generates EUI-based React components. /security sets up RBAC. And a few more.

6 specialized agents — an architect that reviews your plugin structure, a security auditor that checks for auth bypass and data leaks, a migration assistant for version upgrades.

1 massive skill file — around 400 lines of concentrated Kibana plugin knowledge. Plugin lifecycle. Route patterns. ES client usage. EUI components. Auth middleware. Testing patterns. Common pitfalls.

The skill file is the part I'm most proud of. And also the part that took the longest because I kept going "wait, I forgot about saved object migrations" and adding another section.

The Stuff That Was Hard to Get Right

Route authentication patterns.

This sounds boring. It is boring. But if you get it wrong, you leak user data across tenants. I've seen it happen. I've caused it to happen. The plugin bakes security checks into every generated route by default, because I learned the hard way that "I'll add auth later" means "I'll discover the auth bug in production."

Every route the /route command generates starts with:

const user = security.authc.getCurrentUser(request);
if (!user) return response.forbidden();

Boring. But I have scars from the time it wasn't there.

EUI component patterns.

Elastic UI has maybe 80+ components. Some are well-documented. Some aren't. Some have props that don't do what you'd think. I spent a full day once debugging why an EuiBasicTable wasn't rendering pagination correctly — turned out I was passing totalItemCount as a string instead of a number. TypeScript didn't catch it because the prop type was any.

The /component command generates components that already handle the edge cases I've hit. Dark mode compatibility. Responsive layouts. Loading states. Error boundaries. Stuff I used to forget and then fix in production.

Elasticsearch client integration.

The Kibana ES client isn't the same as the regular @elastic/elasticsearch client. It's wrapped. It has different error types. It handles auth differently. And it changes between Kibana minor versions in ways that aren't always documented.

I wrote a service layer pattern into the skill that handles type coercion, error mapping, and defensive defaults for every ES response. It's about 200 lines of code I never want to look at again. But every plugin I build copies it.

The Part Where I Question Everything

Here's what's weird about open-sourcing your expertise: someone could install this plugin and skip years of learning.

The auth patterns I figured out through a security audit that almost gave me a heart attack? It's in there.

The EUI dark mode bug that cost me a full Wednesday? Handled automatically.

The Elasticsearch response transformation layer I wrote at 2 AM because production data had timestamps in three different formats? Built into the skill.

Am I devaluing my own experience by giving it away?

Maybe. Probably not. The plugin can scaffold code and teach patterns, but it can't debug your specific production issue at 11 PM on a Thursday. It can't look at your data model and say "this won't scale past 100k records." It can't sit in a meeting and explain to a product manager why multi-tenancy takes three weeks, not three days.

Tools don't replace experience. They just make the boring parts faster.

At least that's what I tell myself.

What Actually Happens When You Use It

Here's a real example. You type:

/scaffold

Claude asks what you're building. You say "user management plugin with RBAC."

Two minutes later you have:

Plugin manifest with correct Kibana version targeting
Server-side setup with route registration
Public-side app mounting with React
TypeScript types for your domain
Basic EUI page layout with navigation
Security configuration with feature privileges
A working kibana.jsonc

Before this plugin, that setup took me about 4 hours. And I'd still forget something — usually the kibana.jsonc configuration, because that file is easy to get wrong and hard to debug when you do.

Things That Are Still Missing

I'll be honest about what's not in there yet:

State management patterns — I have opinions (use React context + custom hooks, not Redux) but haven't formalized them into commands yet.

Logging and monitoring — This is important for production plugins and I keep putting it off because it's not the fun part.

Inter-plugin dependencies — This is genuinely complicated. Kibana's dependency injection system between plugins is powerful but also confusing. I've been working with it for years and still double-check the docs every time.

Real-time data patterns — WebSocket-style updates through Kibana. I've done it, but the patterns aren't clean enough to template yet.

The Open Source Anxiety

Publishing it was uncomfortable.

Not because of the code — the code is fine. But because it's basically my brain in a markdown file. Every pattern is something I learned through mistakes. Every anti-pattern check in the security agent is a bug I caused or caught.

What if someone finds something wrong? What if a pattern that works in my use cases breaks in theirs? What if an Elastic engineer looks at it and says "that's not how we do it internally"?

Then... they'll open an issue. And I'll fix it. Or learn something new.

That's kind of the point.

How to Actually Use It

If you're building Kibana plugins (or thinking about it):

/plugin marketplace add ch-bas/kibana-plugin-helper
/plugin install kibana-plugin-helper@kibana-plugin-helper

Then try /scaffold and see what happens.

If you're not building Kibana plugins — honestly, most people aren't — this post is really about something else: packaging your hard-won knowledge into something others can use.

Whatever your niche is, you have patterns and lessons that could save someone else months. The format doesn't matter. A plugin, a blog post, a markdown file in a GitHub repo. The point is getting it out of your head and into a place where it helps.

I just happened to pick a Claude Code plugin because the structure was familiar and I'm a developer, so of course I over-engineered it.

What I'd Like to Know

If you're doing Kibana plugin development: what's the thing you wish someone had told you on day one? I might add it.

If you've open-sourced your expertise before: did it help your career or hurt it? Genuinely curious.

And if you've used Claude Code plugins: are people actually discovering them through marketplaces, or is it still mostly word of mouth?

Drop your answers. I read everything.

GitHub: github.com/ch-bas/kibana-plugin-helper
License: MIT (do whatever you want with it)

Kibana #ElasticStack #OpenSource #ClaudeCode #WebDevelopment #React