I'm personally surprised about that, given the degree to which web component advocates prioritise encapsulation — it seems like a footgun, honestly

Personally, I think class is too blunt an instrument — it breaks encapsulation, allowing component consumers to change styles that they probably shouldn't, while also denying them a predictable interface for targeting individual styles, or setting theme properties globally

...but ultimately the component itself has control over what is exposed, and can specify its own fallback values using normal CSS custom property syntax:

A component should be in complete control of itself. Not only should a component's styles not leak out but other component's style should never leak in. Consider this 'Encapsulation part 2' if you will. When writing a component, you have certain guarantees that not only will the styles you write be contained within the component, but nothing from the outside should affect you either. You have a certain confidence that if it works in isolation, then it will continue to work when embedded within a complex application.

CSS encapsulation is a critical feature of single file components in Svelte; it allows you to think only about the styles that live together in a given component. Managing CSS has long been one of the more challenging aspects of building for the web; we have no desire to bring those problems back via official APIs that encourage the de-scoping of CSS. We do not wish to revisit the age of namespaced CSS selectors and required preprocessors.

Often, allowing the parents to compose elements to be passed into components can offer the flexibility needed to solve this problem. If a component wants to have direct control over every aspect of a component, then it should probably own the markup as well, not just the styles. Svelte's slot API makes this possible. You can still get the benefits of abstracting certain logic, markup, and styles into a component, but, the parent can take responsibility for some of that markup, including the styling, and pass it through. This is possible today.

Svelte is an opinionated tool; it has opinions about how things should be done and what should be allowed. By adding constraints, we have managed to create a simple API and a performant output. These are often conscious decisions: we don't necessarily agree with historic approaches or how other tools are doing things, and we are happy to push back where we think there may be a better way. This is one of those cases, and I feel that context is important here.

The problem with the export { className as class } approach is that the classes defined in the parent/calling component still have to be marked as being global otherwise they get removed.

In my mind, the primary argument for this is that it's a very common thing to need and cleaner than the current alternative of string manipulation or wrapping the child component in a <div class:active><Child /></div>.

Syntax-wise, I would like to be able to pass id, style and class DOM attributes as well as (ideally) svelte props to whatever the slot was replaced with, so prefixing everything with attr in the slot that should be passed sounds like a good idea. Examples: <slot attr:class=“test” attr:class:active={true} /> or <slot attr:style=“color: red” attr:id=“henlo” />

So to experience another change-detector I made a little “sister” of Svelte is Malina.js, which instead of checking if a variable was changed, it checks if a binding was changed (bind-checking). Below are a few examples how it’s better.

Svelte offers an immutable way — but it’s just a mask to hide “assignment”, because assignment triggers an update, but not immutability. So it’s enough to write todos=todos, after that Svelte triggers an update.

Like with React, you can pass in callback props like onSave and onDelete, which is the main way you send data out of a component to a parent.

But if you’ve spent time building front ends with components, it’s hard to go back. Svelte lets us do that with a minimum of fuss or code bloat.

$: declares a relationship, where remaining should always be 10 - count. This might seem weird, but it’s conceptually the same as declaring a variable that you know will be re-calculated in every React render loop — except that remaining will get recalculated only when count changes.

Since you often want to do calculations based on state, Svelte also has the “reactive declaration” symbol, $:. It’s like a let declaration, but whenever any variable referenced in the expression — count in this case — is updated, the expression is re-run, the new variable’s value is updated, and the component is re-rendered.

The heart of Svelte’s magic is “reactivity”. Every let declaration sets up a listener, where any time the variable is assigned to, the change triggers a render of the component. So when the increment function calls count++, the component will re-render, which will update the value shown to the user by Count: {count}.

To change component state and trigger a re-render, just assign to a locally declared variable.

Reactive statements run immediately before the component updates, whenever the values that they depend on have changed.

For interoperability with RxJS Observables, the .subscribe method is also allowed to return an object with an .unsubscribe method, rather than return the unsubscription function directly.

style="--columns:{cols}"

Svelte, on the other hand, is a compiler. In a way, Svelte is more like a programming language than a library.

In most component frameworks, you need to write some code to define your component. With React, the simplest component is an empty function. In other frameworks, you need to import a library and call a special function to define and create your component. With Svelte, you just create a new .svelte file.

