EnsembleUI / ensemble-react

BSD 3-Clause "New" or "Revised" License
15 stars 1 forks source link

Sub-Items in the Menu #799

Open justEhmadSaeed opened 2 months ago

justEhmadSaeed commented 2 months ago

Is your feature request related to a problem? Please describe. Need sub items for the menu items that can be collapsed or expanded. Feature Request Ticket image

Describe the solution you'd like A clear and concise description of what you want to happen.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

amin-nas commented 2 months ago

@anserwaseem @evshi here's a proposal for EDL

  Sidebar:
    styles:

      # expose styling of group and its items
      groupPadding:
      groupItemTextStyle:

    items:
      - type: navItem # default type, and what is supported today
        label: Home 
        page: home

      - type: navGroup
        label: Products
        collapsable: true # default
        collapseByDefault: 
        collapseIcon:
          # icon properties
        expandIcon:
          # icon properties  
        items:
          - label: Product A
            page: products/a
          - label: Product B
            page: products/b
anserwaseem commented 2 months ago

@amin-nas In addition to label, we also support customItem. If there are child items (e..g Product A, Product B in EDL above) - a sub-menu can be displayed, so what purpose does type serve?

amin-nas commented 2 months ago

@amin-nas In addition to label, we also support customItem. If there are child items (e..g Product A, Product B in EDL above) - a sub-menu can be displayed, so what purpose does type serve?

My thinking is that

  1. Better to be explicit, instead of saying "if you add sub-items, then it behaves like a group"
  2. We can expand on this and support more types, such as divider, nav section header, ...

cc @vusters, @kmahmood74 - please chime in if you have other ideas

evshi commented 2 months ago

@anserwaseem @amin-nas @justEhmadSaeed this layout is possible already via custom widgets and collapsible containers, and actions.

If we're trying to optimize the YAML, then adding additional attributes to support this seems counterproductive. I think we need to maintain the decoupling of routing and presentation and not create a specialized way to define sub menus. Is there a strong reason not to support nested ViewGroups? A ViewGroup represents a logical group of routes in your app, and supports defining presentation for each. If an item routes to another ViewGroup, then that is a sub menu?

vusters commented 2 months ago

@anserwaseem @amin-nas @justEhmadSaeed this layout is possible already via custom widgets and collapsible containers, and actions.

If we're trying to optimize the YAML, then adding additional attributes to support this seems counterproductive. I think we need to maintain the decoupling of routing and presentation and not create a specialized way to define sub menus. Is there a strong reason not to support nested ViewGroups? A ViewGroup represents a logical group of routes in your app, and supports defining presentation for each. If an item routes to another ViewGroup, then that is a sub menu?

It'll be pretty miserable UX for the user though. I think we should simply ViewGroup rather than making it link to different ViewGroups.. e.g. which is the main one? what happened when i delete one ?, not to mention it'll be hard to support in the Visual Editor. I think we should stick to a simple flow. What @amin-nas has above is simple enough:

...
Sidebar:
  items:
    - label: Home
       page: Home
    - label: Settings
       page: # this is now optional if you want the root to be navigable or not
       type: navGroup
       groupOptions:
           icon*...
        items:
             ....

The important thing is page attribute has to be optional for the group, the type will help you differentiate that and be more explicit.