"Agnostic" filters - decouple filters from datatables

[pxpm]

WHY

BEFORE - What was wrong? What was happening before this PR?

Filters were tightly coupled with the datatable making it impossible to use in a page that didn't had the datatable.

AFTER - What is happening after this PR?

Filters can be used in any page, and developer can configure the actions to perform when they are enabled/disabled.

HOW

How did you achieve that, in technical terms?

transformed the filters_navbar into a component that can be reused.
refactored the filters to emit events when they are changed.

Is it a breaking change?

If you have filters_navbar.blade.php overwritten yes it is.

[susanu]

Off topic: Would you consider adding support for global filters?
Example: A filter that will be displayed on all pages, lets say a date range filter.
On the cruds that have a date range filter, just take the values from the global one (if you set it this way).
Use case: You want to see statistics about last week on multiple cruds and don't want to set the date range every time you navigate to the crud.

Cheers!

[tabacitu]

Hi @susanu - I think that's an interesting idea, but a very niche one. I see how it would be useful (I have a company select in one project too). But I don't think Backpack needs to help with it... it's ok for the dev to do it custom, since it's IS very custom, and particular to that project. We're not looking to add any "could-have" features, only "must-have" and "should-have". But it would make for a very interesting article - I'll give you that! Wanna write it?

[susanu]

Hi @tabacitu,

I'm better at writing code than articles.
After v7 is released and filters can be reused in other places, i will submit a pull request, when time allows it, for this feature.

Cheers!

[pxpm]

@susanu "theoretically" that's already possible.

You can store the "global" filter (you can't use the native filters (yet!)) in a session variable, and add a middleware, or similar approach, that reads from that session variable and redirects the user to say admin/invoices?date=2024-01-01. If the date filter exist on the invoice crud, it will be automatically applied.

Thanks for the suggestion, eagerly waiting for the PR 👍

[tabacitu]

I agree with making it a component. I agree with the naming. Please redo the event names so it's backpack:filters:clear like I said in https://github.com/Laravel-Backpack/PRO/pull/296 too, merge next into this, test it, and give it back.

[tabacitu]

What if we move all this code back to crud::inc.filters_navbar... and have the component blade file just do @include('crud::inc.filters_navbar')? That would give us both the benefit of having a component people can easily use... and make this less of a breaking change... right?

[tabacitu]

Or waaaait. Since FILTERS are a PRO feature... wouldn't it make more sense to move the component and blade file.... inside the PRO package? 👀 If we are to move files around... at least we would solve that issue too 🤷‍♂️

[pxpm]

In part it makes sense, the filters we have are all in PRO, but from other perspective "filters" != "filters framework". WDYM ? Well, filters_navbar it's the "suppport" for any filters, ours in PRO and any custom filters developers may have. So we ship the "filter framework" in the core, but we built our filters in PRO.

I imagine a scenario where we develop a package and that package has their own filters (not using the pro ones), if we move this to PRO, that package must depend on PRO just to have the filters navbar where it can add the filters. Also, the CrudFilter class is in core not in PRO, so I think it makes sense to keep this on the core and not move it to pro.

Your call 👍