New Feature Idea / Menu Slots via Custom Renderer

[ghiscoding]

@zewa666 / @jr01 / @lewis-sanchez
hey guys, just reaching out for some feedback from some big users like you since I'm working on this next feature. The idea came out after looking at the MSSQL extension (which now uses Slickgrid-React for one of their grid for Editing Data) and I noticed that some of their header menu could look quite different and I was wondering if I could provide some kind of Slots to the Menu Items. I managed to do it, with copilot's help, by simply adding an optional custom renderer and when provided would be used instead of the default code. It's not real Slot since I needed something native and not specific to any frameworks, so a custom renderer make sense and is very similar to a SlickGrid Formatter. The other great thing is that a while ago I merged all similar menu code for all the menu plugins and with that in place, I was able to add this feature with less than 50 lines of code and it works for all menu plugins (Cell Menu, Context Menu, Grid Menu, Header Menu).

Note this is scheduled for my next upcoming major v10

I interacted with @lewis-sanchez on the MSSQL extension and I was wondering, if you @lewis-sanchez think that this could be useful to your project? if so, do you have any feedback in regards to the code show below.

below is MSSQL extension header menu from the main grid, which is a bit different compared to Slickgrid-React

Then here's my current implementation with a custom menu item renderer, a user could use HTML string or native DOM element (the later is better for CSP compliance and it can also be useful for adding event listener)

header: {
  menu: {
    commandItems: [
      {
        command: 'sort-asc',
        title: 'Sort Ascending',
        positionOrder: 50,
        // Slot renderer via HTML string
        slotRenderer: () => `
          <div class="menu-item">
            <i class="mdi mdi-sort-ascending menu-item-icon"></i>
            <span class="menu-item-label">Sort Ascending</span>
            <kbd class="key-hint">Alt+↑</kbd>
          </div>
        `,
      },
      {
        command: 'sort-desc',
        title: 'Sort Descending',
        positionOrder: 51,
        // or Slot renderer via native DOM element
        slotRenderer: () => {
          const menuItemElm = createDomElement('div', { className: 'menu-item' });
          const iconElm = createDomElement('i', { className: 'mdi mdi-sort-descending menu-item-icon' });
          const menuItemLabelElm = createDomElement('span', { className: 'menu-item-label', textContent: 'Sort Descending' });
          const kbdElm = createDomElement('kbd', { className: 'key-hint', textContent: 'Alt+↓' });
          menuItemElm.appendChild(iconElm);
          menuItemElm.appendChild(menuItemLabelElm);
          menuItemElm.appendChild(kbdElm);
          return menuItemElm;
        },
      },
    ],
  },
}

I also provided a defaultItemRenderer which you guessed it, can be used as the default item renderer except that this is rather assignable on each Menu Plugins

Below is that what that looks like when used in all 4 menu types. A few notes:

• keyboard hint, like "F5", are just shown as examples and they don't actually trigger anything
• some of the animations shown were added by event listener on elements added by the renderer
• another listener shows a dynamic tooltip on advanced export timestamp
• the renderer is only customizing the inside of each
• item, the
• container remains the same

So what do you guys think? Even if you aren't going to use it, I'm still thinking of adding it since it's less than 50 lines of code anyway.

---

Extras

I was also thinking to add a Menu Footer... but I think this one is simply just too much and probably unnecessary because list items are already clickable anyway. Still is an idea... in the image below, the 2 buttons are in the footer area.

[zewa666]

I'm all for more extensibility as you never know what usecases people have. Also wow cool, didnt know that SSMS was using Slickgrid 🤩

[ghiscoding]

Also wow cool, didnt know that SSMS was using Slickgrid

@zewa666 yeah they're actually using the legacy SlickGrid one as their main grid since many years, but they added a new grid to Edit Data recently that one is built with Slickgrid-React. They created this video to demo it, but that was the first iteration and it changed a lot since then. They should probably update their video 😄

You can see this feature in particular is using the Cell Selection Model and the Context Menu to export as CSV, Excel or JSON file.
microsoft/vscode-mssql#20812

It's just too bad that my current project isn't using SQL Server but rather PostgreSQL 😆 so I'm still using the deprecated Azure Data Studio which is also using SlickGrid but the old one.

