Skip to main content

Have something to say?

Tell HeroUI Pro how they could make the product more useful to you.

Audio and waveform components for dictation

I have a request for new components. I want to build a dictation style input, just like the one you see in Claude code or ChatGPT. Can we please have the audio and waveform component? Examples that work with OpenAI APIs for transcriptions would be great.

ButtonGroup

A button group component for mobile similar to this https://heroui.com/en/docs/react/components/button-group in web.

In Progress

AppLayout: breakpoints include the edge pixel and use px; aside trigger hidden and sheet mis-sized with asideMobile="sheet"

Versions: @heroui-pro/react 1.0.0-beta.10 (latest), @heroui/react 3.2.6, tailwindcss 4.3.3, Chromium on macOS. 1. Breakpoints include the edge pixel and use px AppLayout and Sidebar switch layouts with max-width: 768px and max-width: 1024px, in the compiled CSS (app-layout.css, sidebar.css) and in matchMedia (app-layout.js, sidebar.js). max-width: 768px includes 768px, but Tailwind's md starts at 768px (width >= 48rem). So at exactly 768px AppLayout shows the mobile layout while md: classes already apply. The same happens at 1024px with lg. The docs say "hidden below 1024px" and "visible below the md breakpoint", and number-stepper, context-menu and drop-zone already use 48rem and 64rem. The unit also differs. Tailwind breakpoints use rem, so they move when the user changes the browser's default font size. With Chrome's "Large" font (20px), md is 960px and lg is 1280px, but AppLayout still switches at 768px and 1024px. 768px and 1024px are common iPad widths, so our designs and AppLayout show different layouts on real devices. Could AppLayout and Sidebar use (width < 48rem) and (width < 64rem) in both the CSS and matchMedia? A way to configure the breakpoints (reading --breakpoint-md and --breakpoint-lg, or a prop for the media query) would also work for us. The open-source Toast had the same pattern; it was fixed in heroui-inc/heroui#6932 (from #6933) and ships in @heroui/react 3.2.7. 2. The aside trigger is hidden in sheet mode .app-layout__aside-trigger is hidden at 1024px and below. The docs say the sheet is toggled by the same AppLayout.AsideTrigger, so with asideMobile="sheet" there is no way to open the sheet. Could the trigger stay visible when asideMobile is "sheet"? The context already has hasMobileAside. 3. The aside sheet is wider and rounder than intended .app-layout__mobile-aside-sheet sets max-width: min(360px, 88vw), but.sheet__content--right (96vw, rounded start corners) comes later with the same specificity and wins. On a 390px screen the sheet is 374px wide and rounded instead of 343px. The sidebar sheet already uses a more specific selector for this. Could the aside sheet do the same? 4. Related: one open state for the aside column and its sheet The column and the sheet share isAsideOpen, and defaultAsideOpen is true. So in sheet mode the sheet covers the page on every load on small screens, and opens whenever the window shrinks below 1024px. We work around it with a controlled asideOpen that keeps a separate, closed-by-default state below 1024px. A separate default for the sheet would help. Our workaround CSS for 2 and 3, in case it helps: @media (max-width: 1024px) { .app-layout__aside-trigger { display: inline-flex; } } .app-layout__mobile-aside-sheet.sheet__content--right { max-width: min(360px, 88vw); border-radius: 0; } .app-layout__mobile-aside-dialog.sheet__dialog--right { border-radius: 0; } Thank you!

RichTextEditor.LinkPopover.Trigger renders an unnecessary nested popover trigger

In @heroui-pro/[email protected], RichTextEditor.LinkPopover.Trigger wraps its existing trigger button in an additional Popover.Trigger. First observed in beta.8; still reproducible in beta.10. beta.9 was not tested separately. Reproduction: Mount the documented RichTextEditor.LinkPopover composition with its Trigger, Content, and Input. Actual: The resulting DOM contains the editor’s link-trigger button plus an additional outer popover-trigger wrapper. Expected: One trigger owns the button’s interaction and popover behavior, without a redundant nested trigger. Local workaround: Remove the outer Popover.Trigger wrapper while preserving the existing button and optional tooltip. Our regression test verifies that the link button remains present and the redundant wrapper is absent. Environment: HeroUI Pro beta.10, HeroUI OSS 3.2.6, React 19.2.8.

RichTextEditor registers duplicate Link and Underline extensions

In @heroui-pro/[email protected], RichTextEditor registers Link and Underline twice: once through Tiptap StarterKit and again as explicitly configured extensions. First observed in beta.8; still reproducible in beta.10. Beta.9 was not tested separately. Reproduction: Mount RichTextEditor with its default extensions. The issue occurs both with and without the optional Markdown extension. Actual: Tiptap reports duplicate extension names. Inspecting editor.extensionManager.extensions shows multiple link and underline entries. Expected: Each extension is registered exactly once. Verified workaround: Disable StarterKit’s copies using link: false and underline: false, retaining Pro’s explicitly configured extensions. Our unchanged regression tests fail against the unpatched package and pass with this correction. Environment: HeroUI Pro beta.10, HeroUI OSS 3.2.6, React 19.2.8.

