This is a very simple task for React and literally impossible for Svelte.

It adds a few constructs to the language to solve one of the most complex problems in UI development — state management.

The official Svelte blog, on the contrary, ends up mind tricking the reader by showing only one side of the coin, sometimes through upfront false statements about web technologies and other libs

As we've briefly seen already, you can listen to any event on an element with the on: directive:

mdsvex is a Svelte preprocessor and is the preferred way to use this library.

A reasonably clean alternative would be to map a function over the array and use destructuring in the each loop: {#each [1, 2, 3, 4].map(n => ({ n, sqr_n: n * n })) as { n, sqr_n }} {sqr_n} {sqr_n / 2}<br> {/each}

Could I get your intuition for why that rule of thumb applies to svelte components but not Javascript functions? I tend to make heavy use of let x = e when writing normal Javascript, as I do in most other languages (though unlambda is a notable exception). How is svelte different?

I discovered that a solution can be hacked using an {#if}, but a proper one would be nice:

Unlike DOM events, component events don't bubble. If you want to listen to an event on some deeply nested component, the intermediate components must forward

(One can already destructure the loop variable but using a store obtained that way currently throws an error - Stores must be declared at the top level of the component (this may change in a future version of Svelte))

Here's a proxy store I wrote to derive the value of a store nested within other stores, it plays nice with typescript and can go infinitely deep

About the argument against it, "{@const will make code less consistent ": I think the same is true now, since people can come up with very different ways of dealing with the "computed value inside each loop/if function" problem. Some extract components, some use functions, some will prepare the array differently beforehand.

Do these blocks allow for reactive assignments? @lukeed They're read-only, but values update when their dependencies do

Generally, you should read the value of a store by subscribing to it and using the value as it changes over time. Occasionally, you may need to retrieve the value of a store to which you're not subscribed. get allows you to do so.

the code is a bit verbose/convoluted

To fix our Svelte version you might think we could use beforeUpdate or afterUpdate, but these lifecycle functions are related to the DOM being updated, not to prop updates. We only want to rerun our fetching when the album prop is changed.

Using another reactive statement with $effect we have Svelte automatically handle subscribing and unsubscribing to the store

With this we have replicated the most important behaviors of useEffect.

The Svelte compiler does the dependency tracking work for us, so there’s no dependency array like in React.

I think Svelte has some things to learn from React hooks.

While react hooks were one of the catalysts for v3 we don't agree with with the APIs or the model and won't be emulating it.

One thing I considered was abusing a custom store for this kind of thing.

Store is reactive because it should re-evaluate when track is changed.

Sometimes, you may be tempted to write that wrapper. Because all your (React or Vue or insert your reactive framework here) instincts tell you so.Resist the temptation. There is a better way. A svelter way. Introducing: the use-directive (a.k.a. “actions”).

Especially when coming from a framework like React, it might feel very tempting to start creating a component wrapper around the input (i.e. <input> becomes <Input/>) and add your custom event handlers in there.This is a great approach in React, but not so much in Svelte. Why, you ask?Well, Svelte (at least in its current form, v3) really shines when you have native DOM elements at your disposal. You can use transition directives, conditionally switch CSS classes, bind to the current value with ease, and more.

However, especially when starting out, it’s very easy to fall into the “this is how I did things in my previous framework” trap.

It can feel like a breeze of fresh summer air.

the benchmarks that Rich chose weren't even remotely good ones. They had obvious flaws that even the authors acknowledge and Svelte's implementation actually cheats what it was testing.

The $: can also be used to trigger effects.

Any variable referenced on the lines marked with $: is marked as a dependency of the derived variable.

Solid is a declarative JavaScript library for creating user interfaces. It's kinda like if React and Svelte had a baby.

Svelte-routering is a great library, I think this is one of the best Routing libraries on the internet that helps us to add the routing functionality in our SPA with a minimal effort, but personally I recommend using this library if you want to create a small application with just a couple of pages and also you don't want to have all the power of a Framework. However, if you are open to use a framework, Sapper is a great option, even if you planning to create a medium size project, with Sapper you will have great control of your application.

An action used on anchor tags to navigate around the application.

Note that interacting with these <input> elements will mutate the array. If you prefer to work with immutable data, you should avoid these bindings and use event handlers instead.

this is a common Svelte idiom for manually invalidating something that might have been mutated without there being a visible = sign somewhere

const store = readable(machine.initialState, set => { service.subscribe(state => { if (state.changed) set(state) }) service.start() return () => { service.stop() } })

The readable store takes a function as a second argument which has its own internal set method, allowing us to wrap any api, like Xstate or Redux that has its own built in sub­scrip­tion model but with a slightly different api.

If you are wondering about the odd looking (d), this keys the component, ensuring that the compiler doesn’t do any fancy sharing of objects that leads to sur­pris­ing bugs. You don’t often need to key items in Svelte, but I have run into some cases where it is essential.

Indeed, this simple contract is very close to that of an ob­serv­able, such as those provided by Rxjs. set is basically equiv­a­lent to next in the ob­serv­able world.

The $ contract for auto-sub­scrib­ing is lovely in its sim­plic­ity and flex­i­bil­ity. You can adapt your own preferred state-man­age­ment pattern or library, with or without Svelte stores as helpers. Svelte does not fuss about how you want to manage your state.

$: for watching de­pen­den­cies in ex­pres­sions, a much more concise useEffect, if React is familiar.

Arguably what is in­ter­est­ing about Svelte’s approach to state man­age­ment is not the store itself but the auto-sub­scrip­tion that is possible because of the Svelte compiler. By simply appending a $ to a variable inside of a component, e.g. $myVariable, the compiler will know to expect an object with a subscribe method on it and generate the boil­er­plate of sub­scrib­ing and un­sub­scrib­ing for you.

Svelte is as general-purpose as they come

It lives in a context="module" script — see the tutorial — because it's not part of the component instance itself; instead, it runs before the component is created, allowing you to avoid flashes while data is fetched.

setClient(writable(apolloClient)); let client getClient().subscribe((_client) => client = _client);

I got this working by using _layout.svelte as the point to initialise and set the Client we can then use getClient in each route that uses this layout.

setContext / getContext can only be used once at component init, so how do you share your API result through context? Related: how would you share those API results if the call was made outside of a Svelte component, where setContext would be even more out of the question (and the API call would arguably be better located, for separation of concerns matters)? Well, put a store in your context.

Other lifecycle functions are onMount, onDestroy, etc. It is arguably less obvious that setContext is such a lifecycle method.

setContext must be called synchronously during component initialization. That is, from the root of the <script> tag

This is pretty good, but I don’t love that $contactStore.length bit. If we wanted to change the shape of the store from an array to a key-value store or something, we’d have to remember to update this component too. Instead, we can define a new derived store: contactCountStore. It’ll always track the count, which lets this component have less knowledge about the structure of the store. That refactor looks like this:

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}.

I used a "specific function". But maybe it could be done within a derived store. A kind of auto reset on ... But I think there is no elagant solution, so I stick with the specific function.

As you can see, it uses Javascript label syntax to tell the compiler where recalculation should be carefully managed. And you thought that no one uses labels any more.

The problem I have with this approach to state and prop variables is that the difference between them is very blurry. In React you can clearly see that a prop is an input to component (because of clear function notation), and that state is something internal. In Svelte they are both just variables, with the exception that props use export keyword.

You know those useMemo and useCallback hooks? Well, Svelte has something like this. If you declare a variable like this: $: double = counter * 2;, Svelte will recalculate it only if counter changes.

for example, reactive declarations essentially do the work of React's useMemo, useCallback and useEffect without the boilerplate (or indeed the garbage collection overhead of creating inline functions and arrays on each state change).

Because Svelte is a compiler, we're not bound to the peculiarities of JavaScript: we can design a component authoring experience, rather than having to fit it around the semantics of the language.

Reducing the amount of code you have to write is an explicit goal of Svelte.

If you're using webpack with svelte-loader, make sure that you add "svelte" to resolve.mainFields in your webpack config. This ensures that webpack imports the uncompiled component (src/index.html) rather than the compiled version (index.mjs) — this is more efficient.

I don't understand why it just launches the mutation once and then it throws the error Function called outside component initialization, the only way to make it work is to do something like $: result = mutation(...) but it doesn't make sense, I don't want to run the mutation after each keystroke.

If calling query() results in calls to Svelte's context API, then it needs to be called synchronously during component initialization.

It looks like the issue stems from having "svelte" as a dependency instead of a devDependencies in package.json within the sapper project. This causes import 'svelte' to load the rollup excluded npm package's set_current_component instead of from within the sapper generated server.js.

urql is a GraphQL client that exposes a set of helpers for several frameworks.

One package to get a working GraphQL client in React, Preact, and Svelte

urql/packages/svelte-urql/ Go to file Add file Go to file Create new file Upload files urql/packages/svelte-urql/

Most simple example: <script> import ChildComponent from './Child.svelte'; </script> <style> .class-to-add { background-color: tomato; } </style> <ChildComponent class="class-to-add" /> ...compiles to CSS without the class-to-add declaration, as svelte currently does not recognize the class name as being used. I'd expect class-to-add is bundled with all nested style declarations class-to-add is passed to ChildComponent as class-to-add svelte-HASH This looks like a bug / missing feature to me.

color: red; //doesn't apply this rule, because scoping doesn't extend to children

Say I want to style this javascript routing anchor tag on various pages (some may be buttons, plain links, images) it makes it incredibly difficult. Eg:

Having to wrap everything in a selector :global(child) { } is hacky

I worry about that being a bit of a Pandora's box — it throws encapsulation completely out the window. The nature of CSS custom properties is that they're inert unless the child chooses to do something with them, which wouldn't be the case for other things.

Allow creating custom components with the same abilities as native dom. By all means keep the same level of encapsulation, don't push class on components, but allow a component to mark the class property or another as a CSS Class property, in which case you could pass it through the same transformation that native elements go through

The problem with working around the current limitations of Svelte style (:global, svelte:head, external styles or various wild card selectors) is that the API is uglier, bigger, harder to explain AND it loses one of the best features of Svelte IMO - contextual style encapsulation. I can understand that CSS classes are a bit uncontrollable, but this type of blocking will just push developers to work around it and create worse solutions.

There is a good amount of properties that should mostly be applied from a parent's point of view. We're talking stuff like grid-area in grid layouts, margin and flex in flex layouts. Even properties like position and and the top/right/left/bottom following it in some cases.

Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.

The main reason using classes isn't a great solution is that it completely breaks encapsulation in a confusing way, the paren't shouldn't be dictating anything, the component itself should. The parent can pass things and the child can choose to use them or not but that is different: control is still in the hands of the component itself, not an arbitrary parent.

The RFC is more appropriate because it does not allow a parent to abritrarily control anything below it, that responsibility still relies on the component itself. Just because people have been passing classes round and overriding child styles for years doesn't mean it is a good choice and isn't something we wnat to encourage.

For my point of view, and I've been annoyingly consistent in this for as long as people have been asking for this feature or something like it, style encapsulation is one of the core principles of Svelte's component model and this feature fundamentally breaks that. It would be too easy for people to use this feature and it would definitely get abused removing the style safety that Svelte previously provided.

This allows passing classes to child components with svelte-{hash} through the class prop and prevents removing such classes from css.

The point of the feature is to not rely on the third-party author of the child component to add a prop for every action under the sun. Rather, they could just mark a recipient for actions on the component (assuming there is a viable target element), and then consumers of the library could extend the component using whatever actions they desire.

They don't need to add a prop for every action. The action itself can be passed in as a prop. <script> export let action; </script> <div use:action>whatever</div> The argument for the action can be another prop or can be part of the same prop.

Your tooltip component will have to wrap your image with a span tag or something, it can’t just add events to its children. And if you are adding multiple actions to it you will have to wrap it multiple times.

<Concern1> <Concern2> </Concern2> </Concern1>

vs.

<img use:concern1 use:concern2>

And of course, if you don't use them you don't pay for them

I have created an action for form validation and its really working well

the notion that any given component should be in charge of its own thing, and not do something outside of itself. I.e., loosely coupled components in a sandbox, not tightly coupled to something outside of its own scope.

<slot ref:img data-visible="{{visible}}" /> In the above everything on <slot> is lost since slot is a space in the HTML, not an actual element. How could we translate this to zero or ten elements inside the slot?

the ability to pass around element names as strings in place of components

Since one of Svelte's main principles is reacting only to data changes (as opposed to re-render the whole app with the full state all the time)

I mean, it's not that bad and it's certainly not much of a runtime cost (especially since it'd only affect components which actually use it -- thanks disappearing framework!).

Re Object.keys(undefined), I think I'm ok with that failing. AFAIK it would also fail in React

The more I think about this, the more I think that maybe React already has the right solution to this particular issue, and we're tying ourselves in knots trying to avoid unnecessary re-rendering. Basically, this JSX... <Foo {...a} b={1} {...c} d={2}/> ...translates to this JS: React.createElement(Foo, _extends({}, a, { b: 1 }, c, { d: 2 })); If we did the same thing (i.e. bail out of the optimisation allowed by knowing the attribute names ahead of time), our lives would get a lot simpler, and the performance characteristics would be pretty similar in all but somewhat contrived scenarios, I think. (It'll still be faster than React, anyway!)

So a "Svelte" way to do document.createElement.

No, this is about using a string to create an element of that tag name.

{#each section as {depth, title, lines}} <h{depth}>{title}</h{depth}> {#each lines as line} <p>{content}</p> {/each} {/each}

I would hope for it to come with React-like behavior where I could pass in a string (like div or a) and have it show up as a normal div/a element when the child component used it.

you may specify only the form state that you care about for rendering your gorgeous UI. You can think of it a little like GraphQL's feature of only fetching the data your component needs to render, and nothing else.

Part of the functionality that is returned are event handlers. I'd like to avoid needing to manually copy the events over one by one so the hook implementation details are hidden.

Forwarding events from the native element through the wrapper element comes with a cost, so to avoid adding extra event handlers only a few are forwarded. For all elements except <br> and <hr>, on:focus, on:blur, on:keypress, and on:click are forwarded. For audio and video, on:pause and on:play are also forwarded.

Using a reactive statement is a good way to explicitly turn a reactive variable into a store

Non-store reactivity needs to be analyzable at compile time.