I am curious about what the best approach would be for dynamic, user configured filters. Here is a simplified scenario:
I have repeating items - let’s say it’s email threads in an email inbox.
User can create “custom filters” - these have a name and appear as TABS above the repeating items - when you click on the tab - that specific filter is active and the repeating email threads are sorted based on the custom filter configuration for that tab - as defined by user.
Example - User creates a custom filter that will include all emails from a specific domain - he names that filter (name will be displayed on a tab)
In a perfect world - I could programmatically build a “FILTER” which I assume is most likely a JSON object?? - and bind a tab to a FILTER - and then bind the repeating items list to the “dynamic filter” (whatever is selected by the tab) - which would be a variable (containing that JSON filter object).
Is this conceivable? Or is there a different approach already avaiable I am not thinking of …
I will file a feature request for “Make Filters bindable” - because if WeWeb made filters bindable and just provided the “expected format” - which is most likely some json/object schema - this would actually be … EASY
Pretty sure that won’t work with the limitations of (conditions - apply if). I’ll hack at it a bit to verify - but I don’t really see how it would work without making the actual FILTER bindable.
If the filter is not bindable - you would have to have every possible filter group scenario built with a (conditions - apply if) - and I don’t see it working even with a basic example like this:
User makes a custom filter for the tab - that only shows emails from 4 specific email addresses they have defined. Now I would have to have a filter group - with 4 conditions - each one bound an email address. And another user wants a filter with 7 specific email addresses, etc - so … without a way to programmatically create a filter group … I just don’t see a way to do this without MAKE FILTERS BINDABLE - and provide us an “expected format” for the filter.
What you could do (on the front-end) is to make a formula that will take your object/array of filters and filter the data, you could use Copilot and ChatGPT for this.
As for backend filtering, your best bet is either
Using the SDK (if you’re using Supabase) and building your filters client side
Building an endpoint/function that will take the parameters and filter upon them
For both I don’t think WeWeb should cover this much of a “corner case” scenario, even though the filters could use an overhaul definitely.
I’d take a “hard disagree” on this being a “corner case” scenario - I can think of a tons of uses for BINDABLE FILTERS.
Having dynamic flexibility to manipulate data client side after a ton of data is called from the back end - (many times you will want “all that data” to be client side so that it can be filtered and displayed in different ways vs. specific backend filtered calls) - is an obvious hero feature of a nocode/low-code front end editor IMO.
Further - I know team WeWeb is starting to dev a new, improved data table - and custom/user defined dynamic filtering is kinda a core requirement for any serious data table - so maybe there is a little dev overlap opportunity here …
@luka In my specific context - I need to allow the user the ability to CREATE their own filters (based on a limited amount of specific parameters) and then assign that filter to a tab (and this newly filtered data can be used for repeating elements).
Because the tabs are basically just showing different filtered versions from same master data - it does not make sense to make API calls to back the end and retrieve filtered redundant data,
I think that if you can make FILTERS bindable - based on some schema / expected data format - this would open a lot of doors for dashboards, etc - to be faster than making more filtered backend calls. Also, for a more robust DATA TABLE - you will want this for sure.
Of course I filter on back end as much as possible - but there are many applications (like email) where you want “all the data” in the front end - and robust ability to dynamically filter.