Linter for Heroui web/native libraries

Shadcn recently 09/14/2026 announced a linter for shadcn. It would be nice to have a linter like this for heroui. I’m constantly having to tell agents to try and follow our design system instead of trying to add new custom classes all the time. They open sourced the repo: https://github.com/shadcn-ui/lint Also here’s the tweet thread explaining why they created it: https://x.com/shadcn/status/2099534231114314145

Feature request: row links in DataGrid

React Aria's RowProps already extends LinkDOMProps (href, target, rel, routerOptions), so table rows can be rendered as links and RAC handles modifier-click natively. DataGrid doesn't surface it: here is no href anywhere in its API, and onRowAction only receives the row key, with no event, so a consumer cannot detect metaKey/ctrlKey either. The result is that a row-click navigation cannot support ⌘-click / middle-click / "Open in new tab", which users expect from any list of records.

In Progress

sticky datagrid header

HeroUI Pro DataGrid currently appears to tie sticky header behavior to virtualization. While virtualization can make the header appear sticky through properties such as rowHeight and headingHeight, this is not an acceptable requirement when the application does not need virtualization. A sticky header and row virtualization solve two completely different problems: Sticky headers are a scrolling and usability concern. Virtualization is a performance optimization for rendering large datasets. These concerns should not be coupled. Right now, if the only requirement is to keep the column headers visible while scrolling, developers are effectively forced to enable virtualization and provide fixed dimensions. This creates unnecessary limitations and can prevent the use of normal DataGrid behavior, particularly when rows need to support dynamic or variable heights. For example, enabling virtualization may require: Fixed rowHeight values Fixed headingHeight values Giving up naturally dynamic row heights Additional configuration that is completely unrelated to sticky headers Using a different rendering mode purely to achieve a basic scrolling behavior This makes a common UI requirement unnecessarily difficult to implement. Proposed API or: The sticky header should work independently of virtualization. For example: ... This should preserve normal DataGrid functionality, including: Dynamic and variable row heights Row selection Sorting Horizontal scrolling Pagination Normal non-virtualized rendering Existing table accessibility behavior The expected implementation would simply keep the column header sticky within the DataGrid's vertical scroll container, rather than making virtualization a prerequisite. Why this matters Developers should not have to choose between dynamic content and sticky headers. A DataGrid often contains rows with content that naturally changes height, such as: Long descriptions Multi-line text Status messages Expandable content Custom cell components Responsive content In these cases, forcing a fixed rowHeight just to get a sticky header is a significant limitation. Sticky headers are also a standard table usability feature. They should be available regardless of whether the table is rendering 20 rows or 20,000 rows. Virtualization should remain an optional performance optimization, not a dependency for basic header behavior. Expected behavior ... Expected result: The DataGrid scroll container scrolls vertically. The column header remains visible at the top of that container. Body rows can retain natural and dynamic heights. Horizontal scrolling continues to work normally. Virtualization remains optional. No rowHeight or headingHeight configuration should be required solely for sticky header behavior. This would make the DataGrid API significantly more flexible and would separate scrolling behavior from rendering strategy, which is the more appropriate API design. At t

HeroUI Agents vs HeroUI Pro - Data visualization components

I see heroUI Pro Agents uses data visualization components we don’t have in PRo and I feel thats not fair. Spefifically Candlestick, Funnel charts, Gauges, Sunburst, Sankey, Scatter, Heatmap. We are heavy into building deterministic dashboards, so we don’t need agents feature, just the components.

Drag & Drop Primitive

Can we create a new component that can help drag and drop any component in the UI? Kanban is currently very opinionated, but we do not have a primitive that we can use out of the box right now.

Icon Picker

Similar to Emoji Picker, but for icons. Ideally, with support for FontAwesome, where selecting an icon would return the icon name so it can be rendered with react-fontawesome. It would feature a search to find icons by keyword, and maybe controls to filter/select by icon style (e.g. classic/duotone).

Mouve Theme

Mobile (React Native)

Support OAuth MCP connections

Some agent harnesses do not support custom headers, but OAuth is part of the MCP standard.

Post and comments component

A post and comments components or/and a social template.

Android Theme

The default theme uses styling that tends more towards iOS look & feel. It would be great to have a theme that provides a more native Android look & feel for use on those devices.

Navigation menu with floating dropdown

Navigation Menu similar to radix (https://www.radix-ui.com/primitives/docs/components/navigation-menu) with a floating dropdown and smooth animated width changes between items

Floating Label Wrapper

Bring back the v2 floating animation on v3 form-based components

Web (React)

Update Bottom Sheet Component

can we move away from @gorhom/bottom-sheet or making the bottom sheet implementation pluggable? gorhom is great/powerful but it adds reanimatedd/gesture handler dependency complexity. @lodev09/react-native-true-sheet and @swmansion/react-native-bottom-sheet seem like solid fits to try out instead of gorhom. even if HeroUI keeps Gorhom as the default an adapter layer would let teams choose a native sheet implementation without forking