[jr01]

Hey!I wanted to share how we currently customize menus and what pain points a "Slots" feature could solve.

How We Customize Menus Today

We do three things repeatedly:

1. Hide built-in commands via boolean flags

gridMenu: {
  hideExportCsvCommand: true,
  hideExportTextDelimitedCommand: true,
  hideTogglePreHeaderCommand: true,
  // ... often 5-8 of these per grid
},
contextMenu: {
  hideCollapseAllGroups: true,
  hideExpandAllGroups: true,
  hideCopyCellValueCommand: true,
  // ... then re-add our own versions
}

2. Add custom command items (composed from multiple layers)

const gridMenuCommandItems = [
  ...baseServiceItems,        // "Reset view" from shared service
  { command: 'refresh-data' },
  'divider',
  { command: 'toggle-indentation' },  // conditional
  { command: 'collapse-all' },
  { command: 'expand-all' },
  ...domainItems,             // e.g. "Show to account groups", "Show to rubrics"
  ...consumerProvidedItems,   // additional items passed via @Input
];

3. Imperatively update menu items for dynamic state

// After toggling indentation, we find and update the menu item title:
const cmd = gridOptions.gridMenu.commandItems.find(
  item => item !== 'divider' && item.command === 'toggle-indentation'
);
if (cmd) {
  cmd.title = this._indentationEnabled ? 'Disable Indentation' : 'Enable Indentation';
}

Pain Points

1. Too many hide flags — We set 5-8 hideXxxCommand booleans per grid just to suppress defaults. A single hideCommands: string[] array or filter function would be much cleaner.

2. Can't customize built-in item appearance — We're limited to iconCssClass + title (plain text). No way to render rich content like icon + text + <kbd> shortcut hint.

3. Hide-then-reimplement pattern — We hide built-in collapse/expand, then add our own versions with the same logic. If the built-in behavior improves, we miss it. We'd love to be able to override rendering of a built-in item while keeping its behavior.

4. No dynamic rendering — Menu items with state-dependent labels (like "Enable/Disable Indentation") require imperatively finding and mutating items after creation.

What Would Help Us

A. Simpler hiding

// Instead of 5 boolean flags:
hideCommands: ['export-csv', 'export-text-delimited', 'toggle-preheader']

// Or a filter:
commandFilter: (cmd) => !cmd.startsWith('export-') || cmd === 'export-excel'

B. Optional slotRenderer for rich content

{
  command: 'reset-view',
  slotRenderer: () => `
    <i class="fa fa-undo text-danger"></i>
    <span class="text-danger">Reset view</span>
    <small class="text-muted">(clears filters & sorting)</small>
  `
}

C. Customize built-in items without reimplementing

{
  command: 'export-excel',  // references built-in — keeps its action
  slotRenderer: (ctx) => `
    <i class="fa fa-file-excel"></i>
    <span>Export to Excel</span>
    <kbd>Ctrl+E</kbd>
  `
}

D. State-aware rendering (eliminates imperative updates)

{
  command: 'toggle-indentation',
  slotRenderer: (ctx) => `
    <i class="fa fa-indent"></i>
    <span>${ctx.gridState.indentationEnabled ? 'Disable' : 'Enable'} Indentation</span>
  `
}

E. "Declarative menu" — start fresh, compose from built-ins and custom items

The biggest friction is that the current model is subtractive — you start with all the defaults and then hide what you don't want. What if we could flip it to be additive? Something like a menuTemplate where you declare exactly what you want, in what order, referencing built-in commands by name:

gridMenu: {
  // Opt into full control — no defaults are added automatically
  menuTemplate: [
    { builtin: 'export-excel' },                          // built-in, default rendering
    { builtin: 'export-excel', title: 'Custom Title' },   // built-in, override title
    { builtin: 'export-excel', slotRenderer: () => '...'}, // built-in, custom rendering
    'divider',
    { builtinGroup: 'column-picker' },                     // entire built-in section
    'divider',
    { command: 'my-custom', title: 'My Action', action: () => {} }, // fully custom
    { command: 'show-to-level-1', title: 'Show to Account Groups', action: () => this.showToLevel(1) },
    { command: 'show-to-level-2', title: 'Show to Rubrics', action: () => this.showToLevel(2) },
    'divider',
    { builtin: 'clear-sorting' },
    { builtin: 'clear-filters' },
  ]
}

