``` **An island in a different project needs two statements, not one.** Tailwind scans one project, so a front-end file in a sibling one is invisible to it — every utility used there would be dropped from the sheet, with the island rendering unstyled and nothing reporting why. Name the directory in the stylesheet: ```css @import "tailwindcss"; @source "../../Shop.Web/Features/Islands"; ``` And name it again to the build, which cannot read that line: ```xml ``` `@source` decides what Tailwind **scans**; `RaskTailwindSource` decides what the build **watches**. With only the first, the sheet is built from those files once and then never rebuilt when one changes — the same staleness as before, one project further out. > **A Lit island is the exception, and it is Lit's rule rather than Rask's.** A `LitElement` renders > into a shadow root, and page-level CSS does not cross that boundary — so the app's Tailwind sheet > cannot reach inside one. Style it with Lit's own `static styles`, or render to light DOM by > overriding `createRenderRoot()`. ## The diff boundary Rask's live runtime diffs the server's render against the browser's DOM. Its subtree is **not Rask's to diff**: React owns those nodes and reconciles them on its own schedule, and two writers on one subtree does not throw — it corrupts on the next parent re-render. So the host element is a boundary. Nothing inside it is ever patched, removed or re-keyed by Rask. What crosses is **props, and only props**: a changed prop travels as a single attribute op, and the client routes it to the adapter's `update` rather than letting it land as an attribute nobody reads. An update is therefore a reconcile, never a remount — the component keeps its scroll position, its focus, its open dropdown and its half-typed field. Callbacks keep their identity across updates for the same reason. React compares props by identity, so a fresh closure per render would invalidate every `useCallback` and `memo` keyed on it and re-fire every `useEffect` that lists it. ## Hot reload `rask dev` runs a Vite dev server for the islands beside the app, so editing a `.tsx` or a `.svelte` hot-replaces in place instead of rebuilding: ``` $ rask dev Serving islands from http://localhost:5174 (hot reload)… ``` Nothing to configure. The dev server starts when the project has islands, dies with the host, and listens on **5174** — not Vite's default 5173, so another Vite project on the machine does not fight it for the port. Override it with `` if something else is already there. **Under VS Code's F5 the app starts it.** No `rask dev` runs beside an app the debugger launched, so a dev-session build starts the same Vite server itself once the build has written its config, and stops it with the app — see [debugging in VS Code](https://rask.sh/docs/guides/cli/#debugging-in-vs-code). The page stays on localhost there, as it does under `rask dev`: an HTTPS page could not load modules from this plain-HTTP server. **It answers loopback origins only** — `localhost`, `127.0.0.1`, `[::1]`. Not a default worth loosening: the dev server also serves `/@fs/`, so an allow-everything CORS policy would let any website open in your browser fetch files from under your workspace root while `rask dev` is running. The cost is that an app you serve on a non-loopback address in development (a LAN IP, a custom hostname) will not load its islands; run it on localhost, or bundle normally with a plain `dotnet run`. What changes during a dev session is one step: the production `vite build` is skipped, because it would rebuild every island in the project on every save and nothing would read the result. Everything else still runs — the entry modules, the prop types, the type-check — and the manifest is still written, pointing at the dev server rather than at chunks. **It works the same on both hosts.** The page has to know where the dev server is before it will load a module from it, and it learns that from the manifest: a dev session's manifest names the server under a reserved `$dev` key, beside the islands. That is all a WASM app has — its page is a static file — and a Rask.Server page is also stamped with `data-rask-islands-dev` on ``. Either way the origin is used only when it is a loopback one, and a built manifest never carries the key. **How much you get back depends on the runtime, and that is upstream's call, not Rask's.** Once the modules are served by the dev server, each framework's own refresh integration owns them: | Runtime | On save | |---|---| | React, Preact | Fast Refresh — component state survives | | Solid | `solid-refresh` — signals survive | | Vue, Svelte | plugin HMR — component state survives | | Lit | full page reload (a custom element cannot be re-registered) | | Angular | full page reload | Even the reload cases skip the C# rebuild, which is the slow half. Rask deliberately does not replace a mounted island itself. Doing so would fight the framework integrations and lose: they preserve component state, and a remount is precisely what the [diff boundary](#the-diff-boundary) exists to avoid. ## What the build does `dotnet build` writes one entry module per component — pairing your component with its runtime's adapter, so `Chart.tsx` stays a plain React component with no Rask import in it — and hands Vite a generated config that builds them into one chunk each, plus the manifest the client runtime resolves names through. **A project using them needs Node and a `package.json`.** That single file is also the gate: a project without one runs no npm, probes for no node, and never learns this package has a build step. A Rask app with no islands is unaffected, which is most of them. A [package island](#using-a-package-component-directly) adds one step, before the compile: the build finds the classes whose `Module` names a package, installs, and reads their props into the snapshots the compile generates from. Its entry module imports the package itself — there is no file of yours to bundle. A project that *does* have both is checked before `npm` runs: too old a Node fails with **`RASKISLAND001`** naming the version it found, rather than failing later inside vite with an engines error nobody reads. The floor is `RaskExternalMinimumNode`, **24.11.0**: the first release of the Active LTS line, the same floor a [front end](https://rask.sh/docs/guides/spa/#which-node) takes, and it follows that line. A Node whose version is not exactly `X.Y.Z` — a nightly, a release candidate — is allowed through rather than refused. Override the bar with `-p:RaskExternalMinimumNode=…` if you have a reason to. `rask new` does all of this. Naming a runtime scaffolds the pair, the dependencies, the tsconfig mapping that makes `@rask/.props` resolve, and the package reference, and puts the island on the home page (`Features/Home/HomePage.cs`), so the first `rask dev` shows it running: ```bash rask new Shop --islands react # one rask new Shop --islands react angular blazor # several, on a server, wasm or wasm-hosted app ``` It refuses `--islands react preact` by name, because npm cannot install both plugins ([above](#react-and-preact-cannot-share-a-project)), and gives each runtime its own folder so two that share an extension never overlap. `blazor` needs no npm at all: the Razor SDK compiles the `.razor` and Rask renders it into the first response. **Checking them.** A scaffold with npm islands also gets [Vite+](https://viteplus.dev/guide/) for the checks: `npm run check` formats and lints in one pass (`vp check`), `npm run lint`, `npm run format` and `npm run format:check` one at a time, and a pre-commit hook in `.vite-hooks/` runs `vp staged` on what is committed. Its config is `vite.config.mjs` — a `.mjs`, because every `.ts` in a host project is a component's scoped TypeScript — and it reaches `Features/` and nothing else, so `appsettings.json` and the rest of the C# side stay `dotnet format`'s. The lint rules are each runtime's own, as in its [front-end template](https://rask.sh/docs/guides/spa/#the-clients-toolchain-vite): Oxlint's React and Vue plugins, and `eslint-plugin-solid` and `eslint-plugin-lit` run inside it. Solid and React islands are both `.tsx`, so in a project holding both, Solid's rules apply under a `Solid/` folder only. The bundle is Vite+ too, and only Vite+: the island build runs `vp build` over the config Rask generates, a dev session serves it with `vp dev`, and a project that does not install Vite+ stops with [`RASKISLAND019`](https://rask.sh/docs/guides/diagnostics/#raskisland019). By hand, if you are adding islands to a project you already have: ```bash npm init -y npm install -D vite-plus vite@npm:@voidzero-dev/vite-plus-core typescript # every runtime npm install -D @vitejs/plugin-react react react-dom @types/react @types/react-dom # React npm install -D @preact/preset-vite preact # Preact (not beside React) npm install -D vite-plugin-solid solid-js # Solid npm install -D @vitejs/plugin-vue vue vue-tsc # Vue npm install -D @sveltejs/vite-plugin-svelte svelte svelte-check # Svelte npm install -D lit # Lit npm install -D @analogjs/vite-plugin-angular @angular/compiler-cli @angular/build \ @angular/core @angular/common @angular/compiler @angular/platform-browser rxjs # Angular ``` These are the packages `rask new --islands` writes for each runtime. It picks their versions the way it does for a [front end](https://rask.sh/docs/guides/spa/#which-versions-a-new-app-gets): the newest releases that install together, written as `^x.y.z` — except `vite-plus`, exact, with `vite` aliased to the core at that same version and the alias repeated under `"overrides"`, so every plugin resolves the one Vite+ ships. Then extend the generated tsconfig fragment ([above](#c-owns-the-props)) so `@rask/.props` resolves, and reference `Rask.External`. Install only what you use. A plugin is written into the generated Vite config **only** when an island of that runtime exists, so a Lit-only app is never asked for `@vitejs/plugin-react`, and a Vue-only app is not either. Package islands of React or Preact need no plugin at all: the package is already compiled JavaScript, so `vite` and the runtime itself are enough. ### Why Vite, and only Vite Rask itself stays npm-free — [#871](https://github.com/pal-tamas/rask/pull/871) fetches esbuild and tsgo as verified native binaries, and the framework's own browser code compiles with no package manager anywhere. That does not change here. What changes is that **you** asked for a React component, and React is an npm package: needing it is inherent to the choice rather than a gap in the framework. A second, esbuild-based path with no npm was designed and rejected. esbuild can do the whole job — `--splitting` gives one hashed chunk per component plus a shared chunk, `--metafile` maps each entry to what was actually emitted, `--jsx=automatic` handles `.tsx`, and two components bundle in about a millisecond. The problem is not capability, it is having two of everything: two bundlers, two failure modes, and "why does it work in project A but not B" for the life of the feature. That tax outlasts a one-time install. The no-npm audience was also narrower than it first appeared. A real Lit component starts `import { LitElement, html } from 'lit'` — which is npm. Only a dependency-free custom element qualified, which is a genuine case but a small one, and not worth a permanent second toolchain. Vite is also what made Vue and Svelte cheap when they landed: a single-file component is compiled by a *Vite plugin*, so each was an adapter rather than a compiler integration. Angular arrived the same way, through `@analogjs/vite-plugin-angular` — and it is the one whose plugin asks for more than itself; see [What Angular needs](#what-angular-needs). **Plugin order is not cosmetic.** A Vue or Svelte plugin claims one extension it alone understands; the React plugin installs a *general* JSX transform. Rask registers the single-file compilers first, because the other order sends a `.vue` to the JSX parser and fails as `Unexpected JSX expression` at line 1 — naming neither Vue nor the plugin that should have handled it. The bundle is written after `wwwroot` has already been globbed, so the build registers it as a **static web asset** rather than relying on that glob. Without it `app.MapStaticAssets()` — which serves only what reached the endpoints manifest — would answer every chunk request with the page's own HTML, and the client would report `Unexpected token '<'` with nothing mounted. Nothing extra is needed in `Program.cs`; in particular `app.UseStaticFiles()` is **not** required. A publish that somehow produced no endpoint for the bundle fails the build with `RASKISLAND003` rather than shipping an app whose components silently never mount. | Property | Default | | |---|---|---| | `RaskExternalBuild` | `true` | `false` skips node entirely. They still render their host elements. | | `RaskExternalOutputDir` | `wwwroot/_rask/external` | Under `wwwroot` so the SDK publishes it with no publish target of its own. | | `RaskExternalPublicBase` | `/_rask/external/` | The URL prefix the manifest gives each chunk. A path on the app's own origin — see below. | **Islands load from the page's own origin, and nowhere else.** The client resolves a manifest and every chunk it names against the page and refuses one another origin serves, with a console error naming the URL; the only exception is the loopback island dev server, while a `rask dev` session's manifest (or the Server host's stamp on the page) names it. An island is code and its `manifest` attribute is markup, so without that rule an app that renders sanitized user HTML could be handed ``. A bundle on a CDN host is therefore not a supported deployment, and a `RaskExternalPublicBase` that names another origin fails the build. **An app served under a sub-path needs nothing extra.** With a [path base](https://rask.sh/docs/guides/deployment/) of `/shop` the runtime script is written as `/shop/_content/Rask.External/rask-external.js`, and the client reads the base back off that URL and asks for the manifest and every chunk under it — on Rask.Server and on a WASM app alike. The manifest itself is unchanged: its chunk URLs are baked at build, before anyone knows where the app will be deployed, so one bundle serves any base. A `.ts` is picked up when a `.cs` of the same name sits beside it. Declare one explicitly only when it lives somewhere that pairing cannot reach — the build-side counterpart of overriding `Module`: ```xml ``` A Lit module default-exports its registered tag name, which is how the generated entry knows what to create — a custom element registers its own tag and nothing about the file reveals it. > **Write a Lit element without decorators.** `@customElement` and `accessor` are standard-decorator > syntax, and the *bundler* is what has to lower them — Vite's oxc-based transform does not. The > failure is silent in the worst way: the chunk builds, ships, and loads, and the element simply never > upgrades, so the island renders empty with nothing in the console and nothing in the build log. Use > `static properties` plus `customElements.define('my-tag', MyElement)`, which is the same API with no > transform to depend on. ### A Lit island and scoped TypeScript in one project Both features are spelled `Name.ts` beside `Name.cs`. The only difference is whether the class derives from `LitComponent` — which Roslyn knows and a glob does not — so the build used to claim files in both directions: the scoped pipeline compiled an island's module as a component asset, and island discovery offered every scoped file to the bundler as a Lit module that never default-exported a tag name. Two opt-outs let a project say which *one* of the features it had, and a project that wanted both could not have them. **Nothing to set now.** The build reads the base list out of the C# and each `.ts` goes to exactly one pipeline. `RaskExternalLitAutoPair` is **retired**: setting it does nothing, and it can be deleted from any project that carries it. `RaskScopedTsAutoInclude` stays — it is Rask.Core's own switch, for a project whose `.ts` files are not component assets at all — but it is no longer something an islands project has to reach for. The reading happens *before* the compile, because the scoped-TypeScript list is compiled and handed to the C# compiler and so cannot wait for the assembly that compile produces. It is therefore a scan of the source rather than a semantic answer, and the build checks it against the real one: after the compile, an island whose declared module is not among the files being built is reported by name as **`RASKISLAND004`**. That report is a warning, so a component written before the file beside it tells you rather than stops you. Because it carries a code, it can also be *suppressed* — which until #1042 it could not, a task warning with no code being reachable by neither `MSBuildWarningsAsMessages` nor `NoWarn` nor anything else. The only lever was `RaskExternalPropTypes=false`, and that switches off the generated prop types too, so quieting the warning meant giving up the type-check it sits beside. Demote it where an island deliberately has no module — a test fixture that exists to be rendered rather than bundled: ```xml $(MSBuildWarningsAsMessages);RASKISLAND004 ``` `MSBuildWarningsAsMessages`, not `NoWarn`: `NoWarn` is the Roslyn switch and does not reach a warning an MSBuild task logs. Scope it to the one project that needs it — the check is the only thing standing between an island's markup and a chunk that was never built. Two consequences worth knowing: - The pairing is per **directory** and per **name**. `Gauge.ts` is `Gauge`'s module only if `Gauge.cs` sits beside it, and only if `Gauge`'s runtime is one that writes a plain `.ts` — a `Chart.ts` next to a `Chart : ReactComponent` stays a scoped asset, because that component's module is `./Chart.tsx`. - A component that overrides `Module` to name something else still has its sibling file claimed. The build says so rather than leaving it silent: the declared module has no file, and that is reported. `` is still there for a file the convention cannot reach. The other runtimes have extensions of their own and were never ambiguous. ### What is verified, and by which test Stated exactly, because "it works on both hosts" is a claim worth being able to check. **WebAssembly, in a browser** — `tests/Rask.Site.E2E.Tests/WasmIslandsExampleTests.cs` drives the islands page of the site (`src/Rask.Site`): Vue, React, Svelte, Solid and a Lit-runtime custom element mount and take their C# props; a Vue and a Lit callback re-enter C# through a `[JSExport]` call into this tab's runtime; a prop change reconciles rather than remounting, each component keeping its own state; and a package island (react-colorful) nested inside the React island calls back into C#. **Server, in a browser** — narrower. `tests/Rask.DevTools.E2E.Tests/ServerIslandJourneyTests.cs` mounts a Lit-runtime island on the Server host and reads the props C# passed, reports one that fails to mount, and clicks a [Blazor island](https://rask.sh/docs/guides/blazor-components/)'s own `@onclick` through to its callback. No browser test drives a React, Vue, Svelte, Solid, Preact or Angular island, or a JS island's callback, on the Server host — what covers those there is the unit suites: the React, Preact, Solid, Vue and Lit adapters under Node (`tests/Rask.External.Tests`) and the handler channel they share with every DOM handler (`tests/Rask.Server.Tests`). **Neither host, in a browser** — Preact and Angular. The site carries no island of either. Preact is covered under Node, below; nothing in this repository mounts an Angular island — its rendering, build plan and prop extraction are unit-tested, its adapter in a browser is not. Both browser suites run in CI after a push to `main` (the browser E2E and devtools E2E jobs), not on a commit. ### Preact, verified without a browser The site cannot carry a Preact island: it carries a React one, and [React and Preact cannot share a project](#react-and-preact-cannot-share-a-project). That is a constraint on a bundled **app**, not on a test — the conflict is between the two Vite plugins, and a test harness installs neither — so it is covered instead by `PreactAdapterTests` in `tests/Rask.External.Tests`, a Node harness that drives the shipped client runtime, the shipped adapter, real Preact and a real DOM (happy-dom): - it mounts into the island element and the component's own `useEffect` runs once; - a `props` attribute change **reconciles** — the heading changes while the component's own `useState` keeps the value a click put there, and the mount effect does not re-run; - a callback called inside the component arrives on the host dispatch channel with its arguments, and stops firing once C# stops passing the delegate; - unmount is `render(null, element)`, so the component's cleanup effects actually run. The packages are pinned and installed under `obj/` on first build; with no npm, no network, or `-p:RaskPreactFixture=false` the tests report **skipped** rather than passing quietly. What this does not reach is `@preact/preset-vite` itself: nothing builds a Preact island through Vite, so a change in its transform is still only caught by building one. ## Islands in a shared class library An island can be owned by a Razor-SDK class library and used by any app that references it. The library bundles it once; the app just renders the component. Nothing special is required in the library — a `Badge.cs` deriving one of the runtime base classes, with `Badge.ts` (or `.tsx`) beside it, exactly as in an app. The build does the rest: it writes `Badge.props.d.ts`, runs the prop type-check (rename a C# property and the *library's* build fails with `TS2339`), bundles with Vite, and registers the chunks as static web assets. What differs is only **where they are served from**. A library's static web assets live under `_content//`, so `RaskExternalPublicBase` defaults to `/_content//_rask/external/` in a class library, and to `/_rask/external/` in an app. Set it yourself to override either. That base is also what the island's host element carries, as a `manifest` attribute: ```html … ``` An app's own islands write no such attribute — the client already assumes the app's manifest. Naming it per element is what lets **one page carry islands from the app and from several libraries at once**: "the manifest" is not a single document, and the client caches one fetch per distinct URL. Two things worth knowing: - The library's base cannot be derived from `StaticWebAssetBasePath` or `StaticWebAssetProjectMode`. Both are empty at evaluation, and once `ResolveStaticWebAssetsConfiguration` has run a browser-WASM app resolves to `_content/Rask.Site` / `Default` — character-for-character what a class library resolves to, while its `wwwroot` is served at the site root. `OutputType` is what separates them, so the default is chosen in the targets rather than the props. - A component whose C# and front-end file are in *different* projects is still not supported, and is reported: `ReportUnbuiltIslands` warns in the project that declares the island, because the module it names is not among the files being built. ## What is not here yet - **Rask markup inside an island.** An island takes children of its own runtime, never Rask elements ([RASK062](https://rask.sh/docs/guides/diagnostics/#rask062)). Handing Rask-owned nodes to a framework that then owns them needs updates addressed by MARKER rather than by DOM path, since `EditOp` paths are positional `childNodes` indices — see [children](#children). - **A callback argument richer than a scalar** — a record or a list is [RASK057](https://rask.sh/docs/guides/diagnostics/#rask057); see [callbacks](#callbacks). - **Server-side rendering** for the bundler-backed runtimes, which is what would make `Hydration.None` broadly useful. --- Source: https://rask.sh/docs/guides/blazor-components/ # Blazor components `Rask.Blazor` hosts a **real Blazor component** inside a Rask page — one from a Razor Class Library, from MudBlazor or Radzen, or any `ComponentBase` you already have. The Razor SDK is neither replaced nor reconfigured: it compiles `.razor` exactly as it always has, and Rask renders the result. This is the [islands](https://rask.sh/docs/guides/islands/) contract with a different runtime behind it. A `.tsx` is a React component rendered by React; a `.razor` is a Blazor component rendered by Blazor. To be exact about what changed and what did not: **you still never write `.razor` to write Rask.** A `.razor` here is a component you are *hosting* — someone else's, or your own from a class library — not the way you author a Rask page. The chain is still the only authoring surface. ```csharp public sealed partial class Chart : BlazorComponent { } ``` ```csharp Div.Class("grid")[ H1["Revenue"], Chart.ChartSeries(_series).Width("100%"), Button.OnClick(Refresh)["Refresh"], // ordinary Rask, right beside it ] ``` ## What works, and what does not Read this table before anything else — it is the whole shape of the feature. | | Hosted Blazor component | |---|---| | Renders, styled, in the **first HTTP response** | ✅ | | `OnInitialized`, `OnInitializedAsync`, `OnParametersSet`, `BuildRenderTree` | ✅ | | Reacts to a Rask prop change, keeping its own state | ✅ | | Its own `@onclick`, `@onkeydown`, `@onwheel`, … firing from the browser, with their real event args | ✅ (see [events](#events)) | | Rask children inside it | ❌ — a compile error ([RASK062](#an-island-takes-no-children)) | | `[Inject]` services — `IJSRuntime`, `NavigationManager`, Rask's browser APIs | ✅ (see [services](#services)) | | `OnAfterRenderAsync` | ✅ — **once**, after the first paint (see [services](#services)) | | `ElementReference`, and anything that takes one | ❌ — captures are discarded | | Its own `@onsubmit`, or an event whose args are a library's own type | ❌ — see [events](#events) | | `@bind` writing a value back | ✅ (see [binding](#binding)) | | WebAssembly, published **trimmed** | ✅ annotated for it, but not gated end to end — see [both hosts](#both-hosts) | ## A worked example End to end, and compiled: the component below is a real `.razor` in the repository, its island is declared in the test suite, and the output printed here is asserted by `tests/Rask.Blazor.Tests/DocExampleTests.cs`. A test also pins this document against the file, so the two cannot drift apart. **1. The Blazor component**, in a Razor Class Library — an ordinary `.razor`, compiled by the Razor SDK, with nothing in it that knows Rask exists: ```razor @using System.Globalization

