Skip to main content
The Web IDE is the primary browser authoring surface for RevoEngine Components. It combines a Component tree, element-level files, Monaco language tooling, multiple tabs, split editing, code search, a debugger, change review, and controlled deployment.

Understand the workspace

Opening /editor/:id focuses a specific Component while keeping the complete workspace available.

Runtime-aware types

The editor loads declarations for the current runtime and active library manifest. Completion covers:
  • low-code globals: api, util, storage, and agent, plus active libraries under lib.Category.Name.ElementKey.X;
  • current @revoengine/sdk contracts used by custom Node.js;
  • active instance library namespaces;
  • definitions and references across loaded Component workspaces.
Library calls use the generated namespace:
Declaration hashes let the editor replace stale models after a runtime or library change. If completion disagrees with deployed behavior, reload the Component and verify its active version and current declarations before changing source.

Create or edit a Component

  1. Expand a category in the navigation tree.
  2. Use Add component or open an existing Component.
  3. Add, rename, reorder, hide, delete, or restore elements from their action menus.
  4. Edit code in one or more tabs; pin important tabs or move one to the split pane.
  5. Resolve Monaco diagnostics and inspect definitions for every library call.
  6. Run the selected Component in the integrated debugger.
  7. Select Deploy, review diffs, choose the intended elements, and confirm.
Changes remain local to the Web IDE workspace until deployed. Production builds warn before leaving the page with unsaved changes.

Search code

The editor search is separate from workspace discovery. It searches executable Component content and can narrow by Component type, case sensitivity, and whole-word matching. Open a result to load the exact Component element in the editor. Use global workspace search to find a named resource; use editor search to find source references or implementation text.

Debug before deploy

The debugger accepts JSON input and exposes timeout, memory, production mode, streaming, and dirty-library override settings. By default, it streams structured logs and a terminal result while preserving a local debug history.
Enable dirty-library overrides when the Component should execute against unsaved library changes already present in the Web IDE. Disable them to reproduce the currently deployed dependency set.
Debug is not automatically side-effect free. Use test identities, test data, and idempotency keys. Production mode changes runtime behavior and should be enabled only for a deliberate production-context test.
The debugger’s timeout and memory are interactive test limits, not a change to a Job or Endpoint configuration. See Limits and quotas.

Review and deploy

Selecting Deploy opens a change review rather than saving every open tab blindly. The review groups changes by category and Component, lets you select visible items, and renders the original/modified diff for one element at a time. Before confirming:
  • verify every selected Component and element;
  • remove accidental whitespace or generated changes;
  • confirm renamed or deleted elements have no active consumers;
  • check library namespace and version implications;
  • run representative input through the debugger;
  • note the resulting Component version for rollout evidence.
Deployment requires Component administrative capability. Authoring and viewing are governed by the Component role family; runtime calls additionally use the execution principal and resource ACLs.

Concurrent changes

The Web IDE listens for Component lifecycle updates. When another operator creates, edits, deploys, deletes, or restores a Component, the workspace reconciles the incoming version. If the same item has local changes, the UI presents a merge or conflict decision rather than silently replacing the draft. Reloading without review can discard local work. When a conflict appears, compare the incoming deployed version with the local element, keep only intentional changes, and re-debug before deployment.

Assistant context actions

From Monaco or a diff, send the selected text, symbol, file, or workspace reference to the Assistant. Context includes the resource identity and file location so the Assistant can load the correct Component rather than infer it from pasted text. Always review Assistant-proposed edits in the same diff and debugger flow as human-authored changes.
The Component deployment is only one boundary. If an Endpoint or Job pins an older version, activating a new Component version does not necessarily move that consumer.

Troubleshooting

Confirm the library is active for the instance and use lib.Category.Name.ElementKey.X. Reload declarations after activation or version changes.
Compare production mode, execution principal, dirty-library overrides, input, timeout, memory, and the Component version selected by the Endpoint or Job.
Use the merge/diff flow. Do not overwrite until you identify which deployed elements changed and replay your test against the merged source.
Confirm that the workspace has deployable changes and that your account has the required Component administrative role.

Production checklist

  • Keep changes focused and review each selected element.
  • Use diagnostics and definition navigation before runtime testing.
  • Debug with realistic but safe input.
  • Verify dirty and deployed library behavior separately when relevant.
  • Record the deployed Component version.
  • Test the real Endpoint or Job with its actual principal and limits.
  • Inspect Trace after consequential releases.
Prefer local authoring? The VS Code extension and CLI use the same platform contracts.
Last modified on September 5, 2026