Request new feature custom header

[quocanh16]

Hi,

Thank you for creating this great library.
I’ve been using uiGrid and the overall experience has been very good so far.

I would like to suggest a few enhancements/features that could make the grid even more powerful:

1. Header customization support
   It would be very useful to support more advanced header structures such as:
   Multiple header rows

2 .Performance review for Row Selection + Expand Row
I noticed that when using both row selection and expandable rows together, the grid becomes noticeably slower, especially with larger datasets.
It would be great if the performance in this scenario could be reviewed and optimized.

Thanks again for your work on this project!

[orneryd]

thanks for the report! if you could also specify which wrapper you are using and your environment information that would help with that.

right now i'm pushing and almost done with a release for NornicDB so i will get to this soon.

[quocanh16]

Hi,

First of all, thank you for creating this great library.
I am currently working with Angular 21 and uiGrid, and the experience has been very good so far.

I would like to suggest a few enhancements and report some issues:

Header customization support
It would be very useful to support more advanced header layouts, such as:
Multiple header rows
Merged header cells (colspan / rowspan)
Grouped columns

Example:

Header row 1: one column spans all non-pinned columns
Header row 2: one column merges two columns
Header row 3: normal columns
Performance issues with Row Selection + Expand Row / Tree View
When using expandable rows or tree view together with row selection:
Expanding child items becomes very slow
Selecting the "select all" checkbox is also slow
Clicking expand may unexpectedly trigger row selection
Child items cannot be fully selected automatically, so we currently have to implement custom logic on our side

It would be great if these scenarios could be reviewed and optimized.

Thanks again for your work on this project!

[orneryd]

fixed the performance and button layout issue when both are selected across the quite is checked into main

looking into your feature requests now

[baigny]

Interested to collab, if any new features are in @orneryd

[orneryd]

Interested to collab, if any new features are in @orneryd

oh yeah man, i sort of finished the laundry-list that the old team left behind when they abandoned support. but I definitely need more testing and use-cases handled, i want to migrate most of the ui-generation to the rust-wasm output. the biggest tax is in serialization so keeping the boundary between wasm > javascript lean with primitives similar to golang/rust c/c++ linking performance optimizations. if we generate the ui in wasm, we can output the innerHTML from inside the wasm boundary while we do all the calculations and logic within wasm. that leaves the web component to be a thin rendering and parameter pass through into the wasm functions which return dom strings. that should boost performance considerably i am thinking.

there is an additional feature i want to get to but need to find more time for it is the multi-header col-span on top. id like to make it N-arity for regular col spans and handle the header events but im trying to consider simpler approaches and so i have to do some research. anyone is free to contribute and id love more feedback, review, and test cases if people are still around to use it. i'd love to revive the project in general for everyone.

[baigny]

Interested to collab, if any new features are in @orneryd

oh yeah man, i sort of finished the laundry-list that the old team left behind when they abandoned support. but I definitely need more testing and use-cases handled, i want to migrate most of the ui-generation to the rust-wasm output. the biggest tax is in serialization so keeping the boundary between wasm > javascript lean with primitives similar to golang/rust c/c++ linking performance optimizations. if we generate the ui in wasm, we can output the innerHTML from inside the wasm boundary while we do all the calculations and logic within wasm. that leaves the web component to be a thin rendering and parameter pass through into the wasm functions which return dom strings. that should boost performance considerably i am thinking.

there is an additional feature i want to get to but need to find more time for it is the multi-header col-span on top. id like to make it N-arity for regular col spans and handle the header events but im trying to consider simpler approaches and so i have to do some research. anyone is free to contribute and id love more feedback, review, and test cases if people are still around to use it. i'd love to revive the project in general for everyone.

let me know if anything is on priority basis but not urgent, I know wasm concept is newer to me but JS I can do it. Will be an added skillset to my resume

[orneryd]

Interested to collab, if any new features are in @orneryd

