Watching some threads and good Robert Petittoās videos about creating customized filters using an Inline List component, I thought an idea to make it simpler and avoid configuring manually the Inline Listās filter and suddenly, I got this to share :
The trick is to work with a multiple relation base on values (filters) selected by user which will rule your Inline List data and as you can see, you donāt need to configure/create internal filters later.
I like what youāve done with the template/split text combination.
Although Iāve been creating these types of dynamic relations for quite some time, itās always been a combination of template + if-then-else. The split text approach never occurred to me, but having seen what you did here I think itās a better (cleaner) approach. Nice work
Glad to see my solution gives new ideas to other situations.
Another advantage with it is that you can have quickly the amount of records the filters bring back due to it is working with a relation. Any Rollup pointing to this relation will give you the amount.
I think @kyleheney was looking for something like it weeks ago.
My original idea was to create a kind of āSQL Queryā inside Glide although the big troubles came from playing/working with parameters using an OR operator and AND operator at the same time (a hard challenge sometimes in GDE).
In the end, a Filter is almost a SQL Query when you try to narrow your useful data.
When I ended this idea, I evaluated if this had been a good solution ( a clever idea) or on the contrary, it might create more load/work for Glide (unnecessarily) due to use of template columns changing dynamically along with relations based on them.
To sum up: the endless dilemma between Efficiency vs. Effectiveness when our APP is using this method with a large amount of data: 15k or 20k+ rows
I donāt know at the end whether the best option is to load all data once and let Glide filter and discard values/rows automatically or create/use a dynamic relation to get a specific result always (my idea). Which process is better for Glide? ā¦ I donāt know yet
I read @Darren_Murphy and @Jeff_Hager discuss about this issue here and I agree with some points but I think the friends @Mark or @Jason can give us the final answer to have the best performance on our APPs always.
In my experience, filtering any list (whether by condition>relation>inline list OR inline list>condition>filter) is considerably laggy when that condition is built off of an earlier rollup of a datetime.
For example:
Log of categories and dates > relation to self of log categories > rollup of earliest date > if rollup is date then true >filter inline list where if = true.
Question is, in this instance you only have one row with compute columns and then the relation is built on top of them -
Perhaps as it is a single row it uses significantly less resources than if it were lots of rows -
In which case the conventional way of looking at it doesnāt apply.
Also wondering whether lots of users using a user specific column then having compute columns like template on top of them (and then a relation) -
How many users Glide can handle
To me, itās the best way to do this kind of operations and avoid affecting other columns/tables by accident. I just try to use/put a relation where there is no much data (or few columns) involved or associated to that relation and āhelpā Glide a bit during the table updating.
The assumption is very sound,
The question is whether itās true, especially with multiple compute columns.
But since itās only a single row with user specific compute - and it doesnāt compute the bulk of the data - only this row and pulling the relation columns accordingly - perhaps it can handle much much more -
I was thinking maybe start using this method always.
Instead of having users entering actual screens, just go virtual, like this method.
For instance I Have projects, in this project I have multiple related Tables; āOpeningsā, āTypesā, āRecordsā
Instead of Going into a detail screen of the project and pulling up the related Inline lists, I would just have a virtual screen which pulls up the inline lists -
Therefore I wonāt have to build Template/compute columns and relations directly within these Tables which are rather large
Thanks so much for this ātutorialā to solve an important challenge!
For my own records, to save time next time I want to create multi-filters like these, Iāve created this short step-by-step document on creating āANDā multi-filters using your method.
I share it here in case it may be useful to others:
Hi @gvalero - this video is incredibly helpful and exactly what I hope to create! Iām very new to glide - we have an app ready to go, but havenāt dared touch this filter process because itās extremely intimidating. Iām not sure where to start? We have all of our product data in a google sheet with the different filter values in columnsā¦ Would you be willing to point me in the right direction for a first step to accomplishing this? THANK YOU so much!
Hola @SLP_Nerdcast , Iām glad to see that my idea is still useful to many people.
I was going to tell you that you can copy my APP demo and check how it was created but Iām noticing that some component or some improvement/change made by Glide broke something and I need to verify and fix it.
But in the meantime, the friend @NunoDel wrote a good step-by-step document to understand my procedure. To be honest, Iām going to use it to remind myself of all the things I did months ago on that APP, thanks Nuno!
The current caveat with this technique is the number of edits consumed. If you use it in an APP with many signed in users, your edits will affect your paid plan and quota (it can be worse than a Pac-Man). Instead, if your users are Visitors, there is no problem about it.
Your plan B is to use Glideās native filters. When I created this APP demo, Glideās pricing policies were different (there were no edit charges) and advanced filters didnāt exist but currently, the situation is better if you want to use their native filters.
:
