Skip to main content

Dynamic Script Loading

The loader is the bridge between Planon and the centralized library.

Its job is not to contain business logic. Its job is to answer:

  1. What Planon context is active?
  2. Which shared scripts are required?
  3. Which form-specific script should be loaded?

Runtime flow​

Planon page opens
      │
      ▼
loader.js starts
      │
      ├── load shared/functions.js
      ├── load shared/timing.js
      │
      └── detect active form
               │
               ▼
        load forms/FORM_001.js

Simplified public example​

const formCode = getActiveFormCode();

loadScript("/shared/functions.js");
loadScript("/shared/timing.js");
loadScript(`/forms/${formCode}.js`);

The real implementation used the active Planon context to resolve which module should run.

Why this architecture helped​

Without the loader:

each form
  ↓
embeds more logic
  ↓
more duplication
  ↓
harder updates

With the loader:

Planon form
   ↓
small loader
   ↓
central shared modules
   +
one form-specific module

This created a clean separation between runtime selection and business behavior.

Central delivery​

Because the loader points forms toward centrally managed JavaScript, updates can be delivered through the Azure pipeline instead of manually embedding the complete implementation into every form.