# Script Manager ✅

{% hint style="success" %}
**EXPERIMENTAL** \
Based on an idea by [**Patrick Corsetti**](https://x.com/corsettiDev).&#x20;
{% endhint %}

<figure><img src="/files/T0eNSyveies9sH3UkXTf" alt=""><figcaption></figcaption></figure>

In general when you're injecting a code library into your Webflow site, it's best to directly include the script tag in your page \<head>, pointing to the CDN-served code for your site.&#x20;

This makes is much easier to manage your code safely in Github, edit it more efficiently through VSCode, and setup efficient CI/CD workflows for your team.&#x20;

**But how do you test code with your Webflow site?**&#x20;

Traditionally my preference is to maintain separate URLs for DEV ( on localhost ), TEST & PROD ( on CDNs ), and then to swap them depending on what configuration I need to test. However to do this efficiently, you need a reverse proxy to manage your development mode and modify those scripts. &#x20;

> Developer Patrick Corsetti had the idea of using Webflow Code Components for this, and it lead to this experiment.&#x20;

## Features&#x20;

* Dynamic script loading, based on your environment. &#x20;
* By default, automatically inject the correct script;&#x20;
  * Inject the TEST script if you're on staging
  * Inject the PROD script if you're on production
  * Inject the DEV script if you're in dev mode ( defined by a cookie )&#x20;
* Allow devs to easy override the default mode for testing on the site;&#x20;
  * Append `?dev` to the URL to switch to DEV mode
  * Append `?test` to switch to TEST mode&#x20;
  * Append `?prod` to switch to PROD mode&#x20;
* When you're in an override mode, see that easily ( bottom right indicator )&#x20;
* Click the indicator to exit that override mode and restore default script loading behavior&#x20;

{% hint style="danger" %}
**IMPORTANT** \
Using the code component approach, the script is injected at some point during page load.  Unlike a manual tag placement, it's difficult to control the exact point at which the script will load.&#x20;

If your scripts use the DOMContentLoaded trigger, it's best to verify that the event has not already fired, using a pattern something like this;&#x20;

```javascript
(() => {
  function apply() { 
    // Your code here 
  }
  
  // Loader
  if (document.readyState === 'loading') {
    document.addEventListener('DOMContentLoaded', apply, { once: true });
  } else {
    apply();
  }
})(); 
```

{% endhint %}

## Demonstration

{% embed url="<https://script-manager.webflow.io/?prod>" %}

In this demonstration we have one Script Manager component, which has defined three separate CDN URLs.  For demo purposes, all 3 are coming from CodePen;&#x20;

* DEV - <https://codepen.io/memetican/pen/ByjQPpW/952435b2cc519b0377a667a0c3204086.js>
* TEST - <https://codepen.io/memetican/pen/ogbYMbr/1429d3082c70ee20374640c92b2f6bb9.js>&#x20;
* PROD - [https://codepen.io/memetican/pen/pvgNZEa/9af32f97a8e11f86c29cdba239f991c8.js ](<https://codepen.io/memetican/pen/pvgNZEa/9af32f97a8e11f86c29cdba239f991c8.js >)

{% hint style="success" %}
Typically, you'd use JSDeliver, npm, or Netlify to act as the CDN for your TEST and PROD branches.  For DEV, you'd most likely use localhost.&#x20;
{% endhint %}

## Properties

Use these properties to configure Script Manager.&#x20;

<table><thead><tr><th width="177.66668701171875">Property</th><th width="161.6666259765625">Type </th><th>Description </th></tr></thead><tbody><tr><td>Dev Code URL</td><td>url</td><td>Specify the URL to your DEV mode code, typically using localhost. </td></tr><tr><td>Test Code URL</td><td>url</td><td>The URL to your TEST mode code, typically a CDN served integration branch from your Github repo. </td></tr><tr><td>Prod Code URL</td><td>url</td><td>The URL to your PROD mode code, typically a CDN served from your Github release branch. </td></tr><tr><td>Async</td><td>boolean</td><td>Optional async</td></tr><tr><td>Defer</td><td>boolean</td><td>Optional defer</td></tr></tbody></table>

## Notes&#x20;

Sygnal has a more industrial-strength approach to this solution, which we call DevProxy. It requires a reverse proxy to manage the script loading, and support dedicated, password-protected environments like `test.mysite.com`  &#x20;

See the **Sygnal Site Engine** framework for more - <https://engine.sygnal.com/>&#x20;

## Future&#x20;

* Consider designer suppression- it's executing PROD mode code&#x20;
* Handle partial-configs, where some URLs are unspecified&#x20;
* Support multiple Script Manager components, with independently-tracked states&#x20;
  * Name each component individually, e.g. `engine` , `sa5-layout`&#x20;
  * Allow DEV mode to selectively use DEV-mode scripts,&#x20;
    * e.g. `?dev=engine,sa5-layout`&#x20;
    * e.g. `?dev`  same as `?dev=*`&#x20;
    * e.g. `?dev=engine` &#x20;
  * Same for `?test` and `?prod`&#x20;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://sygnal.gitbook.io/sygnal-webflow-components/cc/sygnal-components/script-manager.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