This would:

• Eliminate all hide flags entirely — you only list what you want
• Give full control over order — no need for positionOrder hacks
• Allow mixing built-in and custom items freely
• Keep it simple — no menuTemplate? You get today's behavior (backward compatible)

This is actually the pattern we end up building ourselves on top of the current API — we assemble arrays from multiple sources, push items, add dividers. It would be much cleaner if the library supported it natively.

A hybrid approach — keep title+iconCssClass for simple cases, add optional slotRenderer for rich content, and (ideally) support a declarative menuTemplate for full control — would be ideal. Backward compatibility is important to us.

Happy to share more details or code examples if useful!

[zewa666]

please dont stress bc of me. we're finalizing the current master update, so if we get v10 by end of march I'm happy bc I have other tasks to jump on from next week

[ghiscoding]

yeah that's ok, I just need some time mainly to see if there's breaking changes coming out of this and if so when (v10 or v11).

also @jr01 I forgot to provide the full interface related to the renderer callback, it actually has 2 arguments (item, args) both are useful for the dynamic stuff you mentioned above, the item is the menu item and the args is typed as any because it's different depending on the which menu type is being used, I could probably improve the typing by using Generics in the future. So anyway, here's the full interface

  /**
   * Default slot renderer for all menu items.
   * This will be used as the default renderer for all items unless overridden by an individual item's `slotRenderer`.
   * The renderer receives both the menu item and args for full context access.
   *
   * @param item - The menu item object (`MenuCommandItem` or `MenuOptionItem`)
   * @param args - The callback args providing access to grid, column, dataContext, etc.
   * @returns Either an HTML string or an HTMLElement
   *
   * @example
   * // Return HTML string
   * defaultItemRenderer: (item, args) => `<div>${item.title}</div>`
   *
   * // Return HTMLElement (e.g. Cell or Context Menu)
   * defaultItemRenderer: (item, args) => {
   *   const div = document.createElement('div');
   *   div.textContent = `${item.title} (Row ${args.dataContext.id})`;
   *   return div;
   * }
   */
  defaultItemRenderer?: (item: any, args: any) => string | HTMLElement;

[ghiscoding]

@jr01 ok so I tested with a callback function which would allow you to filter/sort or add extra command items and if I'm not misunderstanding, I think that would solve all your problems, does it? I'm not sure about the callback name commandsBuilder, but I guess it represents well what it does, feel free to provide better naming. This new function is executed just before rendering all the commands in the DOM.

here's the interface

/**
  * Command builder, this function is executed after `commandItems: []` and is also the last call before rendering in the DOM.
  * You would typically use this **instead** of the `commandItems: []`, since you can use this callback to filter/sort the final commands.
  */
commandsBuilder?: (builtInItems: Array<MenuCommandItem | 'divider'>) => Array<MenuCommandItem | 'divider'>;

and you can use it like this:

gridOptions: {
  contextMenu: {
    commandsBuilder: (builtInItems) => {
      return [
        ...builtInItems,
        {
          command: 'delete-row',
          title: 'Delete Row',
          iconCssClass: 'mdi mdi-delete text-danger',
          action: () => alert('Delete row'),
        }
      ];
    }
  }
}

if you want to filter some commands, just do for example:

commandsBuilder: (builtInItems) => {
  return [
    // filter built-in commands
    ...builtInItems.filter((x) => x !== 'divider' && x.command !== 'copy' && x.command !== 'clear-grouping'),

    // similar approach for sorting as well
  ];
}

for dynamic command title (your State-aware rendering), just use the new slotRenderer which has this interface
slotRenderer?: (item: any, args: MenuCallbackArgs, event?: Event) => string | HTMLElement;

{
  command: 'toggle-indentation',
  slotRenderer: (cmdItem, args) => `
    <i class="fa fa-indent"></i>
    <span>${args.dataContext__collapsed ? 'Disable' : 'Enable'} Indentation</span>
  `
}

