[Feature Request] Add filtersView() to v2/v3

[cuberinooo]

First of all thank you for your hard work and this package is great. Im missing a useful feature: https://rappasoft.com/docs/laravel-livewire-tables/v1/filters/custom-filter-view

Can we get this in v2 or is there are workaround ?

[lrljoe]

I'll certainly look at it, what were you trying to achieve out of interest as there may be a workaround.

There is an option for a Custom Label Blade and Custom Pills Blade. I just hadn't thought about the filter blade itself.

[cuberinooo]

Thank you !

Right now we are trying to upgrading the package from v1 to v2. For some filters we created our own blade template where we render the UI for specific filters. It was great because you just need to point to a specific path as it is described in the v1 doc. Little feature but it is really flexible at least for our use case.

[lrljoe]

No promises on timescales, but I will take a look at some options.

In the meantime, you could publish the views for the filters, and customise the blades there. In theory, you could pass a config() option to the filter, and then use that config setting to determine how to render the blade. That'd work for the meantime at least!

I have stuck a few additional filter options in a separate package (for now at least) which may interest you if you're migrating to V2. LaravelLivewireTablesAdvancedFilters. I mainly use Tailwind, so that implementation is cleaner than the Bootstrap look/feel, but is a work in progress, one of the next releases for that add-on package is Component Filters, so I should be able to port some of the code for customising filter blades back across easily enough.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lrljoe]

This will probably be a v3 feature, unless I have a burst of inspiration in the next couple of weeks.

V3 will be an interim version introducing some new Livewire 3 dependent features.

Then v4 will be a major rework.

[lrljoe]

I've added this to the v3 project board, as we're going through any last additions for the initial release this week.

It may not make it in for v3 initially, but it's in the project and will be addressed!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lrljoe]

Removing wontfix label. This is in dev pipeline for v3

My current plan for filters is the following:

1. Add toggle (Per-Filter) for Filter Validation rules
   The filters all have validation rules against them, that may prevent smooth functioning of a custom filter view

2. Add custom Filter view (per-Filter)
   Depends on the previous item

3. Update Existing Filter Validation methods for Native Laravel methods
   No dependency, but won't be progressed before item 1

4. Allow setting of Custom validation rules (per-Filter)
   Allow for customisation of the validation rules

5. Enable "hideIf" functionality (similar to Columns)
   No dependency, this is likely to come alongside item 2.

Current Roadmap Screenshot

[nathan-io]

This topic is of great interest to me as well.

Our use case for a custom filter view, beyond just wanting more control over layout, is that we want to scope some filter options based on the value of others.

For example, we have a "Metal" filter. Based on the selected value, we'd want to scope the queries we use to build options for the other filters to just get models associated with the selected metal_id.

My hope is that we can accomplish this by using a Livewire component as our filters view, and having it pass the $value and $values to be filtered on.

[lrljoe]

Independent and LW Component filters are definitely in the pipeline, particularly for v3. So it'll be possible to natively link filters.

Happy to explain how to build an independent filter on Discord in the meantime though.

There are a few mandatory methods for it to work with the package, but the rest is open.

I previously published an addon package containing additional filters for this package, it is very straightforward to achieve if you have specific needs!
Most of them are now in v3, but I did create other filters (select2 style, linked dropdowns etc) that I haven't ported in yet.

A large chunk of v2 to v3 was cleaning up the views, code, and improving performance as it'll be easier to customise going forward.

[lrljoe]

This topic is of great interest to me as well.

Our use case for a custom filter view, beyond just wanting more control over layout, is that we want to scope some filter options based on the value of others.

For example, we have a "Metal" filter. Based on the selected value, we'd want to scope the queries we use to build options for the other filters to just get models associated with the selected metal_id.

My hope is that we can accomplish this by using a Livewire component as our filters view, and having it pass the $value and $values to be filtered on.

I have a working example for your ask for v3 using two select filters (one of which does nothing to the query i.e metal, then the other updates options from that)

Caveat is, I haven't yet added grouping etc, so it'd visually appear to be two distinct filters at the moment

[nathan-io]

This is awesome, thank you!

When do you anticipate the v3 docs will start rolling out?

[lrljoe]

This particular example isn't in the repos yet as it does need one tweak to the rendering approach, but you can see some of the new docs by browsing the "docs" folder in the v3-develop branch.

I'm hopeful for maybe back end of next week to have a proper beta release which will also add this function, and add the docs to the main website for easier reading.

Sent from Outlook for Android

[lrljoe]

This one is still in progress for v3, along with use of a Livewire Component Filter.

Definitely days/weeks rather than any longer

Just tied up with bugs etc

[lrljoe]

Edited to display as feature request.

This is very much on roadmaps.

V3 has several filter improvements inbound, including this.
This is presently the only filter features backport that I (personally) intend to add, once in v3

[nathan-io]

I have a working example for your ask for v3 using two select filters (one of which does nothing to the query i.e metal, then the other updates options from that)

Hi, wanted to see if you could share the examples if they aren't already committed somewhere.

[lrljoe]

@nathan-io - I'll add a doc detailing this over the weekend.

[nathan-io]

Glad to see a stable release! Thanks for your hard work on this. I checked the filter docs but they don't seem to mention this yet.

[lrljoe]

It's coming (still!), there's a couple of bits that I wanted to nail before that, to make life easier for anyone wanting to do this (as well as extending Filters etc).

I'm hoping to finish that work this week, as I didn't want people working on something that then changed!

[lrljoe]

For v3, this should be in the next (imminent) release!

[lrljoe]

