solidjs/solid @solidjs/compiler@2.0.0-rc.17

on GitHub

Patch Changes

• a40b6cd: The directives pass rejects a broadcast() render that reads the server function's outer body. The render is shared by every caller with the same arguments, but the body runs per caller, so the first caller's value would show for everyone. The returned component, and any local function it renders, may read the function's parameters, its own locals and module scope.

• 3e72783: The removed Solid 1.x attribute forms are now compile errors on native elements in the dom and ssr generates (#4187). on:, oncapture:, attr:, bool:, use: and classList used to compile silently into literal attributes (<div use:tip="() => {}">, classlist="[object Object]"). Both compilers now reject them with the same message, which names the 2.0 replacement: a camelCase handler or a ref callback for on:, a plain attribute for attr:, a boolean value for bool:, a ref directive factory for use:, and an object or array class for classList. Components, the universal generate, prop: and the XML namespaces (xlink:, xml:, xmlns:) are unaffected. The check runs only at compile time and adds no runtime code.

• 6cca8b5: Dev builds now warn with UNCOMMITTED_INPUT_OVERWRITTEN (#4186) when a stateful DOM property binding (value/checked on an input, value on a textarea, value/selected on an option, muted on media) is about to re-write the value it wrote last time over an edit the user never committed to the bound signal — e.g. value={props.name} onChange={commit} with no draft signal, when another dynamic attribute in the same template changes. Runtime behavior is unchanged: the write still happens, once per element and property the warning names the fix (write the signal from onInput, use defaultValue/defaultChecked for an uncontrolled element, or write a rejected edit back with e.currentTarget.value = next).

  Production output is unchanged byte for byte. In dev DOM output both compilers write stateful properties through a new setStatefulProperty(el, name, value) helper instead of the inline el.name = value; hydratable output keeps setProperty, and spread/assign check in the runtime. The check lives only in @solidjs/web's dev build; the production entry carries a plain node[name] = value stub that no production-compiled module imports, so it tree-shakes away.

  The "Form inputs" section of the DOM RFC, the cheatsheet and the solid-2.0 skill now say that a change to any other dynamic attribute in the same template re-runs a stateful binding, link the new code, and drop equals: false as a way to reject input (it is what the warning reports); write the accepted value back with e.currentTarget.value = next instead.

• 2ba1c4a: A valueless prop: attribute (<el prop:active />) now compiles as prop:active={true}, matching bare plain attributes, instead of being dropped silently (#4180).