Side note, at first I had also implemented the hideColumns that you suggested but I'm not sure if we need it since commandsBuilder would probably suffice (but might still be cleaner to have both). However on that note, I think that I should deprecate all hideXYZ flags and also deprecate the positionOrder property, then remove them in v11 next year. I could also do it in v10, but it might be better to provide a bit more time for the end user to transition to this new approach!?

So did I cover everything and all of your pain points?

Maybe one more thing that I could do it is to use the action callback for all the menu types. I'm saying this because at the moment, some menu commands are using action (local execution) and some other I use the onCommand callback (global execution using the command name). Using the action for all menu commands would allow the end user to possibly override individual command action callback and/or maybe use the onCommand to run extra code action.

What do you think?

[jr01]

Wauw, impressive you put this together so quickly!

• Global grid options / .forRoot() - fair point, we should be using that more to reduce repetition
• commandsBuilder is exactly what we need. Covers all pain points around hideXYZ flags and positionOrder. Good call on skipping hideColumns since .filter(...) handles that.
• slotRenderer - yes, that example is spot-on! 💯
• deprecation: 100% agree with deprecating hideXYZ + positionOrder in v10.
• action on all commands: really nice! To answer your question: ideally action for local/per-item override, and onCommand still fires globally so we can hook into it for cross-cutting concerns. Both working together would be ideal.

Thanks, really appreciate!!👏 🥇

[ghiscoding]

@jr01 great thanks for confirming the approach, I'm still unsure about skipping the hideCommands, I might still keep it since it would be easier to use and easier to override grid options with it. I'll play with it a bit more and we'll see if I keep or not when I'm done with the feature. But instead of using it on every single command (like I do currently for the hide flags), I could simply do a hideCommnds.filter just before calling the commandsBuilder, that would be a lot less lines of code (basically just 1 loc) so I might go with that approach instead.

For the action, yes your onCommand is always the last thing being called, so if you want to keep the internal action execution and do something extra (after) the action execution, then that would be perfect for you. The main difference is that if you override a built-in command (by using the same command name) and you override the action, then the built-in action will be lost and this wasn't the case when I was using the onCommand instead of the action for the built-in menu commands. The other thing with using the onCommand for built-in was that there was no possible way to override the built-in code execution, but switching to the action callback for built-in now we can override it. Also if we're really want to add our own code in combo with the built-in action, we could retrieve it with the commandsBuilder and decide when to execute the built-in code execution. Something along the lines of:

commandsBuilder: (builtInItems) => {
  // find built-in command to override
  const clearFilterCmd = builtInItems.find(x => x !== 'divider' && x.command === 'clear-filter');
  const originalAction = clearFilterCmd.action;
  // override action
  clearFilterCmd.action = (e, args) => {
    // add your code here
    originalAction?.(e, args);
    // or add your code here
  };
  return builtInItems;
}

So this is possible, even though it's not really recommended. But hey, the idea is that it would be possible and give more customization to the end user. Previously this wouldn't be possible because the built-in onCommand is global and wasn't possible to override at all.

As for the deprecation, yeah I think that is the best approach to give more time for the end user to transition since v10 is already starting to be a bit long to read. If you're curious about the migration, it's not pushed to the docs website yet because it's not merged on the master branch yet but you can see the preview here:
https://github.com/ghiscoding/slickgrid-universal/blob/next/frameworks/angular-slickgrid/docs/migrations/migration-to-10.x.md

So I think I'll be able to do a v10 Beta by the weekend and go stable release by end of February. Thanks for all the feedback, that was super helpful to make the project even better for you 😆

[ghiscoding]

@jr01 the feature was included in PR #2367 and is available in the version 10.0.0-beta.0 release. Give it a try if you can, I'll keep it in Beta for the next 2 weeks in case of feedback or last minute breaking change, then go for stable release at the end of February

Live Demo was also updated and demoing slots rendering:
https://ghiscoding.github.io/angular-slickgrid-demos/#/example51

Some notes about the Slot feature:

• renamed the builder to commandListBuilder
• added hideCommands
• when user reimplement existing built-in command (same name), then all his settings will completely override internal settings, there is only 1 exception, if the user omits the action, then the lib will use the built-in callback (that is the only prop that is copied over when missing, nothing else will be copied), but if the user does provide his own action then that would override the callback.