@Symbol @Price.ToString("0.00", CultureInfo.InvariantCulture)

@code { [Parameter, EditorRequired] public string Symbol { get; set; } = ""; [Parameter] public decimal Price { get; set; } [Parameter] public string? Tone { get; set; } } ``` **2. The island** — the whole declaration. Nothing is redeclared; the chain steps are read from the component's own `[Parameter]`s: ```csharp public sealed partial class Quote : BlazorComponent; ``` There is no third step in `Program.cs`: referencing `Rask.Blazor` is the whole setup. **3. Use it** anywhere the chain goes — a leaf, a subtree, or a whole page: ```csharp Div.Class("grid")[ H1["Watchlist"], Quote.Symbol("RASK").Price(12.5m).Tone("up") ] ``` **What comes back**, in the first HTTP response: ```html

RASK 12.50

``` Three things in that are worth naming: - **`Symbol` opened the chain** because `PriceTag` marked it `[EditorRequired]`. `Price` and `Tone` are ordinary optional steps, and omitting `Tone` leaves the component's own default alone rather than passing null. - **The island is a leaf.** `Quote[ … ]` would be a compile error: an island renders the markup of the component it hosts and takes no Rask children — see [children](#an-island-takes-no-children). - **`12.50` is in the first response**, not painted in later. Had `PriceTag` awaited in `OnInitializedAsync`, that would be finished too. ## Declaring one Derive a `partial` class from `BlazorComponent`. The base class *is* the declaration — there is no attribute — and `T` names the component being hosted. ```csharp public sealed partial class Chart : BlazorComponent { } ``` **You do not redeclare its parameters.** A Blazor component already states its surface, so the chain steps are read from its own `[Parameter]` properties. `MudChart` declaring `[Parameter] public List ChartSeries { get; set; }` is what makes `Chart.ChartSeries(...)` a step. ### Required parameters A parameter the hosted component marked `[EditorRequired]` becomes a **required** chain step — one the call site cannot omit, taken before any optional step. Blazor already has a word for "mandatory", so it maps onto Rask's own and neither framework has to learn the other's idiom. ```csharp // MudBlazor: [Parameter, EditorRequired] public string Label { get; set; } Badge.Label("New") // ✓ required, so it opens the chain Badge.Label("New").Tone("warn") // ✓ optional steps follow Badge.Tone("warn") // ✗ RASK038 — Label is never set ``` Everything not marked stays optional. An `EventCallback` is never required even when marked: "you must handle this event" is not something the chain can usefully insist on, and an unwired callback is simply not wired, exactly as for any other Rask component. The type argument is how the hosted component is named — not a sibling file, the way a `.tsx` island pairs by filename. That is deliberate: the common case has no `.razor` in your project at all, only a referenced type. ### Renaming a step When the hosted parameter's name is not what you want to write at the call site — or collides with a chain entry of the same name, which is what happens for parameters called `Title`, `Label`, `Form` or `Select` — name it explicitly: ```csharp public sealed partial class Chart : BlazorComponent { [BlazorParameter("ChartSeries")] public List? Series { get; set; } } ``` A property you declare yourself always wins over the generated one. The name is checked: one the hosted component does not declare as a `[Parameter]` is a compile error ([RASK100](https://rask.sh/docs/guides/diagnostics/#rask100)) rather than a chain step that sets nothing. ### Where the `.razor` has to live For parameters to be checked at compile time, the hosted component must come from a **referenced** project or package. A `.razor` in the *same* project as the island is produced by the Razor source generator, and one source generator never sees another's output — so Rask's generator cannot read its parameters. The island still works; it just is not verified, and says so through [RASK066](https://rask.sh/docs/guides/diagnostics/#rask066). Move the `.razor` into a Razor Class Library and reference it. Hosting MudBlazor or Radzen — packages, therefore referenced — is fully checked with no warning. ## It is in the first response The component is rendered on the server, during the page render, and its markup is in the HTML that is sent. A hosted component that awaits in `OnInitializedAsync` has **finished** before the response goes out rather than appearing a frame later: ```csharp protected override async Task OnInitializedAsync() { Rows = await _api.Load(); // done before the page is sent } ``` That works because the island does its rendering in `OnUpdated`, whose task is registered in the page's quiescence scope — Rask renders, waits for outstanding work, and renders again, sending the settled wave. See [lifecycle](https://rask.sh/docs/guides/lifecycle/). It is also why a Blazor island suits a whole page a crawler must read. Put `[Route]` on the island and it is the page — a `[RouteParam]` property is a step like any other and can feed a `[Parameter]`: ```csharp [Route("/tickers/{symbol}")] public sealed partial class TickerPage : BlazorComponent { [RouteParam] public string Symbol { get; set; } = ""; protected override Component? HeadAssets => Title[$"{Symbol} — quotes"]; } ``` Overriding `HeadAssets` keeps the stylesheets in `RaskBlazorOptions.HeadAssets`: they are registered on their own, as a JavaScript island's runtime script is, so there is no `base.HeadAssets` to remember. A route parameter that feeds a value-typed `[Parameter]` can be declared as it is (`[RouteParam] public int Id { get; set; }`): a non-nullable value type has no "unset" state, so it is always passed on. Declare it nullable (`int? Id`) only when the hosted component should keep its own default until a value is set. URL attributes in that markup get the treatment a Rask element gives them: `javascript:` and `data:` become `about:blank`, and an inline `data:image/…` survives only where it can do nothing but draw — `src` on `img`, `audio`, `video`, `source`, `track` and `input`, a `video`'s `poster`, an SVG `image`'s `href`. An `