DocumentationDocumentation
User guide/Frontend development and delivery

Continue development and diagnose problems

Preserve the existing add-on and technology choices, locate the actual fault, and perform the necessary checks.

Continue the same project

Confirm the add-on name, source, framework copy, page entry, and currently loaded location. Keep these for small changes; do not regenerate the add-on, change its identity, or overwrite the template just to restyle it.

With a separate source repository, edit source and update through the existing build/install flow. Do not manually edit source and installed copies simultaneously.

Identify the affected layer

Symptom Check first
Incorrect layout or images Page source, build output, and resource URLs.
No response to clicks Script loading, action names, registration after binding, and original errors.
Reads work but data stays stale Invalidation notifications and component subscriptions.
Header will not drag or controls miss clicks Transparency, hit markers, and drag exclusions.
Changes have no effect Which files Blender loaded, and whether they were synchronized or restarted.

Preserve the first error

Use existing status messages, diagnostics, or logs. Add minimal temporary diagnostics only if needed and remove them afterward. Do not swallow exceptions or build a permanent debug panel for a one-off issue.

If action or state is undefined, check whether whenNexusWebUIReady's result was mistaken for the SDK. Acquire the interface with acquireNexusWebUI.

Follow dependencies through the change

  1. Find existing source and calls instead of copying a second implementation.
  2. Change only what the issue requires. Decide framework upgrades, format migrations, and toolchain changes separately.
  3. Build frontend projects through their existing flow; update real entry references for static pages.
  4. Add new runtime files to the manifest and check references before removing or replacing files.
  5. Recheck the original issue and directly affected behavior. State what real behavior was not tested.

Leave a clear result for the next change

For example: name validation changed; empty or missing names show a reason; page syntax checked; real object reads await your confirmation. This is more maintainable than a vague Everything fixed.

When ready to deliver, see Packaging and delivery; before a framework update, see Updates and coexistence. Upgrading is not a universal troubleshooting method.

Based on the continued-development and debugging guide.

Back to User guide · All topics