Reflect filters in custom widget

[yohanboniface]

Hi,

Playing again with custom widget (the map), I wonder if there is a way to reflect data selection in the map: when I filter data in the related table, I'd like to display only those filtered rows in the map. I've tried to play around with onRecords, but it does not seem to be the way to go. Any hint ?

Thanks! :)

Yohan

PS: I've made a (quite hard) fork of the map widget to make it more Cocorico-Frenchy, but while doing so I'm also doing some logic change (eg. popup management and map initialization (to prevent the map to blink on each data change)) that I'm planning to propose in some PRs later :)

[vviers]

@dsagal @paulfitz this issue came up again today, any lead on the topic ?

cc @fflorent @CamilleLegeron

[wunter8]

The custom widget has its own set of filters, so if you add filters to the related table and put the same filters on the custom widget, they should be showing the same data.

[yohanboniface]

The need is a bit different I think: the use case we have in mind is a page with a table and a map, when the user filter the data on the table, this will update the data shown on the map accordingly.

[wunter8]

I know it's not ideal, and I agree that the records sent to the custom widget should probably be filtered based on what's visible in the related table, but as a workaround (until the onRecords API is updated), setting the filters in both places should work. Have you tried it?

[vviers]

Hi @wunter8 ! Thanks for you answer :)

I have just tried your workaround and it doesn't really do what I want here. Here what I did :

• created a filter on Département (french regions) on both the table widget and the custom widget
• filtered on a specific Département in the table widget
• the custom (map) widget does not reflect the filtered data shown in the table widget (see screenshot)

As for updating the onRecords API, would you be interested in us opening a PR ? or is it on your roadmap ?

Cheers :)

[wunter8]

You're very close, @vviers. You need to add a filter to the table widget and the custom widget (like you did). But the workaround is to filter on a specific Département in the table widget AND filter on the same specific Département in the custom widget.

Ideally, after updating the API, filtering on the table widget alone will be enough.

I can't speak to the PR or the roadmap. I'm just a fellow user that ran into the same issue when I was working on my calendar custom widget

[paulfitz]

I've pasted below some notes from a related feature proposal we have lying around in our backlog, that seems relevant to this thread. Now that I'm reading it again, I wonder if it wouldn't make more sense to offer filtered, sorted sets of rows as a extra source for linking. @jvorob has been looking into a "grand unified theory" of linking recently, maybe she has ideas.

With Grist today, I don't know of a satisfying solution. @wunter8's suggestion can help some. For custom widgets, it is also possible to make a set of rows available for linking https://support.getgrist.com/code/modules/grist_plugin_api/#setselectedrows so it might be possible to modify a map or calendar widget to be the "main" widget that gets filtered, and let it drive other widgets. Not sure how comfortable the result would be.

Proposal: “Inherited” filters

Allow a widget to use another widget’s filters.

• For a linked widget, show a new option in sort-and-filter: [ ] inherit linked filters
• If checked, then effective filters in that widget are:
  • any compatible effective filters on source
  • with any added filters on widget itself
• if conflicting, filters on widget itself take precedence
• In UI, inherited filters are shown in a distinct, read-only way, with a way to override
• Initially only offer option when linking source and target are same table

Possible design

• The option to turn on inherited filters is in the Sort & Filter menu.
• Once on, all linked filters are represented as a single special filter-button: it has a “Link” icon, lists all fields being filtered as a comma-separated list (with some max-width and truncation), and a lighter disabled-looking color.
• It may be pinned or unpinned, which determines, as usual, whether it is shown above the widget in addition to the Sort & Filter dropdown menu.
• It has no behavior on click, is purely informational.

Scope

• UX design work - moderate
  • UI for activation of feature
  • Filter appearance and operation in new combinations
• Dev work - changes to web client - moderate to hard (kind of work that can hit unexpected snags)
  • Propagating/pulling changes to filters to/from target/source widgets
  • Nested inheritance
  • Summary table nuances? (could exclude from scope)
  • Referenced table nuances? (could exclude from scope)
• Small addition to filter state - easy

[wunter8]

I had the same thought about adding an "inherit filters" feature. I think that would be very handy, especially for situations like this

[vviers]

paging our in-house Custom Widgets extraordinaire @CamilleLegeron and moving this ticket into our backlog