Moving to TailwindCSS, Shadcn and Base UI in AdapTable

AdapTable has always prided itself on shipping a rich, opinionated UI out of the box.

These include wizards, dashboard toolbars, tool panels, cell editors, pickers, dialogs, column & context menus, and a long tail of bespoke controls.

As our UI surface has grown, we decided it was time, with the release of AdapTable Version 23, to invest in the foundation that all of these components sit on.

This post explains what has changed, and - more importantly - what this means for the developers and run-time users who rely on AdapTable every day to run business-critical applications.

What Changed Under the Hood

Previously, AdapTable shipped with a hand-rolled component set built up over many years.

It worked well, but maintaining dropdowns, popovers, comboboxes, tooltips, selects and menus from scratch - with full accessibility - is a significant undertaking.

More importantly, it was not core to what AdapTable does.

So we've adopted the combination that is fast becoming the default stack for serious React applications:

This means every dropdown, popover, combobox, tooltip, menu and dialog in AdapTable is now built on the same small, well-tested set of primitives.

CSS Variable Renames

As part of this migration we have simplified some of our CSS custom property names to align with the shadcn/Tailwind conventions:

If you were overriding the old variable name, you should transition to the new variable name.

For this release, the default values for the new variables still fallback to the old names if you have them, but they will be phased out in the next major release.

Better Accessibility (ARIA) Out of the Box

The biggest single win from this migration is accessibility.

In practical terms, this means AdapTable UI now:

• announces menus, listboxes, comboboxes, dialogs and popovers correctly to screen readers
• exposes correct aria- attributes: label, expanded, selected, controls and activedescendant
• manages focus traps in modals and popovers, and restores focus when they close
• keeps aria-labelledby / aria-describedby relationships consistent across our components

For users working in regulated environments - or simply users who rely on assistive technology - this is a material improvement on what we had before.

First-Class Keyboard Navigation

Hand-in-hand with ARIA comes first-class keyboard support.

Every interactive component in AdapTable - menus, comboboxes, selects, tabs, dialogs, tooltips - now follows the keyboard interaction patterns that advanced users expect:

This is particularly valuable for AdapTable's power users on trading floors and operations desks, who rely on keyboard-driven workflows and rarely reach for the mouse.

Cleaner, More Flexible Styling

Under the new system, every component is styled with Tailwind utility classes, driven by a small set of CSS variables (design tokens).

This provides mulitple benefits in a single step:

• Consistent theming - colours, spacing, radii and typography are derive from one set of tokens
• Built-in dark mode - light and dark themes are just two sets of CSS variable values
• Easier white-labelling - customers who need to match a corporate palette can do so by overriding a handful of CSS variables, rather than fighting with deeply nested selectors
• Smaller surface area for regressions - fewer bespoke stylesheets means fewer places for visual bugs to hide

No Clashes With Your Own Tailwind

A common (and entirely reasonable) concern when a library adopts Tailwind is: "what happens if my app is already using Tailwind, possibly at a different version, with my own utility classes?"

In practice, this means:

• No class-name collisions - AdapTable's twa:flex and your app's flex are two completely separate utilities, and can't overwrite each other
• No version coupling - your app can stay on its current Tailwind version (v3, v4, or no Tailwind at all); AdapTable ships its own self-contained Tailwind build
• No configuration required - you don't need to extend your tailwind.config or add AdapTable to your content / @source paths for anything to work
• Safe to drop into any app - whether your host app uses Tailwind, styled-components, CSS modules, vanilla CSS, or a mix, AdapTable's styles stay inside their own namespace

Troubleshooting: cascade layer order

In rare cases - typically when your app uses Tailwind v4 with cascade layers and AdapTable's prefixed utilities appear to be overridden by your app's preflight reset (e.g. twa:px-1 losing to *, ::before, ::after { padding: 0 }) - declaring an explicit layer order in your global stylesheet resolves it:

@layer theme, base, components, adaptable, utilities;

This places AdapTable's styles after your base (preflight) and components layers but before your own utilities, so AdapTable's prefixed classes win against the base reset while your own utility classes still win against AdapTable. The rightmost layer in the declaration has the highest priority.

Performance and Bundle Improvements

Rebuilding on top of Base UI and Tailwind also gave us an opportunity to clean up the bundle.

For end users this manifests itself in 2 noticeable ways:

• a much faster intitial render
• smoother subsequent UI interactions

This is particularly noticeable on large, data-dense screens (where AdapTable is often used).

What Stays the Same

• All existing AdapTable modules, APIs and config options continue to work exactly as before
• Existing styling and theming APIs are preserved
• Your existing custom toolbars, custom cell renderers, custom context menus and Adaptable Buttons all continue to work unchanged

If you upgrade and do nothing else, the main thing you will notice is that the UI feels a little snappier, a little cleaner, and a lot more consistent.

le for yourself.