"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 👍 |
* add method to get ajax uploaders * Apply fixes from StyleCI [ci skip] [skip ci] * use an abstract class * wip * Apply fixes from StyleCI [ci skip] [skip ci] * refactor uploaders * Apply fixes from StyleCI [ci skip] [skip ci] * refactor rules * Apply fixes from StyleCI [ci skip] [skip ci] * move ajax to PRO, cleanup * Apply fixes from StyleCI [ci skip] [skip ci] * make attributes available for all subfields * fix tests * wip * Apply fixes from StyleCI [ci skip] [skip ci] * upload multiple and upload properly working 🙏 * fixes * Apply fixes from StyleCI [ci skip] [skip ci] * allow the configuration of valueWithoutPath call. * fix valid upload inside repeatables * Apply fixes from StyleCI [ci skip] [skip ci] * fix condition * cleanup * fix * Apply fixes from StyleCI [ci skip] [skip ci] * fix use case for enabling validation after entry is created * Apply fixes from StyleCI [ci skip] [skip ci] * dont save array keys * fix ajax validation * fix validation messages * Apply fixes from StyleCI [ci skip] [skip ci] * fixes ValidUpload * Apply fixes from StyleCI [ci skip] [skip ci] * dont json encode if casted in the model * Apply fixes from StyleCI [ci skip] [skip ci] * fix previous file identification in repeatable * Apply fixes from StyleCI [ci skip] [skip ci] * fix getting values * Apply fixes from StyleCI [ci skip] [skip ci] * add fake fields support * Apply fixes from StyleCI [ci skip] [skip ci] * wip add uploaders tests * Apply fixes from StyleCI [ci skip] [skip ci] * wip * Apply fixes from StyleCI [ci skip] [skip ci] * add pro columns * fix test suite * fix tests * ffix tests * remove unused test views * add uploaders to test coverage * Apply fixes from StyleCI [ci skip] [skip ci] * add coverage folder to gitignore * make tests run faster by not reloading db when not necessary * add coverage to validation tests * add fake tests to uploaders * Apply fixes from StyleCI [ci skip] [skip ci] * add more tests * Apply fixes from StyleCI [ci skip] [skip ci] * wip * Apply fixes from StyleCI [ci skip] [skip ci] * wip * wip * Apply fixes from StyleCI [ci skip] [skip ci] * wip * Apply fixes from StyleCI [ci skip] [skip ci] * add more upload assets * fixes * Apply fixes from StyleCI [ci skip] [skip ci] * fix single file * Apply fixes from StyleCI [ci skip] [skip ci] * add image column * fix tests * Apply fixes from StyleCI [ci skip] [skip ci] * remove hardcoded macro names * Apply fixes from StyleCI [ci skip] [skip ci] * remove double loop, fix single file uploader * Apply fixes from StyleCI [ci skip] [skip ci] * use a big increments and unsigned for primary key * handle pivot file deletion * Apply fixes from StyleCI [ci skip] [skip ci] * register events for relation models * Apply fixes from StyleCI [ci skip] [skip ci] * fix typo * Apply fixes from StyleCI [ci skip] [skip ci] * fix relationship uploaders * Apply fixes from StyleCI [ci skip] [skip ci] * wip * Apply fixes from StyleCI [ci skip] [skip ci] * wip * Apply fixes from StyleCI [ci skip] [skip ci] * update temporary time key * save objects in the macro --------- Co-authored-by: StyleCI Bot <[email protected]>
* wip * clean up * add get uploadedFilesFromRequest to clean up uploaders * Apply fixes from StyleCI [ci skip] [skip ci] * fix type cast * add summernote uploader * update summernote * add summernote * add more test assets --------- Co-authored-by: StyleCI Bot <[email protected]>
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
[ci skip] [skip ci]
pxpm
changed the title
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 🤷♂️
There was a problem hiding this comment.
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 👍
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.