Spike: Resolve per-type graph styling off both selectors and element data

[kmcginnes]

Goal

Validate an architecture that resolves per-type vertex/edge styling neither through per-type Cytoscape selectors nor through per-element data() — so the canvas can be O(1) in style-context count (the #2104 win) and free of per-element display state (the #1887 reconciler's requirement), while making restyles explicit and cheap. This must be settled before the reconciler or further style work commits to an implementation, because #2104 (landed) and #1887 (planned) currently hold contradictory models of what an element carries.

Background / why now

• Schema view lockup from per-type Cytoscape style selectors in useGraphStyles #2104 fixed the schema-view lockup by replacing ~20k per-type selectors (node[type="X"]) with a single node/edge rule reading precomputed ge_* values off ele.data(). Style-context count O(elements × selectors) → O(1); Cytoscape STYLE self-time ~88% → ~0% at 10k types. It is a deliberate stepping stone, not the durable end state.
• It introduced two downsides:
  1. Data duplication — every element carries ~13 ge_* fields whose values are per-type yet copied per-element; the current cy.json(cloneDeep(...)) full-replace copies them all on every change.
  2. Implicit reactivity — a style edit reaches the canvas only because the element-build hooks re-read style atoms and rebuild the element array; there is no explicit style→canvas channel.
• Reconcile the graph canvas — stop rebuilding on every change #1887 (reconciler) is on a collision course: its founding decision is "elements carry structural identity only; display resolves at paint time, never baked in." ge_*-on-elements reintroduces exactly the baked-in display state that defeats reference diffing — a color edit changes every element's ge_* → new references → the reconciler sees "everything changed." Reconcile the graph canvas — stop rebuilding on every change #1887's body also still assumes node[type="X"] selector-driven styles (pre-Schema view lockup from per-type Cytoscape style selectors in useGraphStyles #2104).

The three-way constraint

A durable answer must satisfy all three at once:

1. O(1) style-context count regardless of type count (Schema view lockup from per-type Cytoscape style selectors in useGraphStyles #2104).
2. No per-element display/style state so element references stay stable across restyles (Reconcile the graph canvas — stop rebuilding on every change #1887).
3. Explicit, cheap restyle — a Type style edit updates the canvas without rebuilding elements (Reconcile the graph canvas — stop rebuilding on every change #1887 user story; Push node background-color to Cytoscape ele.data() with styled type atoms #1725).

Cytoscape natively offers only per-type selectors (fails #1) or per-element data (fails #2). The spike finds and validates the escape.

Hypothesis to validate (the "unifying bet")

Combine three moves so styling stops being smuggled through the element pipeline:

1. Class-based dedup — each element carries one stable style-class keyed on its distinct resolved style (not its type). Stylesheet has one rule per distinct style (usually ≪ types; a uniform schema collapses to one rule). Element data shrinks to ~1 class ref. Degrades to O(types) only in the pathological "every type uniquely styled" case — the same worst case as selectors, so no regression.
2. Style-registry bridge — an external store (mirroring the existing iconRegistry + useSyncExternalStore pattern) owns type→style; a thin bridge patches the stylesheet / ele.data() imperatively on change, outside React render, decoupled from element identity.
3. Incremental element updates — ride on the Reconcile the graph canvas — stop rebuilding on every change #1887 reconciler (kill cloneDeep full-replace) so element data is diffed/patched, not rebuilt + cloned.

Result: element data ≈ 1 class ref; style values live once per distinct style; restyle = patch one rule / the registry, no element rebuild. Both downsides dissolve.

Open questions the spike must answer

• Function-mapper vs class vs data(): a Cytoscape style function mapper (ele => typeStyleMap.get(ele.data('type'))) gives O(1) selectors + a shared type→style map + no per-element style data — and Reconcile the graph canvas — stop rebuilding on every change #1887 already proposes exactly this for edge labels. Why did Push node background-color to Cytoscape ele.data() with styled type atoms #1725 deliberately choose data() string mappers over function mappers? Resolve this (function-mapper caching / perf cost?) — it decides between the function-mapper and class approaches.
• Class-membership churn: when a type's style changes bucket, element class assignments must update — measure that this stays cheap (or that the registry / data-patch path handles it).
• Composition with the reconciler: how the style channel interleaves with Reconcile the graph canvas — stop rebuilding on every change #1887's diff/apply batch without double-work or ordering hazards.
• Scale: holds at 10k types / 68k edges, and 70k (Support graphs with very large numbers of node types (70k+) #1677)? Benchmark restyle latency, memory, and reference-stability under a Type color edit.

Expected Outcome

• A recommendation (function-mapper vs class-based; whether a registry bridge is warranted) backed by a throwaway prototype measuring style-context count, restyle latency, element-data memory, and reference stability under a Vertex-Type color edit at 10k+.
• An updated implementation plan feeding Reconcile the graph canvas — stop rebuilding on every change #1887 and the styling work, replacing Reconcile the graph canvas — stop rebuilding on every change #1887's stale "selector-driven styles" assumption.
• Confirmation the approach composes with the reconciler.

Out of Scope

• Building the reconciler engine (Reconcile the graph canvas — stop rebuilding on every change #1887) or the final styling implementation — this spike unblocks them.
• Layout performance (fcose at scale) — the next wall, tracked separately.

Related Issues

• Originated from Schema view lockup from per-type Cytoscape style selectors in useGraphStyles #2104 (the landed stepping stone and its two downsides)
• Gates / blocks Reconcile the graph canvas — stop rebuilding on every change #1887 (reconciler must not commit to a styling model until this resolves)
• Supersedes the open question in Push node background-color to Cytoscape ele.data() with styled type atoms #1725 (Schema view lockup from per-type Cytoscape style selectors in useGraphStyles #2104 did the full data() conversion)
• Related to Spike: Redesign Cytoscape abstraction layer for performance and simplicity #1797 (broader Cytoscape redesign spike) and Initiative: Make the Cytoscape abstraction a deep, performant module #1891 (parent initiative)
• Part of Scale gracefully to very large label sets #2091

Important

Internal only — this issue is maintained by the core team and is not accepting external contributions.