Continue sidebar menu grouping feature

[adam-code-labx]

@glennjacobs I can see this one was started so I have continued this grouping feature. If we can't make the next beta release then please include in the new develop branch to avoid switching branches 😂

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
getcandy-2-docs	✅ Ready (Inspect)	Visit Preview	Sep 6, 2022 at 4:33PM (UTC)

[adam-code-labx]

@markmead Tooltip updated to group hover.

I have quite a few ideas on improving this menu grouping feature. Already implemented part of this for my client customisations the ability to dynamically populate the menu from the page components.

With this I am introducing a new Resource class to handle the menu and PageComponent to handle the view. The page CRUD components extend the resource so only need to define the navigation once.

<?php

namespace GetCandy\Hub\Http\Livewire\Pages\Products;

use GetCandy\Hub\Http\Livewire\PageComponent;

abstract class ProductsResource extends PageComponent
{
    protected static string $navigationLabel = 'Products';

    protected static string $navigationIcon = 'shopping-cart';

    protected static string $navigationGroup = 'catalogue';
    
    protected static int $navigationPosition = 3;

    public function mount()
    {
        static::setTitle('Products');
    }
}

<?php

namespace GetCandy\Hub\Http\Livewire;

use Livewire\Component;

class PageComponent extends Component
{
    protected static string $view;

    protected static string $navigationLabel;

    protected static string $navigationIcon;

    protected static string $navigationGroup;
    
    protected static int $navigationPosition;

    protected static array $params = [];

    public static function setTitle(string $title)
    {
        self::$params['title'] = $title ?? 'Page';
    }

    /**
     * @param  array  $params
     */
    public static function setParams(array $params): void
    {
        self::$params = array_merge(self::$params, $params);
    }

    /**
     * Render the livewire component.
     *
     * @return \Illuminate\View\View
     */
    public function render()
    {
        return view('adminhub::livewire.pages.'.static::$view)
            ->layout('adminhub::layouts.app', static::$params);
    }
}

This is how it looks currently on my side.

If your interested in including this let me know, I can either refactor the existing page components or create another PR for this one 😜

[glennjacobs]

@adam-code-labx got a few bugs to sort on this one.

Firstly, the styling seems to have gone a bit wrong in places.

The tooltips do not align correctly and are inconsistent. And the icon placement is not centered in the light blue boxes.

Also, it no longer remembers your preference when contracting the menu. If you refresh it will forget and go back to default (expanded).

[adam-code-labx]

@markmead I was about to push a fix but now lots of merge conflicts 😂

[adam-code-labx]

@markmead you can review here then apply the changes just put up temp branch, this is the only commit for the changes. https://github.com/adam-code-labx/getcandy/commit/63901694cc392cd53793cbc293c1d13a30701763

Currently you do have an issue with the setting alignment should only be applied to the main menu items

Also the focus when in the settings menu should be only the settings menu see my collapsedMainMenu override, which will ignore persist if you are in a settings section.

[markmead]

Sorry, @adam-code-labx I was asked to take a quick look as we're getting PRs merged in today!

Welcome to make those changes/fixes, but we want a working persist more than we want the settings menu being displayed by default when on /settings.

[markmead]

Looks good! @adam-code-labx

Do need to run yarn production as the JS is now 37k lines long 😅

Question for @glennjacobs do we want the side menu auto collapsing when a user is on /hub/settings/*?

If we do take that approach, should the same happen for collections and variants?

Additionally, "Orders List" does that sound right? I feel like it should be "Orders" but then you have the issue of the sub-menu header being the same. Looking at what Shopify does, "Orders" is a link and the sub-menu header.

[adam-code-labx]

Ooops that’s what happens with npm run watch 😆

[adam-code-labx]

@markmead @glennjacobs collapsing the main menu if there is a sub menu open is a great idea to focus on the section you are on.

For orders I would change the group name to be something like Sales which would eventually have the following:

Sales

• Customers
• Discounts
• Orders
• Carts

[adam-code-labx]

I feel like soon we will need to consider accordion style collapsible especially once we have some addons in place.

[glennjacobs]

Question for @glennjacobs do we want the side menu auto collapsing when a user is on /hub/settings/*?

I think we can, but only for smaller screen sizes. If there is enough room, it should remain expanded (if that was their preference).

[adam-code-labx]

Ok so I should revert the settings commit? Then just let the user decide?

Let me know if you would like any further changes or @markmead you plan to finish this one?

[glennjacobs]

For orders I would change the group name to be something like Sales which would eventually have the following:

Sales

• Customers
• Discounts
• Orders
• Carts

I think "Sales" works, go with that.

[markmead]

All good for you to finish this one up 🏁 @adam-code-labx

[adam-code-labx]

@markmead @glennjacobs Ok should be good to merge now.

[jonathangustafssonax]

@markmead is there any blocker to merge this in to main?

[glennjacobs]

@markmead is there any blocker to merge this in to main?

We have been testing different menu layouts internally. This is our preference currently.

https://ui-menu.vercel.app/

Ignore the style, it's more about how the menu works. So you'll see the sections are actually replaced with top-level menu items. We are likely to take this route, but was keeping this PR open until we made a firm decision.

[jonathangustafssonax]

@glennjacobs Got it. Any chance to be included for [0.2.0]?

[glennjacobs]

Closing in favour of #680