Skip to content

surveyJS integration plan

Yes — you should plan to run SurveyJS Creator in its own dedicated page (or even its own micro-app). Given your experience and the complexity of your platform, this is the correct architectural choice , not a workaround.

Below is a clear rationale, followed by recommended patterns that work well in regulated, modular systems like the one you are building.

Executive recommendation

Do not deeply embed SurveyJS Creator inside complex application layouts or multi-purpose React views.

Instead:

  • Run it as a standalone route or micro-frontend
  • Treat it as a specialized design tool, not a reusable widget
  • Integrate with your platform via explicit save/load APIs

This mirrors how REDCap, OpenClinica, OpenEDC, and most commercial EDCs behave in practice—even if not always obvious.

Why embedding SurveyJS Creator is problematic (and keeps biting teams)

Your experience is common, and there are good reasons.

1. SurveyJS Creator is state-heavy and opinionated

SurveyJS Creator:

  • Maintains deep internal state
  • Manages its own undo/redo stack
  • Injects global styles and listeners
  • Assumes control over layout and focus

When embedded inside:

  • complex routing
  • nested modals
  • dynamic layout containers
  • multi-pane dashboards

…you get exactly what you observed:

  • rendering glitches
  • broken focus / keyboard handling
  • unexpected re-renders
  • CSS collisions
  • difficult-to-debug lifecycle bugs

This is not a failure of your architecture; it’s a mismatch of responsibilities.

2. The Creator is a ****

tool

, not a form component

Conceptually:

  • SurveyJS Runner = application component
  • SurveyJS Creator = design environment

Trying to embed Creator alongside:

  • study dashboards
  • participant workflows
  • admin panels

is like embedding:

  • Figma inside Jira
  • VS Code inside a CMS editor

It can be done, but it is rarely worth the cost.

Pattern A — Dedicated full-page route (best default)

Example

/studies/{study_id}/forms/{form_id}/design

Characteristics

  • Full-width, full-height page
  • Minimal surrounding UI (top bar only)
  • No complex layout nesting
  • Creator owns the screen

Integration

  • Load schema via API on mount
  • Save schema explicitly via “Save” / “Release” actions
  • Navigate back to study dashboard on exit

Why this works

  • Clean React lifecycle
  • No CSS or layout conflicts
  • Predictable behavior
  • Easiest to validate and maintain

This is what I recommend for you.

Pattern B — Separate micro-frontend (iframe or sub-app)

Use this if:

  • Your main app is already very complex
  • You want strict isolation
  • You anticipate Creator upgrades independently

Options

  • Separate React app served at /designer
  • Embed via iframe or router-level mount
  • Communicate via:
  • REST API
  • postMessage (only if iframe)

Pros

  • Strong isolation
  • Zero CSS bleed
  • Easier versioning

Cons

  • Slightly more plumbing
  • Cross-context auth/session handling

For regulated systems, this is often worth it.

Avoid:

  • modals
  • split panes
  • tabs
  • collapsible sidebars

Even if it “works today,” it tends to break:

  • after SurveyJS upgrades
  • after React upgrades
  • after layout changes

This pattern has the highest long-term cost.

What ****

does

** integrate well inside your main app**

These components are safe to embed:

  • SurveyJS Runner
  • jsPsych runtime
  • read-only previews
  • summary views of form metadata

Rule of thumb:

If it edits structure → isolate it

If it fills data → embed it

Treat SurveyJS Creator as a ** stateless editor with explicit IO .**

On load

  • GET /forms/{form_version_id}
  • Pass JSON schema into Creator

On save (draft)

  • PUT /forms/{form_version_id}
  • Store schema (new draft version)

On release

  • POST /forms/{form_version_id}/release
  • Freeze version
  • Trigger:
  • QuestionMap generation
  • ODM snapshot
  • jsPsych transpilation (if applicable)

On exit

  • Navigate back to study dashboard
  • No hidden autosave side effects

This explicit lifecycle is excellent for:

  • auditability
  • version control
  • team mental models

Regulatory and auditability bonus

A dedicated Creator page helps you:

  • Clearly separate design-time vs run-time
  • Enforce RBAC cleanly (only designers access it)
  • Log explicit “design events”:
  • opened
  • saved
  • released
  • Avoid accidental edits to released forms

This aligns with how EDCs justify traceability during audits.

What to tell your team (one paragraph)

SurveyJS Creator should run as a dedicated design surface, not embedded inside complex application layouts. It is stateful, opinionated, and behaves more like an IDE than a UI component. A standalone page or micro-frontend dramatically improves stability, maintainability, auditability, and developer velocity. SurveyJS Runner and jsPsych remain embedded in participant workflows; Creator does not.

If you want next steps

I can:

  • Propose a routing and permission model for the designer
  • Sketch a minimal UI shell around Creator that fits your platform
  • Provide a React integration snippet that avoids common lifecycle bugs
  • Help define audit events tied specifically to form design actions

Just tell me which would be most useful.