With Svelte, components and files have a one-to-one relationship. Every file is a component, and files can't have more than one component. This is generally a "best practice" when using most component frameworks.

Being able to use an empty file as a Svelte component was useful during refactoring, because I could just create a placeholder file for the new component, import it and start using it

You're not limited to using $count inside the markup, either — you can use it anywhere in the <script> as well, such as in event handlers or reactive declarations.

$: console.log(`the count is ${$count}`);

async function onEdit() { editing = true // enter editing mode await tick() nameEl.focus() }

Stores are global state. While context is local state.

Notice it's not related to components. Another crucial difference is that it's accessible from outside of components. And good way to determine where goes where is to ask yourself, can this particular state and functionality still makes sense outside of the displayed component?

Write svelte components in jsx.

This package exposes an hyperscript compatible function: h(tag, properties, ...children) which returns a svelte component.

In this app, we have a <Hoverable> component that tracks whether the mouse is currently over it. It needs to pass that data back to the parent component, so that we can update the slotted contents. For this, we use slot props.

In fact, you might use the two together. Since context is not reactive, values that change over time should be represented as stores:

The previous example contained a default slot, which renders the direct children of a component. Sometimes you will need more control over placement, such as with this <ContactCard>. In those cases, we can use named slots.

Components with TypeScript can be type-checked with the svelte-check command

To type the variable, do this

"watch:check": "svelte-check --watch"

To add documentation on a Svelte component that will show up as a docstring in LSP-compatible editors, you can use an HTML comment with the @component tag:

def svelte_compontent(name, props) content_tag(:div, nil, id: "svelte-#{name.dasherize}-root", 'data-props': props.to_json) end

It's recommended to put the fetch in onMount rather than at the top level of the <script> because of server-side rendering (SSR). With the exception of onDestroy, lifecycle functions don't run during SSR, which means we can avoid fetching data that should be loaded lazily once the component has been mounted in the DOM.

Now, when the user interacts with the keypad, the value of pin in the parent component is immediately updated.

A # character always indicates a block opening tag. A / character always indicates a block closing tag. A : character, as in {:else}, indicates a block continuation tag.

If you have an object of properties, you can 'spread' them on to a component instead of specifying each one: <Info {...pkg}/>

Take the case of the <input> element in this component — we could add an on:input event handler that sets the value of name to event.target.value, but it's a bit... boilerplatey

But that's a lot of code to write, so Svelte gives us an equivalent shorthand — an on:message event directive without a value means 'forward all message events'.

preventDefault — calls event.preventDefault() before running the handler. Useful for client-side form handling, for example. stopPropagation — calls event.stopPropagation(), preventing the event reaching the next element passive — improves scrolling performance on touch/wheel events (Svelte will add it automatically where it's safe to do so) capture — fires the handler during the capture phase instead of the bubbling phase (MDN docs) once — remove the handler after the first time it runs self — only trigger handler if event.target is the element itself

In some frameworks you may see recommendations to avoid inline event handlers for performance reasons, particularly inside loops. That advice doesn't apply to Svelte — the compiler will always do the right thing, whichever form you choose.

Any top-level statement (i.e. not inside a block or a function) can be made reactive by prefixing it with the $: JS label syntax.

Shorthand attributes It's not uncommon to have an attribute where the name and value are the same, like src={src}. Svelte gives us a convenient shorthand for these cases: <img {src} alt="A man dances.">

I was just expressing that, even thought I like React, I dread having to still manually handle everything, instead of just using a directive, a la Vue.JS. This is what I consider boilerplate. Hence my comment on how I could leave React for Svelte just because of that. Clearly a Svelte side-by-side code comparison shows a much cleaner code for Svelte.

<script> let a = 1; let b = 2; </script> <input type="number" bind:value={a}> <input type="number" bind:value={b}> <p>{a} + {b} = {a + b}</p>

I'm saying I'm ready to switch just because of the clarity of the code.

State management is also easier. Instead of importing hooks and using setters, you just define a property within the script tags. You then change the value by re-assigning it (not mutating the original value).

But it’s impossible to argue with the value binding. You don’t have to worry about defining the value property and an onChange event for an input box in Svelte, bind:value does it all