Have something to say?

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

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.

Abel Guevara 4 days ago

💡 Feature Request

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

iqromprasetyo 6 days ago

💡 Feature Request

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.

Vjeran 13 days ago

📝 Components Request

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

Aren Dalloul 2 months ago

1

📝 Components Request