Modern UI / New Views: Is interactive row filtering between views (IVFW-like) supported without workflow re-execution?

KNIME Extensions
1

Hi KNIME community,
We are developing a custom cascading filter node intended to work with Modern UI “New Views” (e.g., New Table View, Scatter Plot, etc.) in a composite component, similar to how legacy JavaScript views and the Interactive Value Filter Widget (IVFW) enable interactivity.

Environment

  • KNIME Analytics Platform: 5.8.2

  • Modern UI / New Views (composite components)

  • Goal: a custom “cascading filter” that updates other views interactively

1) Goal

We want an IVFW-like experience in Modern UI:

  • When users change a filter (or choose rows) in one view, other connected views update immediately and interactively, ideally on the client-side, without requiring workflow-wide re-execution.

2) Why we are doing this

  • In New Views, linked row selection works (selection is propagated across views).

  • However, we need interactive filtering across New Views (not just selection).

  • We know nodes like Nominal Row Filter Widget may be an option, but in workflows with heavy preprocessing, re-execution of the downstream flow can be expensive. We are looking for a pattern that reduces unnecessary re-execution.

3) Findings from our tests (logs)

  1. Legacy JS views / IVFW style
    We observed that knimeService publishes interactivity topics such as:

    • selection-<tableId> (e.g., selection-root:6:0:4)

    • filter-<tableId> (e.g., filter-root:6:0:4)
      Calling knimeService.setSelectedRows() / setFilteredRows() from the console triggers GS.publish logs (topics are published).

  2. New Views (New Table View) selection path
    When the user clicks a row in the New Table UI, we consistently see RPC calls like:

    • NodeService.updateDataPointSelection

    • params example: [..., "root:6:0:4", "ADD", ["Row1"]]
      This RPC seems to be the path that actually drives UI highlights and cross-view selection propagation.

  3. Mismatch: publishing via knimeService does not update New View UI in our tests
    Even though knimeService.setSelectedRows() / setFilteredRows() publishes events (GS.publish visible), we do not see NodeService.updateDataPointSelection being triggered by that call, and the New Table UI does not visually reflect selection/filter changes (based on our tests).

Questions

  1. Roadmap / product direction
  • Are there any plans (roadmap) to improve Modern UI / New Views so that they can support more front-end-side interactive data handling, similar to legacy JavaScript views (e.g., interactive filtering between views)?
  1. If there is no such plan
  • Is there an official workflow guideline or recommended node pattern to satisfy these requirements (interactive/cascading filtering across views) while minimizing re-execution?
  1. For extension development / customization
  • If we need to implement this ourselves, it looks like we may need work on both PageBuilder and New View based custom nodes.
    Are there any recommended packages/classes/APIs we should study, or any important functions we should pay close attention to (and/or avoid if they are internal/unstable)?

Additional questions that would help us design correctly

  • Is knimeService intended to affect New Views, or is it effectively legacy-only?

  • Is there any supported API to programmatically set:

    • row selection (so that New View UI highlights update), and/or

    • an interactive “row filter” (so the table/chart updates without re-execution)?

  • Are rowKeys guaranteed stable across sorting/filtering/virtualization in New Table View, and is there a recommended way to reference rows for interactivity?

If needed, we can share a minimal reproducible example and more log snippets.
Thanks in advance for any guidance.

2

Hello @jspark123 — thanks a lot for the detailed investigation and for sharing your findings.

With KNIME Analytics Platform 5.8.2 and the current Modern UI / New Views framework, the kind of IVFW-like, front-end-side interactive filtering across views without re-execution that you describe is not possible. Your observations match the current design: knimeService–based interactions belong to the legacy JavaScript view framework and are not expected to affect New Views. New Views use a different, internal interaction path, and the two frameworks do not interact with each other.

Product direction
We do see the value in opening up these capabilities in the Modern UI framework. However, there is currently no supported solution for this, and we can’t share a concrete timeline.

Recommended workflow pattern

  • To limit re-execution, you can branch on selection using a HiLite Row Splitter and re-execute only the minimal downstream part that needs the filtered data, for example via an explicit refresh step. This does require an explicit press of the refresh button after changing the selection.
  • For the New Table View, a filter-like behavior via “show only selected rows” is available.

Extension development
There is currently no public front-end API for programmatically setting selection or interactive row filtering in New Views. The corresponding mechanisms are internal and not intended for external use.

Row identification
RowIDs (row keys) are stable and are also the internal mechanism used to reference selected rows.

Hope this helps — and let us know if there are any follow-up questions you’d like to discuss.
Best regards,
Robin

3 Likes