Sterling-svelte v2 is built on Svelte 5, while sterling-svelte v1 is built on Svelte 4. There are breaking changes between Svelte 4 and Svelte 5. You will need to deal with these breaking changes when moving from sterling-svelte v1 to v2. Don't worry, the changes are straightforward.
We recommend reading the Svelte 5 migration guide first.
Components use $state, $derived, and $effect rather than
the let and $:. While not technically required, prefer to use runes in
your components and pages that pass props to sterling-svelte components.
Each component defines their props types that are intersected with the HTML attributes for the primary HTML element they render. The $props rune is used to access props and props are passed to the primary HTML element.
Svelte 5 handles events from HTML elements using onevent callbacks. These do not change the case of the event name (e.g. click events are handed by onclick). Components in sterling-svelte, camelCase component event callbacks to distiguish them from HTML events. For example, the List has an onSelect callback.
Following Svelte's move to snippets, components use the children snippet rather than
the default slot. Components also provide named snippets often with default content rather than named
slots.
Some components will provide a snippet property than can be a string or a snippet. This allows
you to pass a string directly rather than have to write {#snippet}{/snippet} within the component tags. For example, Switch has offLabel and onLabel properties that are string | Snippet.
Svelte 4 made it difficult to export a class property from components. This
resulted in sterling-svelte 1 exporting a variant property on every component that
was appended to class when rendered. With Svelte 5, components can accept class as a property and the variant
property has been removed.
Some components in sterling-svelte 1 had properties for indicating status. The Label and
Progress components had a status property that could be 'none', 'error', 'warning', 'info', or
'success'. Now, components have removed that property in favor of passing classes on the class property.
Components that need to communicate across hierarchy use getContext and setContext. To allow parent components to change values and child components to update when values changed, context properties were often Svelte stores (e.g. Readable<T>, Writable<T>).
With Svelte 5, context properties are plain Javascript values. To support property changes, the parent creates the context object with getters and setters. This allows values instantiated with $state or acquired with $props to update the UI when the values change.