Preview & Publish

Preview tooling and publishing pipelines live together because teams iterate on both continuously. This section summarizes how ResultFly Studio helps authors validate experiences (including “time travelling” the clock) and how those drafts become immutable releases with rollback support.

Preview workflows

Preview modes run entirely inside Studio using the live node graph from your draft. They never alter production data and allow you to inspect internal state safely.

Component Studio

Build and test individual UI blocks in isolation.
Validates bindings, style tokens, and accessibility before the block enters page compositions.
Ideal for teams contributing reusable controls or iterating on complex game layouts.

App Preview

Executes the complete app.json flow behind a mobile frame so authors see the same constraints as end users.
Supports mock integrations (e.g., fake rewards) and exposes event/state inspectors per node.
Mirrors runtime logging so QA can capture traces before publishing.

Diagram Mode

Visualizes the entire node graph with edges, branches, and loops so reviewers can reason about control flow.
Lets collaborators annotate nodes (stickers, TODOs) directly on the diagram.
Acts as an entry point for jumping into Component Studio or App Preview from any node.

Time Travelling

Editors can offset the preview clock by a relative duration or explicit timestamp (e.g., “+5 days”).
Helpful for testing scheduled rewards, expiry logic, or time-limited campaigns without waiting in real time.
The offset applies consistently across timer nodes, conditionals, and backend mocks until reset.

Preview vs runtime parity

Preview renders the same React tree as production but injects additional tooling (state inspectors, logs).
When preview is paused (tab hidden, manual pause), the runtime posts a pause event so components can throttle timers.
Only after a scenario passes preview validation can it move to the publishing stage.

Publishing lifecycle

Publishing promotes a draft into an immutable version that production users consume. Every publish entry is stored so teams can trace history or roll back safely.

Version creation

Each publish action snapshots the entire campaign (nodes, assets, settings) and assigns a monotonically increasing version number.
Publish metadata captures the author, timestamp, change summary, and optional release notes.
Validation gates (schema checks, contract validation, linting) must pass before the snapshot completes.

Version history and retention

ResultFly stores the most recent versions (default: last 10) for quick rollback and auditing. Versions beyond the retention limit are not stored.
History view surfaces diffs between adjacent versions, highlighting node changes and asset updates.
Every version explicitly records which preview build it originated from, closing the loop between testing and release.

Rollbacks

Any stored version can be promoted back to “current” with a single click; publishing a rollback still generates a new version identifier for auditability.
Rollback operations preserve release notes and add an automatic entry explaining which version they supersede.
Access controls ensure only project maintainers can initiate rollbacks in regulated workspaces.

Preview vs production environments

Preview URLs always point to a selected draft or historical version and require authentication.
Production endpoints automatically serve the latest published version unless a rollback overrides it.
Analytics clearly label which version emitted each event so data science can correlate behavior with releases.