` element.
2. **CSS-structural characters stripped from a `style` value** are reported.
3. **An un-annotated interpolation in a JavaScript-evaluated attribute** is
reported.
Points 2 and 3 are advisories recorded in development mode only. In production
both things still happen, silently. Given
`style="color: ${ c }"` with `c = "red; background: url(x)"`, both modes emit
`style="color: red background: urlx"`; only `render_dev` tells you the value lost
characters.
**An editor or preview pane wants `render_dev`.** A production SSR path wants
`render`.
The **budget** diagnostics are not among the development-only pair. Loop
truncation at 1,000 items, the output-byte budget and the render-depth budget are
reported in **both** modes, because each one silently removes content from the
page. See [Limits](/slurp/troubleshooting/limits).
## `validate` and `validate_full`
```ts theme={"languages":{"custom":["/languages/slurp.json"]}}
function validate(source: string): JsonString
function validate_full(source: string, isMiddleware: boolean): JsonString
```
Both return a flat array of errors **and** warnings, not the split shape the
other exports use. An empty array means clean.
**These two do not report the same thing, and the difference is
security-relevant.**
`validate` parses. `validate_full` parses **and** runs the compiler's
compile-time security walk, which is what `slurp build` and `slurp validate`
enforce.
Rules that live in the walk and not in the parser:
* an unfiltered `${ }` in a `'
parseJson(validate(src)) // []
parseJson(validate_full(src, false)) // [{ code: 'UnsafeScriptInterpolation', line: 1, column: 20, ... }]
```
**Prefer `validate_full` for an authoring tool, a publish gate or a CI check.**
The two stay separate rather than merged so pure editor-preview hosts are
unaffected.
Two things at the call site:
* **`isMiddleware` must match the value the eventual compile will use.** The
rules are inverted, not merely looser: `request.*` and `{redirect}` are legal
only in middleware, and most other path roots are illegal there. A caller with
no way to know passes `false`, which is what the CLI and both Rust `compile`
entry points do.
```ts theme={"languages":{"custom":["/languages/slurp.json"]}}
const mw = '${ request.path }
'
parseJson(validate_full(mw, false)) // [{ code: 'MiddlewareScopeViolation', ... }]
parseJson(validate_full(mw, true)) // []
```
* **The security walk returns on its first violation.** It is a `Result` in Rust,
not an accumulator, so at most **one** security diagnostic is appended per
call, while parse diagnostics accumulate normally. Fix the reported one and
re-run to see the next.
## `extract_schema`
```ts theme={"languages":{"custom":["/languages/slurp.json"]}}
function extract_schema(source: string): JsonString
```
```ts theme={"languages":{"custom":["/languages/slurp.json"]}}
interface SchemaResult {
ok: boolean
schema: SerializedSectionSchema | null
errors: SlurpError[]
warnings: SlurpError[]
}
```
Reads the `section { }` block out of a template's frontmatter as editor-facing
JSON. `schema` is `null` when the template declares none, which is not an error.
```ts theme={"languages":{"custom":["/languages/slurp.json"]}}
const src = [
'---',
'section {',
' name: "Hero"',
' settings { heading: text = "Hi" }',
'}',
'---',
'${ section.settings.heading }
',
].join('\n')
parseJson(extract_schema(src)).schema
// { name: 'Hero', settings: [{ key: 'heading', type: 'text', default: 'Hi' }], blocks: [] }
```
This is also the fastest way to debug frontmatter, because **unknown frontmatter
directives are skipped silently**. If a directive did nothing, this shows you
what the compiler actually read.
## `render_section`
```ts theme={"languages":{"custom":["/languages/slurp.json"]}}
function render_section(
astJson: string,
sectionStateJson: string,
contextJson: string,
): JsonString
```
Renders a section template with saved editor state merged over its schema
defaults. An editor uses it for an instant preview of a fetch-free section, with
no server round trip.
```ts theme={"languages":{"custom":["/languages/slurp.json"]}}
const src = [
'---',
'section { settings { heading: text = "Default" } }',
'---',
'${ section.settings.heading }
',
].join('\n')
const ast = JSON.stringify(parseJson(parse(src)).ast)
const state = JSON.stringify({ settings: { heading: 'Saved', bogus: 1 } })
parseJson(render_section(ast, state, '{}')).html // '\nSaved
'
```
The merge is tolerant: unknown keys such as `bogus` above are dropped and
out-of-range numbers are clamped to the schema's `min` and `max`, rather than
rejected, so saved state survives a theme update.
It renders in **production** mode and it does **not** take a block catalog, so
`@theme`-targeted blocks are dropped from the output while surviving in storage.
That is a host-side concern; see
[Embedding with Rust](/slurp/reference/rust-api#sections-and-theme-blocks).
***
## Security
**`parse`, `render`, `render_dev`, `validate`, `extract_schema` and
`render_section` do not run the security walk. `validate_full` is the only one
that does.**
`SLURP_SECRET_*` access, middleware scope and the redirect restrictions are
server-side concerns enforced by the host, and a preview is not a deploy. A
template that violates all of them parses and renders cleanly through the other
six.
**Do not use a WASM render as a production render path.** Use the
[Rust API](/slurp/reference/rust-api) server-side, where `compile` and its relatives
run the walk on every call.
What a WASM render **does** still apply is the renderer's own script-context
backstops, because those live in the renderer rather than the walk. An unfiltered
`${ }` in a `'
const r = parseJson(render(JSON.stringify(parseJson(parse(bad)).ast), '{"user":{"name":"A"}}'))
r.ok // false
r.html // ''
```
So the escaping guarantees hold in WASM. The **policy** rules do not.
***
## Diagnostics
Every export reports through the same shape:
```ts theme={"languages":{"custom":["/languages/slurp.json"]}}
interface SlurpError {
file: string
line: number
column: number
message: string
severity: 'error' | 'warning' | 'info'
code: SlurpErrorCode
}
```
`file` is always the literal `"wasm-input"`, since these functions take a source
string and know no path. Substitute your own when you surface a diagnostic to a
user.
`code` is machine-consumable, so match on it rather than pattern-matching the
message. See [Error codes](/slurp/reference/errors).
***
## The browser runtime is a different package
Not to be confused with this one. **`@bytesell/slurp-runtime`** is the optional
client runtime that ships to a visitor's browser; this package is the compiler. A
page using none of `{fetch}`, `{$let}`, `{try}` or client navigation does not
need the runtime at all.
The core bundle measures 2,570 bytes gzipped, and Alpine is an external import
rather than something bundled into it.
The runtime's capability and the compiler's output do not currently meet in the
middle:
* It registers **zero** Alpine magics and **zero** Alpine directives. It touches
Alpine in exactly three places: `Alpine.start()`, `Alpine.initTree()` after a
client navigation, and `Alpine.data('slurpFetch', ...)`.
* **`{$let}` has no hydrator.** Nothing reads `data-slurp-let`.
* Several markers the runtime looks for have **no producer in the compiler**:
`[data-slurp-page]`, ``, `x-data="slurpFetch(...)"`
and `[data-slurp-sentinel]`.
In practice that means the fetch and infinite-scroll bundles are not reachable
from compiled output today, which is why they are published behind an
`experimental/` prefix (`@bytesell/slurp-runtime/experimental/fetch` and
`.../experimental/infinite`) rather than from the package root. Client navigation
needs a theme that supplies `[data-slurp-page]` and a `navigate` attribute on
`` itself.
A host can supply any of the above.
***
## Next
The server-side path, where the security walk runs on every compile.
What each `code` means.
The budgets a render reports in both modes.
The VS Code extension, which is a consumer of this package.