I’d like to build an extra filtering panel to provide some extra filter capabilities that Grist does not currently offer.
Among other things, this panel would apply to all views of the page. It would also offer range filtering for number and date columns. Would support vertical layout, allowing to position the panel on the left of the screen for instance.
I’m investigating how to build this using custom widget.
At a first glance what I need is listed here:
a) fetch all tables of the current page.
b) get the list of widget of the current page.
c) set the list of the row ids to show for a widget.
d) a way to save custom widget configuration.
(a) and (b) are in principle possible for a custom widget granted full access. It can call grist.docApi.fetchTable('tableId') with tableIds like _grist_Tables and others listed in grist-core/schema.ts at main · gristlabs/grist-core · GitHub, to navigate the structure of the document. Not easy, but possible. The missing piece of information is to actually let the widget know which is the current page. You might be able to pick a rule that works for your use-case, and we can look at adding this information.
The biggest missing thing is (c). Thinking about that a bit more.
@cpind for (c) would it suffice to have a method that could add/update a filter on a view, without being able to control row ids directly? E.g. create a filter for a field, add/remove options from the filter, with filter being in an unsaved state?
I am not as knowledgeable as you gentlemen, but I had a thought that might also work.
An option to set the filtering status of any table to be “child” to another table that uses the same data.
Then, the “Filtering Panel” custom widget could control the “parent table” data and the remaining widgets display only the records surfaced in the “parent table”.
Again, I don’t really know the underlying mechanics, but I wanted to see if this is helpful at all.
@cpind I guess I’d say yes to all? It isn’t really a plan, just trying to figure out at least one possible path that gets you to your goal. This may not be a very pretty path
One thing to have in mind when designing features with Grist is what stays on the client side and what happens at the document level.
For instance editing a cell value happens at the document level, it means that all user that have access to the document will see the modification live.
On the contrary filtering stays on the client side, so that multiple user can have different filters at the same time. Only when one user decide to save its filter (clicking the save filter button), then it becomes the default filter for all user. This is why we destiguish between save and unsaved filtering state.
With that in mind, the problem with you proposal is that it changes the document itself, hence does not let multiple users to have different filters at the same time.