Menu Item withBadgeIf Issues

[tylernathanreed]

• Laravel Version: 10.25.0
• Nova Version: 4.27.13
• PHP Version: 8.2.10

Description

Context

I was trying to add a badge to a menu item that used a count as a badge. In my specific case, I have a "Support Ticket" resource, and the badge indicates the number of unassigned tickets (prompting an admin to go in and assign them).

MenuItem::resource(SupportTicket::class)
    ->withBadge(function () {
        return SupportTicket::query()->unassigned()->count();
    });

This worked just fine, until I received a request from the business to only show the count when it was non-zero.

This sounds like a simple request, but doing it with the existing Nova technology was awkward.

Option 1: Duplicate the Query

At first, I tried this:

MenuItem::resource(SupportTicket::class)
    ->withBadgeIf(
        fn () =>SupportTicket::query()->unassigned()->count(),
        'info',
        fn () =>SupportTicket::query()->unassigned()->count()
    );

It gets the job done, but it looks weird, and requires making a query call twice.

A quick aside. The withBadgeIf signature really ought to be $badgeCallback, $condition, $type, not $badgeCallback, $type, $condition. I can get around this by using named arguments or specifying info, but it doesn't feel as clean as what I'm used to within the Laravel framework. I would recommend reordering the parameters in the next major version of Nova (as this would be a breaking change).

Option 2: Separate the Calculation & Definition

I also considered doing this:

$count = SupportTicket::query()->unassigned()->count();

return [
    /* ... */
    MenuItem::resource(SupportTicket::Class)
        ->withBadgeIf($count, condition: $count)
];

But I don't like this approach, as I have tons of menu items, and moving the calculation far away from the definition isn't ideal.

Additionally, this didn't actually apply the badge. Apparently, when a non-closure value is passed in, it must be string. This wasn't documented anywhere, and I wasted a lot of time figuring this out. This is due to the withBadge function declaration, which looks like this:

public function withBadge($badgeCallback, $type = 'info')
{
    /* ... */

    if (is_callable($badgeCallback) || $badgeCallback instanceof Badge) {
        /* ... */
    }

    if (is_string($badgeCallback)) {
        $this->badgeCallback = function () use ($badgeCallback, $type) {
            return Badge::make($badgeCallback, $type);
        };
    }

    return $this;
}

I get that the badge's value is expected to be a string, but more effort on the framework's part to actually accept non-string values (namely numbers and stringables) would be greatly appreciated.

Option 3: Bring in Conditionable

Menu Item's aren't normally conditionable, but I extended the class and added the trait. Doing so allowed me to do this:

MenuItem::resource(SupportTicket::class)
    ->when(
        fn () => SupportTicket::query()->unassigned()->count(),
        fn (MenuItem $item, int $count) => $item->withBadge((string) $count)
    )

This is the optional that I ultimately went with, but I felt like I had to jump through too many hoops to do something so simple.

Recommendation

A non-breaking solution to my problem would be to have the badge callback accept the result from the condition, similar to how the conditionable trait does it. Additionally, an attempt should be made to accept integer values as valid badges.

Ideally, I should be able to do this:

MenuItem::resource(SupportTicket::class)
    ->withBadgeIf(
        fn () => SupportTicket::query()->unassigned()->count(),
        condition: fn (MenuItem $item, int $count) => $count > 0
    )

Yet another option is to allow the badge callback to return null (this currently throws an exception), and have null disable the badge. That tweak would allow me to do this:

MenuItem::resource(SupportTicket::class)
    ->withBadge(fn () => SupportTicket::query()->unassigned()->count() ?: null)