You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/concepts/variables.mdx
+58Lines changed: 58 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,6 +34,64 @@ Every declaration requires four fields: `id`, `type`, `label`, and `default`. `i
34
34
35
35
The Studio editing UI uses `label`, `type`, and the type-specific options to render the right input widget for each variable.
36
36
37
+
## What can be a variable
38
+
39
+
Variables come in two layers. The five [declared types](#variable-types) above cover typed primitive data — strings, numbers, colors, booleans, enums. For everything else, a `string` variable holding a URL is the escape hatch: your composition reads the URL and assigns it to whatever DOM element needs it.
40
+
41
+
### Parameterizing media assets
42
+
43
+
The same composition can render different images, video clips, or audio tracks just by swapping URLs through a string variable:
The runtime probes the DOM after your composition script runs, so a `<video>` or `<audio>``src` assigned at runtime from a variable is discovered and pre-extracted for the render. No extra wiring required — just set the `src` from your variable.
71
+
</Note>
72
+
73
+
The same pattern covers the three media element types:
74
+
75
+
-**`<img src>`** — assign from a string variable. Chrome fetches it during capture like any other image; no extra config.
76
+
-**`<video src>`** — assign from a string variable, but keep the timing attributes (`data-start`, `data-duration`, `data-track-index`, `data-has-audio`) on the element itself. The probe phase scans `video[data-start]` elements after your script runs and reads the resolved `src` for pre-extraction.
77
+
-**`<audio src>`** — same as video. The audio is decoded during capture and mixed into the final output.
78
+
79
+
Pass assets as URL references your composition resolves at render time; don't inline base64. URL-shaped assets travel cleanly through both the local renderer and the Lambda surface — see [Templates on Lambda](/deploy/templates-on-lambda#working-with-large-variables) for the 256 KiB execution-input cap on distributed renders.
80
+
81
+
## What can't be a variable
82
+
83
+
Some inputs look variable-shaped but are configured elsewhere. The right mechanism for each:
84
+
85
+
| What | Mechanism (not a variable) |
86
+
|------|----------------------------|
87
+
| Composition duration |`data-duration` attribute on the composition element |
| A sibling or parent composition's variables | Variables are per-composition; use [`data-variable-values`](#per-instance-overrides-sub-compositions) on each sub-comp host element to pass overrides |
92
+
93
+
The deeper rule: variables are runtime values, not authoring inputs. A variable can toggle DOM state, swap text, change a color — anything your composition script does with the resolved value. It can't change the composition's structural identity. Two compositions with different `data-composition-id` or different layout markup remain different compositions, even when their variable values are identical.
94
+
37
95
## Reading Variables at Runtime
38
96
39
97
Inside any composition script, call `window.__hyperframes.getVariables()` to get the resolved variable values. The return type is `Partial<Record<string, unknown>>` — use destructuring with defaults matching the declared `default` values:
Templates with [variables](/concepts/variables) work on the same Lambda stack — declare `data-composition-variables` on the composition, then pass values per render with `--variables` or fan a whole batch out with `lambda render-batch`. See the [Templates on Lambda](/deploy/templates-on-lambda) guide for the personalised-render pipeline (single render, batch from JSONL, programmatic SDK) and the 256 KiB Step Functions execution-input cap.
Copy file name to clipboardExpand all lines: docs/deploy/migrating-to-hyperframes-lambda.mdx
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -48,6 +48,12 @@ Most adopters' render config maps directly:
48
48
| Max parallel chunks |`--max-parallel-chunks=16` (default 16) | Caps the Map state's fan-out. |
49
49
| Bitrate / CRF |`--bitrate=10M` or `--crf=18`| Mutually exclusive. |
50
50
51
+
## Variables (inputProps)
52
+
53
+
Render-time payloads — `inputProps` in some frameworks, `variables` in HyperFrames — are isomorphic. Declare the composition's variable shape on the root `<html>` element via `data-composition-variables`, then pass per-render values with `hyperframes render --variables '{...}'` locally or `hyperframes lambda render --variables` on the Lambda surface. The same 256 KiB execution-input cap and "URL your assets, don't inline base64" convention apply.
54
+
55
+
The full mapping — `defaultProps` → declarations, `useCurrentFrame()` + `props.<x>` → `__hyperframes.getVariables().<x>`, `renderMediaOnLambda({ inputProps })` → `renderToLambda({ config: { variables } })` — lives in [Templates on Lambda](/deploy/templates-on-lambda#migrating-from-remotion-lambda-inputprops).
56
+
51
57
## What HyperFrames does differently
52
58
53
59
A few areas where the contract is intentionally different from comparable frameworks. Surface them up front so the migration doesn't surprise you mid-deploy.
0 commit comments