[jr01]

Hi @ghiscoding - we test-drove angular-slickgrid 10.0.0-beta.0 (+ the matching @slickgrid-universal/* packages) in our production Angular 21 app. Upgraded from v9.12.0, migrated all grid/context menus to the new APIs, and ran our full test suite (~1910 specs). Here's what we found.

What works great

commandListBuilder 👍

This is a great improvement! The old pattern of mixing commandItems[], positionOrder hacks, and hideExportXxxCommand booleans was brittle. With commandListBuilder we get the built-in items (already filtered by hideCommands), spread them, and append our custom items. The composition is explicit and easy to reason about.

slotRenderer

Very useful for items that need dynamic rendering. I used it for a "Toggle indentation" item that reads live state at render time, avoiding imperative title updates. Clean API.

hideCommands: string[]

Cleaner than the individual hideExportCsvCommand / hideExportExcelCommand booleans. Straightforward migration.

Bugs found

1. Some built-in menu commands do nothing when clicked (e.g. Export to Excel and Export to PDF)

Clicking some built-in command in the grid hamburger menu or right-click context menu does nothing — the click is silently swallowed.

Reproducible on the official live demo: https://ghiscoding.github.io/slickgrid-universal/#/example02 — click the hamburger menu → "Export to Excel" → nothing happens. The standalone "Export to Excel" button on that same page works, so the ExcelExportService itself is fine.

Suspected cause: In menuBaseClass.ts, the click handler calls slotRenderer(item, args, e) passing the click event, then checks e.defaultPrevented. If true, it bails out before calling the command's action callback. Something in the rendering pipeline appears to call preventDefault() on the event.

Workaround: None found.

---

2. HeaderGroupingService timer leak crashes test suites

HeaderGroupingService.delayRenderPreHeaderRowGroupingTitles() creates setTimeout callbacks but never stores the timer IDs. When the grid is destroyed before the timer fires, the callback calls methods on a disposed grid:

TypeError: Cannot read properties of undefined (reading 'getVisibleColumns')

This crashes our Karma's afterAll and poisons all subsequent specs.

Workaround: Monkey-patch renderPreHeaderRowGroupingTitles to catch errors:

const hgs = angularGrid.headerGroupingService;
const original = hgs.renderPreHeaderRowGroupingTitles?.bind(hgs);
if (original) {
  hgs.renderPreHeaderRowGroupingTitles = () => {
    try { original(); } catch { /* grid already destroyed */ }
  };
}

Suggested fix: Store setTimeout IDs and clear them in dispose(), or guard against a disposed grid.

---

3. @Input() readonly gridId breaks strictInputAccessModifiers

AngularSlickgridComponent declares @Input() readonly gridId = ''. When strictInputAccessModifiers is enabled (Angular compiler option), template binding [gridId]="..." fails:

[ERROR] TS2540: Cannot assign to 'gridId' because it is a read-only property.

We use that because we some places where multiple grids are in the same page.

Workaround: Custom directive that bypasses the readonly via (host as any).gridId = value:

@Directive({ selector: 'angular-slickgrid[appGridId]' })
export class SlickgridGridIdDirective implements OnInit {
  private readonly host = inject(AngularSlickgridComponent);
  readonly appGridId = input.required<string>();
  ngOnInit(): void { (this.host as any).gridId = this.appGridId(); }
}

Also tried via setting gridOptions.gridId, but the library's mergeGridOptions() always overwrites gridOptions.gridId with this.gridId (the @Input), and the library template uses gridId directly for DOM element IDs and the SlickGrid querySelector.

Suggested fix: Remove the readonly modifier from the @Input() declaration.

Behavioral changes worth noting

Could be these were mentioned in the v10 changes / conversion notes, just listing what we ran into.

• grid.getColumns() now includes hidden columns — code that assumed only visible columns are returned needs to filter by !col.hidden or switch to grid.getVisibleColumns().
• Column picker requires hidden columns in the grid — columns must exist in the grid's column set with hidden: true for the picker to toggle them. Previously they could be omitted entirely.
• Column picker click handler checks event.target.type === 'checkbox' — our tests were dispatching synthetic click events on <label> elements and that no longer worked; click input[type="checkbox"] directly instead.
• New mdi-icon-partial-check CSS class — select-all checkbox now has a partial-check state in addition to check/uncheck.

