Primeng: [Discussion] Why MenuModel API?

[marcelcremer]

Hello,

I want to ask a general question and maybe some others can also give feedback. Why does more and more in PrimeNG become configurable with the MenuModel API?

The reason I'm writing this is, because in the new Release, the SplitButton also became a victim of the MenuModel API.

I have now several lines of code with the MenuModel API and I'm not the biggest fan of it. Here are some Reasons:

• Ugly nested JSON
  I mean... just look at http://www.primefaces.org/primeng/#/megamenu and you'll see my point. Read out loud all Entertainment2 Sub-Elements without using the search function in 5 Seconds...and It's over :)
• Menus not visible in HTML-Template
  This is the counter-part to the last point. Before the MenuModel API, you could just look in the HTML Template and see what the Frontend renders. Now it's hidden in the background.
• Command binding
  To make sure, that you have the correct "this"-object in the command function, one has to make sure that the function is bound to this. This leads to ugly commands like
  { label: 'Do Something', icon: 'fa-sitemap', command: this.doSomething.bind(this) }
• Context-Sensitive Functions
  Can anyone tell me, how to pass the index of the current loop to the MenuModel API Command function? I really don't know how to do this. Example:
  <p-splitButtonItem icon="fa-trash" label="Delete Condition" (onClick)="removeCondition(index)"></p-splitButtonItem>
• Code generation for dynamic Menus becomes necessary
  With the old Items, it was easy to create dynamic Menus just by using Angular2 Stuff. With the MenuModel API, someone must write and test new methods that generates Menu Models. Here's an easy example that worked before:
  <p-splitButton label="Ticketing" icon="fa-headphones" (onClick)="navigate('/admin/tickets')"> <p-splitButtonItem *ngFor="let type of ticketTypes" [icon]="type.icon" [label]="type.name" (onClick)="navigate('/admin/tickets/' + type.id)"> </p-splitButtonItem> </p-splitButton>
• No custom Templates
  With the Old Item-based approach, it would've been easy to add custom templates for menus later. Now that the MenuModel API is there, it won't be possible in the future.

I hope no one sees that as an offense and would love to get some feedback from others about this.

Have a nice Weekend
Marcel

[reach4thelasers]

I love PrimeNG, but the MenuModel is awful - just awful. Every single item needs its own command callback.... Would it not make sense to have a single callback for the whole menu and pass in the item that was clicked. I've got a multi-level nested menu and need to loop though every item in every level and assign the same callback to each one.

It supports router, but with no way of passing route params?? I literally can't see how I can work with this?

Getting the item that was clicked is pretty fundamental - am I missing something here?

[marcelcremer]

@cagataycivici Could you maybe give some insights on this before PrimeNG goes RC? :)

[rapptor789]

I have similar issues..

How to create dynamic menus based on conditions?

For example: I have a DataTable with ContextMenu. Now I want to render a ContextMenu based on the data in the selected row. I don't know how I should handle this, because the context menu was generated onInit and it is defined for all rows in the DataTable...

How can I pass parameters to routerLink? The following Code doesn't work
this.items = [{label: 'Open', routerLink: ['/newSite','selectedParameter.id']}];
When I write the second parameter without quotes then I get an error from the typescript compiler...

Has someone any suggestions?

[cagataycivici]

Sorry for the delay, we are on different things at the moment regarding PrimeNG.

@darkwarriorn4p For routerLink issue, please create a new ticket, that should work. #954 should help as well if we fix it.

About MenuModel, to begin with, what would be the alternative? Something like following;

<p:menu>
  <p:submenu>
    <p:menuitem>
  </p:submenu>
</p:menu>

• Nested json and
  I agree it doesn't look on big menus but it would be the same story with declarative elements as well like p-menuitems everywhere.
• Menus not visible in HTML-Template
  I don't think this is a big issue.
• Command binding
  What could be the alternative?
• Context-Sensitive Functions
  What do you mean by the index loop? The index of the splitButtonItem?
• Code generation for dynamic Menus becomes necessary
  Isn't this required only once so that you can reuse?
• No custom Templates
  Yes, menus are pretty much static in terms of templating.

[mischkl]

I have another use case which would work better with a template-driven approach: being able to add things like custom styling, custom attributes (directives), custom filters, or custom content to individual menu items. With the current approach none of this is possible. (OK, filters are possible but not as convenient.) One great example is the ability to highlight a menu item according to whether a certain route is selected. Normally you would just use the routerLinkActive attribute directive to add a class when the linked route is active, but with the current system it's not possible.

In answer to the question from @cagataycivici: I guess command binding is simply a matter of adding a (click) handler to the menu item? Or does the command binding do something more than simply binding a callback to a click?

I'd also like to propose that maybe the ability to use the MenuModel could be offered as an alternative to using pure templating. I do believe there are some use cases where it is a benefit to be able to dynamically generate the menu structure in code, and other cases where it would be nicer to simply use templating.

[rapptor789]

Hint for dynamic contextmenu based on content in the datatable:

I use the undocumented datatable event: onContextMenuSelect to generate a dynamic context menu.

[cagataycivici]

We're so much in to the MenuModel API now, in PrimeNG components and the premium templates, better to stick with it.