oh yeah man, i sort of finished the laundry-list that the old team left behind when they abandoned support. but I definitely need more testing and use-cases handled, i want to migrate most of the ui-generation to the rust-wasm output. the biggest tax is in serialization so keeping the boundary between wasm > javascript lean with primitives similar to golang/rust c/c++ linking performance optimizations. if we generate the ui in wasm, we can output the innerHTML from inside the wasm boundary while we do all the calculations and logic within wasm. that leaves the web component to be a thin rendering and parameter pass through into the wasm functions which return dom strings. that should boost performance considerably i am thinking.
there is an additional feature i want to get to but need to find more time for it is the multi-header col-span on top. id like to make it N-arity for regular col spans and handle the header events but im trying to consider simpler approaches and so i have to do some research. anyone is free to contribute and id love more feedback, review, and test cases if people are still around to use it. i'd love to revive the project in general for everyone.

let me know if anything is on priority basis but not urgent, I know wasm concept is newer to me but JS I can do it. Will be an added skillset to my resume

if you want to do some research on the best approach for the header and implement that i’d love to have the help.

[orneryd]

oh and for web we want to use the orneryd/ui-grid repo. this repo contains the rust.

[baigny]

rneryd/ui-grid

orneryd/uiGrid: Contains the core Rust code, calculations, and logic.

orneryd/ui-grid: Designated for the web implementation and frontend wrapper.

am I on right track based on your explanation? let me check and do some research and get back to you.

[orneryd]

that’s correct!

…

-TJ

On Thu, Aug 20, 2026 at 1:29 AM baigny ***@***.***> wrote: *baigny* left a comment (orneryd/uiGrid#5) <#5 (comment)> rneryd/ui-grid orneryd/uiGrid <https://github.com/orneryd/uiGrid/>: Contains the core Rust code, calculations, and logic. orneryd/ui-grid <https://github.com/orneryd/ui-grid>: Designated for the web implementation and frontend wrapper. am I on right track based on your explanation? — Reply to this email directly, view it on GitHub <#5?email_source=notifications&email_token=AANH4H2FARVRYJH6JAI6AQ35K2ZHTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZVGMZTQNZXHE22M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5353387795>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANH4HZ37ITGXOLB6RR2JGD5K2ZHTAVCNFSNUABGKJSXA33TNF2G64TZHMYTEMRSHAZDENZVGY5US43TOVSTWNBUGQZTGMJRGMZDHILWAI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[baigny]

Interested to collab, if any new features are in @orneryd

oh yeah man, i sort of finished the laundry-list that the old team left behind when they abandoned support. but I definitely need more testing and use-cases handled, i want to migrate most of the ui-generation to the rust-wasm output. the biggest tax is in serialization so keeping the boundary between wasm > javascript lean with primitives similar to golang/rust c/c++ linking performance optimizations. if we generate the ui in wasm, we can output the innerHTML from inside the wasm boundary while we do all the calculations and logic within wasm. that leaves the web component to be a thin rendering and parameter pass through into the wasm functions which return dom strings. that should boost performance considerably i am thinking.

there is an additional feature i want to get to but need to find more time for it is the multi-header col-span on top. id like to make it N-arity for regular col spans and handle the header events but im trying to consider simpler approaches and so i have to do some research. anyone is free to contribute and id love more feedback, review, and test cases if people are still around to use it. i'd love to revive the project in general for everyone.

Approach on Custom Headers

• Hierarchical Tree Structure: Give GridColumnDef an optional children array to allow columns to nest hierarchically like a tree. The number of header rows can then be derived automatically from the depth of that tree—eliminating the need for a separate header configuration that risks drifting out of sync with the columns array.
• CSS Grid Span Rendering: For actual rendering, since we aren't using a traditional table (it's all CSS grid), grouping can be handled cleanly using grid-column: span / grid-row: span on the header cells, sitting on top of the same grid-template-columns the body uses.