This is now out for V3. For v2, it'll be a backport, so may be a week (or three)

[nathan-io]

Awesome, thank you! I see the relevant docs.

Our likely use case would be to include a Livewire component in the custom view. That component would handle updating the options based on the other active filters and their values.

If you're able to share the working example of two filters where one affects the options for the other, that would be really helpful in understanding how to use this.

As for the view, are there any certain requirements as to how options/data are handled? I think the changelog mentioned a DTO for filter data.

[lrljoe]

Just so I can prioritise writing up examples, are you after:

Select Filter 1 -> Does Not Filter, but Changing Populates/Changes Select Filter 2's options
Select Filter 2 -> Actually Does Filtering

[nathan-io]

Our current use case would be:

Select Filter 1 -> Does Filter, and Changing Populates/Changes the options of multiple other filters
Select Filters 2, 3, 4, etc. -> We need to know the value of select filter 1 to scope the options for some of these

We have a column metal_id which is filterable and sortable.

In filter(), when we're querying the table to build the filter options, we'd like to be able to scope whereIn('metal_id', $filterValues) on them. This way, we exclude filter values which have no associated model with the filtered metal_id.

While being able to do that at mount (with whatever filters have been preset) is helpful, the scope needs to change if someone changes the metal_id filter value.

---

My initial thought was that by utilizing a custom view where we could mix Livewire components, we could achieve this dynamic between the filters. And then that view could somehow pass that data to the table, which would then query with the filtered scope and update the DOM.

If it's possible to dynamically regenerate the secondary filter options using the stock filters without needing a custom view, even easier!

[lrljoe]

Yep, that won't be an issue, just wanted to make sure I understood before I wrote it up.

It's possible to do this with the present implementation, but not particularly cleanly/smoothly. I'll add the relevant methods in to make it a bit tidier before I give you the working examples.

[nathan-io]

Thank you!

[nathan-io]

I made a correction in the last part of my comment above. 🤦 Hope it makes sense now.

[nathan-io]

Looking at the setCustomView() doc/example again, I realize that I was misunderstanding the purpose of this method.

It isn't used to define a custom view where all of your filters live, but rather, the view for a specific filter. 🤦

Still, the requirements within the custom view remain unclear to me. Presumably, in our view we'd need the values for attributes like id, value, and wire:key to conform to whatever convention is expected by the package.

---

When talking about filter customization, it seems to boil down to two areas:

• Layout and UI (being able to use whatever input elements we want, laid out however we want - so this could be a mix of Alpine components, LW components, etc.)
• Interactivity between filters (ie. a selection on one filter changes the options for others)

One approach which seems like it would solve for all of this is to let us define a custom Livewire component which is responsible for rendering all filters and dynamically updating their options as a user makes selections. (To clarify, I mean that in the view for this LW component, we would have all of our filters together. This could be a mix of Blade components, other LW components, and regular Blade markup.)

Each time the user makes or changes a filter selection, the component would trigger livewire-tables to re-query based on the updated filtered scope and refresh the DOM.

Hope this makes sense.

[nathan-io]

Thanks so much!

Some of the new lifecycle hooks (imminent) will also help with this.

Yes, I was wondering if there was a way to listen for some sort of event and run filters() again each time the user activates a new filter or updates their selections on an already active filter.

The idea would be that in filters(), we could use when() in the queries which get the filter options to scope those queries based on the values of any active filters.

Of course, the DOM would then have to be updated to reflect the updated filter values, perhaps that's a showstopper until v4.

[lrljoe]

With some of the new lifecycle hooks, I've run a quick test, and was able to do:

Filter A - Continents List
Filter B- Countries List

When "Filter A" changes, the standard Livewire Lifecycle Occurs,
"Filter B" then only has options for "Countries" that are in the "Filter A" continent

Running filters() more than once can often prove painful.

What does your filters() {} look like at the moment?

[lrljoe]

So the post filter hook should do what you need.

If you're on the Discord then ping me a message and I'll let you know when it goes into develop as it'll be in there for a week or so ahead of the next release so that you can validate that it's workable for you.

[nathan-io]

Sorry for the late response! Is the post filter hook now available?

Also, I've been wondering if it is possible to take another approach:

Instead of using the package's native filter UI, we create a separate Livewire component which contains all filter input elements and an "Apply" button. We'd handle all of the interactivity between filters, dynamic value population, etc. within that component.

When the user clicks Apply, the component tells the laravel-livewire-tables component that the active filters and/or values have changed, causing it to refresh the table based on the new filtering criteria.

So essentially, we'd still be using the package's native filtering functionality in that our filter keys and queries would still be defined in the laravel-livewire-tables component, but our actual filter UI would live in our custom filter component.

Is something like this possible?

[lrljoe]

@nathan-io apologies for the delay!

Coming very soon will be the ability to replace the filter menu (pop-over/slide-down) blade with a custom blade of your choosing.
A lot of the v3 clean-up helped us get into a better place where things can be swapped in/out more smoothly on a per-Table basis, rather than the "publish the views" approach, so it's now easier to add functionality to customise on a per-table basis.

There is presently an event listener for "setFilter", which expects two values - $filter and $value, $filter being the "filterKey", and $value being the value of the filter, which will enable you to do exactly what you're after, once the per-table "custom filter menu blade" is introduced.
The "filterKey" is the second parameter in the make() method.

The above will all be documented with the release when it's introduced (which is my least favourite task!)

Also worth noting that a Livewire Component Filter is currently in beta, which lets you do effectively whatever you like in terms of interactivity on a per-filter basis, noting that this is of course subject to change/tweaking prior to becoming Core.
See Here