# CDN: Chunk Loading & Troubleshooting

When using the Myop SDK via CDN (`<script src="https://cdn.myop.dev/sdk/next/myop_sdk.min.js">`), the SDK uses a modular chunk-loading system internally called `__federation__`. This page explains how it works and how to troubleshoot issues when chunks fail to load.

## How CDN Chunk Loading Works

The CDN SDK is split into multiple chunks for performance — only the modules your page actually uses are loaded:

| Chunk | Description |
|-------|-------------|
| `myop_sdk.min.js` | Root entry — lightweight bootstrap |
| `_HostSDK.*.min.js` | Host SDK module (component loading, messaging) |
| `_IframeSDK.*.min.js` | Iframe SDK module (runs inside component iframes) |
| `_helpers.*.min.js` | Helpers (CloudRepository, config builders) |

When a module is needed (e.g. `getHostModule()`), the root SDK dynamically creates a `<script>` tag to load the corresponding chunk.

### Base Path Resolution

The SDK determines **where to load chunks from** using `document.currentScript.src` — the URL of the root `myop_sdk.min.js` script. For example:

```
Script src: https://cdn.myop.dev/sdk/next/myop_sdk.min.js
Resolved base: https://cdn.myop.dev/sdk/next/
Chunk URL:    https://cdn.myop.dev/sdk/next/_HostSDK.a1b2c3d4.min.js
```

This works automatically in most setups. However, **caching proxies** can break this mechanism.

## The Caching Proxy Problem

Some hosting platforms optimize JavaScript by combining, relocating, or proxying scripts through their own URLs:

- **LiteSpeed Cache** (WordPress) — combines scripts into `/wp-content/litespeed/js/...`
- **Cloudflare Rocket Loader** — rewrites script tags
- **WP Rocket, Autoptimize** — similar JS optimization plugins

When a proxy relocates `myop_sdk.min.js`, `document.currentScript.src` returns the **proxy URL** instead of the CDN URL. The SDK then tries to load chunks from the proxy path — where they don't exist:

```
Script src (rewritten): https://example.com/wp-content/litespeed/js/c9d89370.js
Resolved base:          https://example.com/wp-content/litespeed/js/
Chunk URL (404!):       https://example.com/wp-content/litespeed/js/_IframeSDK.fe8716bb.min.js
```

**Result:** Chunks return 404, components fail to initialize (timeout errors).

## Fix: Override the Base Path

Add this **before** the SDK script tag (or the optimized/combined script that includes the SDK):

```html
<script>
  window.__federation__ = {
    __public_path__: 'https://cdn.myop.dev/sdk/next'
  };
</script>
```

This tells the SDK to always load chunks from the specified URL, ignoring the auto-detected path.

### Full Example

```html
<!-- Override chunk base path (required when using caching proxies) -->
<script>
  window.__federation__ = {
    __public_path__: 'https://cdn.myop.dev/sdk/next'
  };
</script>

<!-- SDK script (may be optimized/combined by LiteSpeed, Cloudflare, etc.) -->
<script src="https://cdn.myop.dev/sdk/next/myop_sdk.min.js"></script>
```

### WordPress / LiteSpeed Example

If LiteSpeed has already combined your scripts, add the override snippet in your theme's `<head>` **before** the combined script:

```html
<script>
  window.__federation__ = {
    __public_path__: 'https://cdn.myop.dev/sdk/next'
  };
</script>
<!-- LiteSpeed combined script (includes myop_sdk.min.js) -->
<script data-optimized="1" src="/wp-content/litespeed/js/c9d89370.js"></script>
```

## Automatic CDN Fallback

Starting from SDK version **0.3.25**, the SDK automatically retries chunk loading from the CDN when a chunk fails to load from the detected path. This handles most caching proxy scenarios without requiring the `__public_path__` override.

However, setting `__public_path__` is still recommended when you know a proxy is in use — it avoids the initial failed request and the retry delay.

## Diagnosing Chunk Loading Issues

### Symptoms
- Components don't render (blank container)
- Console shows `timeout_5000` errors
- Network tab shows **404** responses for `_HostSDK.*.min.js` or `_IframeSDK.*.min.js`

### Steps to Diagnose

1. **Open DevTools → Network tab** and filter by `_HostSDK` or `_IframeSDK`
2. Check the **URL** of the failed request — if it points to your domain instead of `cdn.myop.dev`, a caching proxy has rewritten the script source
3. **Open DevTools → Console** and run:
   ```js
   console.log(window.__federation__.__public_auto_path__);
   ```
   If this shows your domain instead of `cdn.myop.dev`, the base path was mis-detected

### Quick Console Fix (for testing)

To verify the fix before making code changes, run this in the console **before** navigating to the page, or use it as a browser override:

```js
window.__federation__ = {
  __public_path__: 'https://cdn.myop.dev/sdk/next'
};
```

Then reload the page. If components load correctly, add the `__public_path__` snippet to your HTML.

## `__federation__` Reference

| Property | Type | Description |
|----------|------|-------------|
| `__public_path__` | `string` | Explicit base URL for chunk loading. Takes priority over auto-detection. |
| `__public_auto_path__` | `string` | (Read-only) Auto-detected base path from `document.currentScript.src` |
| `__use_public_auto_path__` | `boolean` | (Internal) Whether auto-detection is active |
| `__loading_timeout__` | `number` | Chunk loading timeout in ms (default: 5000) |
