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

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.