Modern UI / New Views: Is interactive row filtering between views (IVFW-like) supported without w...

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

)

1.

filter-<tableId>

(e.g., 

filter-root:6:0:4

)

Calling 

knimeService.setSelectedRows()

/ 

setFilteredRows()

from the console triggers 

GS.publish

logs (topics are published).

1.

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

1.

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.

1.

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.