Oleg Isonen
9a8ae2dc8f
Closes #6605 New Forms show editable feedback while Resource actions run. The `formProgress` variable starts with `status: "idle"`, `loaded: 0`, `total: 0`, and `files: []`. It becomes pending during submission, then returns to idle. The existing `formState` still reports only initial, success, or error. The Progress container says “Submitting…” and adds measured whole-request bytes when the total is known. Files include ID, field name, name, size, and type. The browser cannot measure reliable per-file transfer bytes in the single multipart request. The binding editor suggests one example file to reveal those fields; the example never enters the actual Form value. Saved Forms retain their existing bindings and submission message. ## Checklist - [x] Keep the existing Form outcome variable and add upload activity, byte counts, and file details. - [x] Show zero byte defaults on insertion, new submissions, cancellation, and Preview reset without fake runtime files. - [x] Suggest file fields in Form and Resource bindings while evaluation, reset, rendering, and stored values use real data. - [x] Preserve Builder Preview headers, authentication, response checks, and cancellation. - [x] Keep existing success/error feedback and saved-Form fallback. - [x] Reset external progress when an active published Form unmounts. - [x] Update Form, Variables, and MCP/CLI guides; clarify the older screenshot and final-only simulation. Generated MCP docs check passes. - [x] Audit Form and Variables docs against final progress behavior; clarify the older Variables screenshot. - [x] Cover lifecycle, transport, repeated submission, cancellation, unmount, Preview, template, MCP binding/style, and editor completion with focused tests. - [x] Run relevant typechecks, lint, formatting, fixture generation, and independent review. - [x] Required CI checks pass on the latest commit. ## Verification Local focused Form browser tests (25), Form template tests (12), Builder Preview and Form context tests (14), and mounted editor example/reset tests (6) pass. Builder, SDK React, SDK registry, and project-build typechecks pass, as do lint, formatting, and fixture generation. The fixture sync regenerated two unrelated linked-project site paths; those outputs were restored before commit. Independent review found no remaining issues. All latest-commit checks passed; E2E shard 9 passed on a targeted rerun after its two Form tests also passed locally with 11 related tests. This follow-up adds 162 net non-test lines, more than the initial estimate. The extra code identifies the actual callback-bound variable by ID, even when renamed, and gives autocomplete a separate example scope so it cannot affect actual values. One provider covers Form fields and Resource editors. No schema or package was added. The existing Variables screenshot predates `formProgress`; its explanatory text is current. The React Router fixture's built browser client grew by 4 KiB on Linux CI (376 → 380 KiB), and its checked limit matches that measured output. Multipart transfer remains one whole request. Browser submission supplies live progress. MCP can discover `formProgress`, bind the Progress container, and style it; server simulation reports final outcomes and does not measure browser uploads.
Webstudio CLI
The Webstudio CLI helps you to link, sync and build projects from Webstudio Cloud. This README will guide you through the process of setting up a Webstudio project on your local machine and continually sync it with the cloud.
Prerequisites: Installing Node.js
You need Node.js to use the Webstudio CLI. If Node.js is already installed in your system, you can skip ahead to the section on installing the Webstudio CLI.
To install Node.js using NVM, first install NVM by running:
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash
Once NVM is installed, you can install Node.js version 22 by running:
nvm install 22
Verify your Node.js installation by checking its version:
node --version
Installing the Webstudio CLI
To get started with the Webstudio CLI:
-
Download and install the CLI using the following command:
npm install -g webstudio@latest -
Confirm the installation by checking the CLI version:
webstudio --version -
To keep your CLI updated, use the same command used for installation whenever a new release is available.
Initiating a Webstudio Project
Now, you can run a Webstudio project on your local machine using this command:
webstudio
This will initiate the flow to connect your Webstudio Cloud project and build it in your local computer. The default flow will guide you through the steps. You can also perform all the operations individually using independent commands.
Commands
Here is the list of independent commands:
- version
- help
- link
- sync
- build
link
The link command stores access to a Webstudio Cloud project. MCP clients use that connection to read and edit the latest Builder build directly; the project does not need to be published or synchronized first.
Shell-capable agents can call MCP tools directly as CLI subcommands immediately after linking. This does not require MCP client configuration or a client restart:
webstudio meta.index
webstudio components.search '{"brief":"button"}'
webstudio insert-fragment --input-file .temp/insert-fragment.json --dry-run
.temp/insert-fragment.json:
{
"parentInstanceId": "<parent-id>",
"fragment": "<section />"
}
The explicit equivalent is webstudio mcp single-op-call <tool> '<json>'.
Use webstudio connect <client> only when you want persistent native MCP tools
inside Claude Code, Codex, Cursor, or VS Code. A persistent client may need to
reconnect after its configuration or cached tool catalog changes.
See the Webstudio MCP documentation for setup, discovery, editing, verification, and safety guidance.
You can link a project from Webstudio Cloud with the following command:
webstudio link
This command will prompt you to paste a link which you can create using the Share option in your project.
Make sure to provide Build access when generating the link in Webstudio Cloud.
sync
Once the project is linked, use the sync command to sync it with the cloud:
webstudio sync
Sync downloads the current saved Builder project and its asset files, then prepares the local content index. Publishing is not required.
Use the export with webstudio build or webstudio import --to "<target-share-link>". Sync is not required for MCP editing.
build
Now, you can build your project with the build command:
webstudio build
During this phase, the CLI establishes the necessary routes and pages, scaffolding the entire application using the default Remix template. Additionally, all assets, such as images and fonts are downloaded to the assets folder inside the public directory.
Once the project is scaffolded, you can run npm install and then npm run dev to run your app in development mode.
If you want to build a production version of the app, you can run npm run build.
Deployment
Vercel
Once you've built the project locally, you can use the Vercel CLI to deploy your project directly to Vercel:
vercel deploy
Follow the instructions here to install the vercel CLI. We plan to add more deployment targets in future.
Netlify
If you want to deploy to netlify, you can use Netlify CLI to deploy your project directly to Netlify:
netlify deploy
You can configure the project to support netlify serverless/edge-functions respectively, as deployment target at the time of initially setting up your project. Please check the initiating-a-webstudio-project section.
You can manually change it using the build command. For serverless functions:
webstudio build --template netlify
Important Notes
If you use vercel build before vercel deploy, make sure to clean your app folder in the project afterward.
Vercel injects a few files to support and deploy Remix using their CLI, but these files are not necessary for your project when you use it locally.