Migrating Workflow Edit to React

Proposed Approach

1. Single React Root
   • We will maintain one global React (or similar root component) that is initialized at page load.
   • This will host a shared store (e.g., Zustand or Redux), ensuring all embedded React components can access the same global state and context providers.
2. Use React Portals for Incremental Embedding
   • For each LiveView-rendered container or “sub-view” we want to replace, we will add a small Phoenix LiveView Hook that notifies our React root once the container is mounted.
   • The root will dynamically create a portal into that container, rendering the React component (e.g., “InputTab” or “Inspector”) inside the LiveView-generated DOM.
3. Gradual Migration
   • We will handle each subcomponent (or tab) one at a time to reduce risk.
   • The simplest components (like the “Input Tab”) will be migrated first, verifying our portal approach works smoothly.
   • More complex areas, such as the Inspector and multi-user code editing, will come later and build on this pattern.
4. Maintain Real-Time Features
   • Where we currently use LiveView event handlers, we will transition to dedicated Phoenix channels or minimal LiveView stubs to broadcast real-time updates.
   • Our React components will consume those events (and handle concurrency or presence as needed), while LiveView focuses on general page layout and server-driven updates that we don't need to replace.
5. Long-Term Vision
   • Once we complete the incremental migration, the main UI for editing workflows will be React-based, with LiveView primarily for top-level page rendering.
   • This architecture also positions us to adopt collaborative editing libraries and use some of the many React libraries out there for a better UX.

Outcome / Success Criteria

• Consistent React UI: Each migrated sub-view fully rendered and controlled by React.
• Shared State: Components share a single store (or set of stores) for data. We avoid duplicating logic between client and server for form handling/validation.
• Reduced LiveView Complexity: Less “bridge code,” fewer LiveView event handlers for pure UI updates. LiveView remains for initial rendering and limited server-driven events.
• Maintain or Improve Performance: The portal approach must be responsive and must not introduce significant overhead or degraded user experience.
• Position for Collaboration: Our approach should be compatible with future CRDT or yjs integration.

Sub-issues

• Input Tab
  • Replace the LiveView-based form for creating/selecting input dataclips with a React component.
  • Integrate JSON validation and any future Monaco editor enhancements.
• Run Pane
  • Migrate the Run Pane (tabs, step list, log viewer integration) to React.
  • Retain real-time log streaming via a Phoenix channel.
• AI Assistant
  • Convert the LiveView AI chat tab to React, including session management and message rendering.
  • Potentially refactor Apollo calls to be handled directly in React or via a channel.
• Editor Shell
  • Rebuild the “3-pane” Job Editor layout (Input, Editor, Run) as a React-managed layout.
  • Ensure Monaco editor, docs, metadata, etc. all integrate with the same store.
• Node Inspector
  • Create a React-based Inspector for Triggers, Jobs, and Edges, moving the form logic and validations to the client.
  • Provide a path for concurrency checks or CRDT integration.

👋 AI Disclaimer, this has been adjusted and proof-read - but portions of the above were assembled using AI.