Summary

Overall the v10 API direction is great 💯 — commandListBuilder, slotRenderer, and hideCommands[] are real improvements that simplify our codebase. Looking forward to v10 with fixes for these issues! 😃 🙏

[ghiscoding]

@jr01 hey thanks for the checks, you found some bugs that should indeed be fixed

1. I wasn't aware of this one, thanks for reporting. This is a new issue because I renamed a Service variable from className to pluginName that I use to search external resource and forgot to update them in Context Menu and Grid Menu. I didn't detect them because I don't have any Cypress E2E tests for Exports.
   • fixed in PR fix: calling Export services from Context/Grid Menu regressed #2397
2. this is an old one, it's been like this for years, I added a bunch of clearTimeout (in few files) so that should fix your issue
   • fixed PR chore: setTimeout should also have clearTimeout to avoid timer leaks #2396
3. that was suggested by @zewa666 but I could remove if it causes problem
   • fixed in PR fix(angular): @Input() readonly breaks strictInputAccessModifiers #2398

So I managed to fix them all in a short time. Thanks a lot for reporting them all. I think it's all good now 🚀

Side note, I merged another PR yesterday that improves accessibility (a11y) significantly and will be included in the final release this weekend (hopefully won't bring regressions). You can see an animated gif in PR #2393

... in the end, all the size gain I had when dropping all enums and other stuff to decrease build size was eventually regrown by adding new features like this new Slot Renderer and a11y improvements. So my v10 build size is now about, or even slightly bigger, than v9. oh well, can't win them all 😆 but it will be smaller if you don't use Row Detail plugin since it's now optional, so there's that 🙃

BTW, I didn't know that you guys had all these challenges with the Menu Commands, so feel free to open any new Discussion in the future if any other improvements like the new Slot Renderer/Builder is possible. It wasn't that hard to implement but the user (you) ends up gaining a lot from this new approach... so feedback is the key 😉

[jr01]

Nice work @ghiscoding 👍

Actually, we do use the Row Detail plugin, so I guess size will be even bigger for us with the v10 😁. Wouldn't "tree-shaking" solve size issues for other lib users?

... so feedback is the key

💯 percent

[zewa666]

yeah my bad on the 3rd one, didnt think its going to cause that ng templating issue

[ghiscoding]

@jr01 @zewa666 thanks for all feedback guys, it's always quite helpful. So I know it got a bit bigger because for our Salesforce usage it requires a bundled standalone zip file (exactly like the old ways of downloading a lib like jQuery and copy it to your lib folder, that's how Salesforce works for external lib sadly) and I saw it increased from 628Kb in v9 to 631Kb in v10 and that bundle doesn't include Row Detail plugin (file on disk of ~3Kb, also it's zip not gzip). So I do see a small increase probably because of a11y improvements, it required a few changes... it should go down again next year in v11 when I drop all hide... flags and most especially if I can start using CSS anchor position, for tooltip & menus positioning, to replace all JS position code with native code.

For size I can't really compare with a demo build because I keep adding new examples 😆 also in Salesforce it's the Vanilla bundle (no frameworks) and tree shaking is done by Vite build (before the zip). But in your case with Angular, you might still get other side to keep or even decrease build size if for example you go Zoneless since it's not longer required by my lib and I wonder if going Standalone in my lib had any impact on build size too (didn't check). Perhaps you can do a build and compare by yourself since you probably have a different branch for the v10 beta... BTW, I'll be releasing v10 this weekend

oh actually I can compare myself by removing the only new slot renderer example51, then do an Angular demo build for both v9 and v10. So it is actually decreasing quite a lot since it was 5.28Mb for v9 and 4.76Mb for v10 (again it's size on disk on Windows). So Zoneless, Standalone and Angular 21 seems to have a quite decent impact on the final size decrease... I like what I see 🚀

BTW, I enhanced the Slot Renderer example which is now also showing button groups (multiple buttons as a menu item), see PR #2410 for a print screen. It's pretty similar to MSSQL extension (print screen above), pretty cool, right?