"Agnostic" filters - decouple filters from datatables #5714
Conversation
|
Off topic: Would you consider adding support for global filters? Cheers! |
|
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? |
|
Hi @tabacitu, I'm better at writing code than articles. Cheers! |
|
@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 Thanks for the suggestion, eagerly waiting for the PR 👍 |
There was a problem hiding this comment.
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.
pxpm
force-pushed
the
agnostic-filters
branch
from
6e40e3a to
a719f19
Compare
pxpm
changed the title
pxpm
force-pushed
the
next
branch
2 times, most recently
from
1253d3b to
7019815
Compare
pxpm
force-pushed
the
agnostic-filters
branch
from
49d8f33 to
1d88043
Compare
| @include('crud::inc.export_buttons') | ||
|
|
||
| <script type="text/javascript"> | ||
| // TODO: this needs to be agnostic per filter navbar as in the future hopefully we can have more than one |
There was a problem hiding this comment.
VERY good catch! Do we need to do this now, or can we do it later, as a non-breaking change? Cause it's a pretty big thing.
There was a problem hiding this comment.
I think we can do it later as non-breaking
[ci skip] [skip ci]
pxpm
force-pushed
the
agnostic-filters
branch
from
86266b1 to
fb3a80c
Compare
* wip * wip * Apply fixes from StyleCI [ci skip] [skip ci] * wip * Apply fixes from StyleCI [ci skip] [skip ci] * remove filters navbar component --------- Co-authored-by: StyleCI Bot <[email protected]>
* wip * wip * Apply fixes from StyleCI [ci skip] [skip ci] * wip * Apply fixes from StyleCI [ci skip] [skip ci] * remove filters navbar component --------- Co-authored-by: StyleCI Bot <[email protected]>
* wip * wip * Apply fixes from StyleCI [ci skip] [skip ci] * wip * Apply fixes from StyleCI [ci skip] [skip ci] * remove filters navbar component --------- Co-authored-by: StyleCI Bot <[email protected]>
* wip * wip * Apply fixes from StyleCI [ci skip] [skip ci] * wip * Apply fixes from StyleCI [ci skip] [skip ci] * remove filters navbar component --------- Co-authored-by: StyleCI Bot <[email protected]>
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.phpoverwritten yes it is.