Exclude an event if model has a certain state

[Lednerb]

At the moment I'm including a Task model with an expiration date to the calendar, that works fine so far.

However, I did not find an option in the docs that provides the possibility to exclude an event from the calendar.

I'm thinking about something like this (taken from the README,.md):

use Wdelfuego\NovaCalendar\Event;

protected function customizeEvent(Event $event) : Event
{
   ...
    if($event->model())
    {
        ...
        if($event->model()->isInACertainState())
        {
            $event->addBadges('⚠️');
        }

        if($event->model()->is_finished) {
            $event->hideOnCalendar();
        }

        ...
   }
   ...
    return $event;
}

Simply returning null does not work because an Event object has to be returned.

If I'm not missing a simple thing and this is actually not possible at the moment than this would be a Feature Request ;-)

[Lednerb]

Okay, this was a quick one, but for documentation purposes:

Just add a custom style:

public function eventStyles(): array
{
     return [
            'hidden' => [
                'display' => 'none'
            ],
      ]
}

and on the $event you can add:

        if($event->model()->is_finished) {
            $event->addStyle('hidden');
        }

[wdelfuego]

Ha, that's a nice creative css workaround :)! You can rely on it temporarily but it might break things in the future when the amount of events returned could potentially be used to calculate layout rules or something like that.

I have an update in the works that allows real event hiding, stopping them from being relayed to the front-end, which fixes #12 and allows the developer to not relay events to the front-end based on whatever condition. It will be released within weeks. Until then, your solution is a nice work-around 👍 .

[Lednerb]

Nice!
I will update the marked answer once the update is published.

The CSS workaround will also slow down the frontend if there are a lot of entries.

[wdelfuego]

I have just released 1.3 with support for an exclude method in your CalendarDataProvider, please see the updated README 👍

[Lednerb]

Hey and thank you for the quick addition!

I've implemented it in my case like this in order to support arbitrary other classes too:

use Laravel\Nova\Resource as NovaResource;

...

protected function exclude(NovaResource $resource): bool
{
    if (get_class($resource) == 'App\Nova\Task') {
        return $resource->model()->is_finished;
    }

    return false;
}

Maybe updating the README for $resource->model() instead of $resource->resource is more obvious and more laravel-styled than the double name with a comment?

[wdelfuego]

Hey Sascha, thanks! Ooh that’s a good point, will do 👍.

I’d personally opt for ‘instanceof’ instead of using get_class and a hardcoded class name, by the way, but of course that implementation should work just fine.

I’m considering moving some responsibilities to the Nova resources themselves for the 2.0 release, to avoid a bloated CalendarDataProvider. So I’m thinking of a Calendarizable interface + trait for Nova resource classes and then you wouldn’t have to do class checks in the data provider. Things like exclude and maybe even customizeEvent could then be moved to the nova resource classes themselves. As always, very interested to hear your insightful feedback on this idea :).

Thanks for all your input, really valuable!

[Lednerb]

I’d personally opt for ‘instanceof’ instead of using get_class and a hardcoded class name, by the way, but of course that implementation should work just fine.

That's also a good idea, in my special case the get_class method is a better fit, because instanceof also returns true if a subclass is checked.

I’m considering moving some responsibilities to the Nova resources themselves for the 2.0 release, to avoid a bloated CalendarDataProvider. So I’m thinking of a Calendarizable interface + trait for Nova resource classes and then you wouldn’t have to do class checks in the data provider. Things like exclude and maybe even customizeEvent could then be moved to the nova resource classes themselves. As always, very interested to hear your insightful feedback on this idea :).

In my opinion I would prefer a larger CalendarDataProvider instead of having the calendar data and settings distributed over the Nova Models so to speak. In my opinion the nova-calendar package is handled as a thrid-party component and if one is going to replace it with another package it would be nice to not have to modified all related nova classes etc.

I've just developed a nova resource tool and do often struggle with implementing functionalities in dependency to laravel nova itself or handle options and functionality by my own classes and ToolServiceProvider.

So I think it would be best to stick with one (or more) Data Providers.
Furthermore it's more flexible than within the Nova classes, as you already mention it here with the possibility to have more than one data provider or calendars: #3 (comment)

---

However, one other option for handling the excludes that I'd expected and that would reduce the complexity / lines of code within the data provider is to have an $event->exclude() function that is usable within the customizeEvent method like:

if ($task->expiration_date->lt(now())) {
    $event->addStyle('warning');
    $event->addBadge('⚠️');
}

if ($task->is_finished) {
    $event->exclude();
}

[wdelfuego]

Good points! Thanks.

The point about multiple data providers is a very good one. I think I’ll keep the current approach functional in any case and might add the option to also work with an interface and a trait on the nova resources themselves, but completely optional for those who prefer it and for operations that apply regardless of the data provider.

I considered having an ‘$event->exclude’ option as you describe, but opted for a resource based exclusion model because that connects better with Nova’s authorization model and prevents the generation of events that will not be displayed later. Right now event generation isn’t awfully expensive but I’m working on an update that allows one nova resource to generate any amount of events (#11) and in that case it is computationally more efficient and makes more architectural sense to decide on a Nova resource level whether to include its event(s) or not and to let the nova resource decide which events to generate in the first place, I think. Open to discussion :)!