where in the panel you'd like to show it. can you send a screenshot or an example?

In this case, that's a resource tool, with a sidebar in the PanelComponent, and the beginnings of a menu in the sidebar component.

I have to hook the stimulus stuff up so it doesn't actually collapse, etc, now

Good job!

I feel it's nice and clean that way, vs having lots of logic in the view

If you don't have it on your radar, I'll keep at it and if it's a clean implementation I'll send a PR for it

render WorkflowEditorMenu.new

somewhere in the code...

that I'm including the same way that you suggest for modifying ApplicationController

but a subclass may be a better way to go

like adding a WorkflowComponent to the ItemSwitcher stuff

we need to think of a good way to do it

do you have a place already that I can put app-specific components?

or even Avo::Sidebar::WorkflowComponent

makes sense to me to keep it in the same module as the rest of the menu

yeah. conventions rule. it's not worth it to break out for this scenario IMHO

(for now I put WorkflowAction in app/lib/avo/menu and the component files in components/avo/sidebar )

so I guess the real question is just where to put the Menu item

alright @lemon-wall-20836 ... been monkeying around with this for a while. Looks like the hard part is going to be adding new menu component types that are app specific to components/avo/sidebar/item_switcher_component.html.erb Have you given any thought at all about how this might be made a little more generic? I have the whole system running with arbitrary menus, but adding app specific components breaks things.

Need a way to either append to that view with custom entries like this: or maybe move that logic to the component ruby file in the #call method.

Would also love to understand why the component type specific stuff (like label, path, target, data, icon in the above example) is in the view there, vs having it in the Avo::Menu::Link class. Feels like LinkComponent should know how to render an Avo::Menu::Link w/o getting anything from the ComponentSwitch helper class

instead of the

ItemSwitcher

(which I created because I was lazy), we add a

def component

method on the

Avo::Menu::BaseItem

which will produce the name of the view component used by the renderer.

ruby
#pseudo code
class Avo::Menu::BaseItem
  def namespace
    # code that transforms classes from Avo::Menu::Link to Link
  end

  def view_component
    "Avo::Sidebar::#{name_without_namespace}Component".safe_constantize.new **view_component_args
  end

  def view_component_args
    {
      label: item.label,
      path: item.path,
      ...
    }
  end
end

so instead we generate the items like so

erb
<!-- Instead of this -->
          <% Avo::App.main_menu.items.each do |item| %>
            <%= render Avo::Sidebar::ItemSwitcherComponent.new item: item %>
          <% end %>

<!-- Something like this of this -->

          <% Avo::App.main_menu.items.each do |item| %>
            <%= render item.view_component %>
          <% end %>

so we can now create new item types for the menu with the item file (ex:

Avo::Menu::Link

) and view component files (ex:

Avo::Sidebar::LinkComponent

) and they can self-register

what do you think about this approach?

I think that with this approach we could extract the whole functionality in an external gem for everyone to use

I have it all working locally in an 'override' fashion right now, so I will take a crack at adapting my local stuff to work this way, and once it's working I'll let you know

looking forward to seeing what you got