Plotly.js to Dash migration boundary: can dcc.Graph and client-side charts coexist during a zero-downtime cutover?

Answer to the core question

Yes, dcc.Graph and client‑side Plotly.js can coexist during a zero‑downtime cutover, provided you:

1. Route each request through a feature flag that selects either the legacy JavaScript bundle or the Dash component.
2. Guarantee that the Plotly.js version in the legacy bundle matches the one bundled with Plotly.py/Dash.
3. Synchronize any mutable chart state (zoom, hover, selection) between the browser and the Dash callbacks.
4. Use a shared figure JSON schema so the same data can be fed to both paths.

Why this works

Both rendering engines ultimately consume a Plotly figure JSON. The Dash dcc.Graph component is a thin wrapper that injects the same Plotly.js library into the browser, so if the figure and library versions match, the visual output is identical. Feature flags allow you to serve one path to a subset of users while the rest continue on the legacy path, giving you a controlled, incremental rollout.

State‑consistency risk

Client‑side interactions that modify chart state (e.g., zooming, clicking a legend item) are normally handled entirely in the browser. In Dash, those interactions must be captured by a callback (e.g., relayoutData, clickData) and sent back to the server. If the legacy path updates the chart without reflecting those changes server‑side, the two views will diverge, confusing users and breaking metrics. The safest approach is to replicate the exact state changes on the server for any path that will eventually use Dash callbacks.

Interactions that map cleanly

• Click, hover, and relayout events have direct callback equivalents.
• Zoom, pan, and legend toggle are all available via relayoutData and hoverData.

Interactions that need redesign

• Custom context menus or multi‑trace selection logic that rely on bespoke JavaScript may need a client‑side callback or a re‑implementation in pure Dash.
• Advanced animation or dynamic data loading that uses Plotly.js’ restyle or relayout APIs may require a custom Dash component or a hybrid approach.

Version‑compatibility gate

Dash bundles plotly.js via the plotly.py dependency. The plotly.js version shipped with Dash is pinned to the plotly.py release. Verify that:

• The legacy bundle’s plotly.js Plotly.version string matches the one in plotly.py (e.g., 5.22.0).
• Any custom Plotly.js plugins or extensions are also present in the Dash bundle or re‑implemented as Dash client‑side callbacks.

Practical rollout steps

1. Feature‑flag setup: Add a boolean flag (e.g., USE_DASH) to the request context. Route the HTML template to include either the legacy plotly.js script or the Dash dcc.Graph component.
2. Shared figure generator: Refactor the Python code that builds the figure dictionary so it can be serialized to JSON for the legacy path and passed directly to dcc.Graph for Dash. Keep the schema identical.
3. State bridge: For any interactive feature that will eventually live in Dash, capture the relevant state in the legacy JavaScript (e.g., Plotly.relayout events) and send it to the server via an AJAX endpoint. Update the Dash callbacks to read that state instead of relying on the browser.
4. Regression test harness: Render the same figure with both paths in a headless browser, capture the DOM snapshot, and assert equality. Also trigger click/hover/zoom events and verify that the server receives the expected data payload.
5. Incremental user exposure: Enable the Dash path for a small percentage of users, monitor error rates, and compare interaction metrics. Once confidence is high, increase the flag rollout to all users.

Missing diagnostic detail

To finalize the compatibility gate, we need the exact plotly.js version currently used in the legacy application. Please provide that version string so we can verify it against the plotly.py release bundled with Dash.