Surprise! Svelte Secretly Sending Signals

Welcome, everyone, to my talk. It's called Surprise! Svelte Secretly Sending Signals. Before we begin, a small presentation is due. Who am I? I am Paolo Ricciuti. I come from Campobasso, Italy, the land of pizza. And you can find me on BlueSky as paolo.ricciuti.me or on GitHub as Paolo Ricciuti. I'm a Svelte ambassador and a Svelte maintainer, and I work as a senior software engineer at is super cool, because I get to work with Svelte but also to teach Svelte, both at meetups and conferences, just like this one, but also in my day-to-day job because we do what's called team augmentation, which means that we join your team, we help you hire, we teach you Svelte and best practice. We even do workshops. So if you want, you can scan this QR code and also get JS Nation 25 code for 25% off. And we also have a subscription API, not API service, so that if you don't have a full-blown project, you basically get access to our expertise, like, in Slack, and you can basically, like, ask us to review a code and stuff like that.

But it's demo time, because this will actually be 100% live coded, because apparently I hate myself. So let's switch to VS Code, where we are met with the most useless demo. It's a counter that doesn't work unless you keep the party going. And then you can, like, type here, and it will update on top. But the interesting bit is how everything is wired. So this is wired with the old way of doing reactivity in JavaScript files in Svelte, which is with a writable store. The writable store is basically the observer pattern, and you can see an implementation here. It's, like, 20 lines of code. And how you use it is also very simple. Like, you just declare the writable state, and you can subscribe to it, and this function will be invoked whenever the state changes. And then, like, this is a vanilla project, so you are wiring up the button, click listener, and this is how you update the state, which is...

But let's look at the implementation. So you pass an initial value, you store the value here, and then you have a set of subscriber, and here, a set is just a fancy array with no repetitions. And then you have a subscribe function that take a function as input, store it in the subscriber, invoke it with the current value, and then return a function to unsubscribe. Then you have the set function that just, like, sets the new value, like, the value to the new value, and then loop over every subscriber and call the function with the value. The update function is even easier because it's just calling the set function. And the value that you are passing in is this get new value function. Now, as you can see, like, using the store, the writables, is not really pretty. And Svelte is famous for its vibe, like, we want to do stuff simpler. So allow me to introduce you to the proxy API.

So I can do const P is equal a new proxy. The proxy API is very simple, and basically, you get an object like this, and then the second argument is actually a series of traps. And just like a network proxy where you can interject a request, you can basically interject operations on your object. For example, there is the get trap, and the get trap, you get the target and the key that you are trying to access. And you can return target at key for target at key for the default value. But you can also add, I don't know, console.log getting key. And if you do this, and I need something here. If you do this, and if I try to do console.log p.name, and if I save, you can see that in this case, I'm getting the value, which is Paolo, and I'm getting name, which is a sort of side effect. But what we are really interested in is the set function. So you can get a target, the key, and the value. And obviously, you can get the default behavior with target at key is equal to value. You need to return true, otherwise, you will get an error. But even here, you can do some side effect, basically. So if I save, and if I do p.name is equal to JS nation, and I save, you can see that we are getting setting name, JS nation, and then we are getting the actual value. So basically, we can replace these with our set function. And so instead of returning this object, we can do return new proxy.

Now, we need to pass in an object in this case. So we cannot pass literal values anymore. In Svelte, we don't have this limitation because it's a compiler. So I can remove this because since it's an object, the user can just access the object directly since it's a reference. And here I can basically do set, I get the target, I get the key, I get the value, and then I can basically do the same thing that I was doing here. So I can basically set the target at key equal to value to update the value. I need to return true as I've saved. And then we can just call our list of subscribers, the function again. So obviously, you may notice now we have a problem because we don't have a way to subscribe to it. So for the moment, let's do something dirty and let's return a tuple. And the first argument will be our subscribe function. So basically, I can do exactly this inside this function. And obviously, I don't need the value anymore because it's not there. Now, we can update our code now so we can remove all of these.

And we need to, for the moment, we need to update this to get the subscribe out of it. We need to update all this state dot subscribe to just be subscribe. We say that we don't need this dollar sign state as input anymore because now, we are just doing, we are just accessing the state by default. And now, the fun part is that we can update all of this code.

And here, we can just do state dot count plus plus, which is much, much nicer. And we can do the same thing here. We can do state dot checked is equal to e dot target dot checked. And can remove all of this. And then we can do state dot value is equal to e dot target dot value. And we can remove all of this.

Now, if I did everything correctly and I save, we should have literally the same. And it's not, obviously. What did I miss? Subscribe, subscribe. Did I miss something? Oh, what? How it was there? Yeah. It should be this. Yep. So now, this is literally the same. I don't have to do anything. I just have to do, like, the same thing. I just have to do, like, this. I don't have to do anything. I just have to do, like, this. I don't have to do anything. So now, this is literally the same thing as before. So it works and it's fine.

I don't have to do anything. I just have to do, like, this. I don't have to do anything. So now, this is literally the same thing as before. So it works and it's fine.

Now, we can go home. It's fine. The problem is that let's say that I do console.log running. And if I save, obviously, now, it's running the first time. And if I uncheck the checkbox, it's running. And we kind of expect that, because checked changes. And if we change the number, it's running again, which we kind of expect, because count changes. But if I uncheck and then I change count, it's still running, even though the UI is not really changing.

But, I mean, this maybe is acceptable. The thing that is really not acceptable is this. If I change the value, even though I'm not using the value here, I'm still running that code. So, I don't want to do that. And the reason for this is that we're using a set, so this means that we only have one set of subscriber for all the keys. I can change this if I do map. So, a map is just a fancy object. And so, basically, what I want is I want to have a new set for every key that, for every key.

So, obviously, we need a way to get the key. For the moment, let's do something dirty and let's do this. We loop over every key of keys. And then, if we, the subscriber does not have a key, we create a new set for it. And then, we do const depth is equal subscribers.getKey, like this. So, we get the set of subscribers. And now, we can just do depth.add the function. So, we add the function to this array.

We can remove this and we can basically do the same to clean up everything. So, we can remove all of this. We get the dependency and we do delete function. So, we actually need that. Okay. So, basically, now, we need to update our code in even an uglier way because now we need to manually specify our subscription. So, I need to do checked. I'm interested in checked and I'm interested in count here. For this, I'm only interested in checked. And for this, I'm only interested in value.

Now, if I did everything correctly and I say, oh, I need to do something else. I need to change this to be the key. So, I need to get the subscriber of that specific key. And since this can be null, let's also do this. So that we are safe. And now, it's not working. So, I think... Ah. Okay. Oh, in both places, obviously. Okay. Now, if I save, this should work the same.

And so, if I click, it's running. If I check, it's running. The nice part, however, is that now I can change this and the reactivity still works, but I'm not running that code unnecessarily. Now, obviously, like the DX of this. I started this talk saying, okay, we can have a better DX, and this is actually way worse. So, what I want really is that if I read something in a function, I want that thing to be a dependency of that function.

Now, if you have used Svelte 5 a bit, we introduced runes, which use signals under the hood. And when you declare state, you declare it like this, $state. And then, if you use something like function $effect, where you pass in a function, so if you use a function... If you use a stateful variable inside a function passed in inside the effect, then everything that you read will actually be a dependency of that. And we can actually do that, because we kind of explored it before, but we can do get.

And so, we can know when we read something. So, we can do target, key, like this. We can return target at key. And then, basically, that's the point where we can subscribe. So, instead of doing it here in the beginning, we can do it here. So, if the subscriber does not have the key that we are looking, we create a new set. We get the dependency, and then we added the function to the dependency. Now, what is the function? Well, in JavaScript, there's no API to know in which function you are running into. But since we want this API, we can actually trick it, because a function is just a variable.

So, I can do let current effect is equal to null. And then, here I can do current effect is equal to function. And then, I can invoke the function, and then I can set back to the current effect to null. And this means that when I'm running this function, if I read something, this function will be invoked. And I can check if current effect is defined to know in which function I'm running.

So, I can say if current effect, then I will do this kind of stuff. So, I do this, and obviously, I need to rename function to current effect. And obviously, now, we need to change our code again, because we don't need to return subscribe anymore. We can just return the proxy, which is a much nicer API. But we do need to change a couple of things. We need to change every subscribe that needs to become dollar sign effect. And obviously, we need to remove this.

So, if I save, now, everything should work fine. If I check, and it's working. If I check, it's working. And that's it. No, that's not it. There is a bug yet. Because if I now increase the counter, it's not working. And if I uncheck, and I check again, then it updates. And the reason for this is because inside our effect, we are setting current effect to function, and then we run the function, and then we set current effect back to null. But this means that when we read the value, the second time that this function executes, we don't set current effect before running the function.

This, however, is actually very simple, because we can do function actual effect, and we wrap all this code inside this actual effect. We invoke it the first time. But then current effect becomes actual effect instead of function. So, this means that now, every time we rerun the function, so, in this case, if we increase a dependency, then we check, and now count is a dependency. Because before running the function that update count, we actually update current effect to actual effect.

Not yet. Because if we uncheck, now, we still have a dependency on count. Which is a bit weird, because we are not reading count the second time. The UI is not changing. So, the reason is that we are adding something to the subscriber set, but we never remove something from the subscriber set. However, since every time we run the effect, we explore a branch, we can actually, before running the effect, remove that effect from the dependency of every key that has that effect as a dependency.

It's a bit convoluted, I know. But it's actually very easy to do. We can do depth is equal a new set. So, this is the set of all the set that contains effect as a dependency. And instead of just passing the object, we can pass depth and the function like this. So, now, when we add the dependency, we add the function here, and then we do current effect dot depth dot add depth. So, we are adding this subscriber set to the dependency of this effect. And now, what we can do is, before running it, we can loop over let of depth� sorry. We can do let depth of depth like this. And we can do depth dot delete actual effect. So, we remove this function from every key that has that function as a dependency. We can also clear the set just for good measure.

We can also clear the set just for good measure. And now, if we save, this should work just fine. And if we click here, we are not getting extra running. And when we check back, we don't get a dependency on count anymore. And we can do it. And we can click it and click it and stuff like that.

There's still one bug left. If I do this, state dot value is equal to JS Nation. And if I save, the moment I type something here, I'm� it's frozen. I cannot type anymore. The reason for this is because up until this moment, our effects are synchronous. Which means that by the time you reach this line here, this code here in the effect already run.

Which means that when you set state dot value to JS Nation, this input dot value runs before this state dot value. And so, we set input dot value to JS Nation. And then we set state dot value to the input dot value. To fix this, also because it's very inefficient, like we are basically running the code twice here where we don't need to run the code twice.

We can just implement a very basic batching. Which means that we can do const to run is equal a new� guessed it� a new set. And then we can do function schedule. And inside this schedule, if to run dot size is greater than zero, then we know that we already scheduled something and we can just return. And then we can queue a microtask, which means that it will go to the next microtask. And then we can loop over every function to run and invoke it. And then in the end, we can clear to run. And now we need to update this so that we can schedule every time.

And then instead of immediately calling the function, we just add the function to the queue. And if I save, this is working, this is working. And it works. It's not rerunning code unnecessarily. And that's it.

Now, this obviously, like, it's much more complex in Svelte. So, if you go in Svelte, in the Svelte repo and try to look for this code, there will be no such thing at this code. Because in Svelte, it's much more complex because we need to deal with transition and animations that have their own problems. There is also the write situation that I'm not exploring this. However, like, this is the very barebone implementation of how signals work. So, if you know this, you can pretty much just like figuring out some reactivity problem that you're having. And this is not even just related to Svelte. Like, if you are using a signal based framework, which it's a lot nowadays, with this mental model of how signals work, you can figure out reactivity problem. For example, a lot of people are kind of puzzled by the fact that count is not a dependency initially. Now you know why. Because to get a dependency, you actually need to read that code. Another thing that kind of trips people off is when I do await 42, and if I do async here and I save, this actually stops working. And the reason for this is very simple. If you have an async function, after the first await, this runs in the next microtask, which means that since we are doing this here, we are setting the current effect, we are invoking the function synchronously and then we are setting it back to null. By the time you read the checked and you read count, current effect will actually be already null. So, these are the kind of stuff that trips people off when they are thinking about effect, about signals. And with this very basic mental model, you can now figure out why it's happening, why something is happening.

If you're interested, the code is on github.com. There's the initial code and then the final code. And if you have any question, I'm here for it. Thank you.

How would you store the data? This was early on in your presentation, so think back early in your presentation. How would you store the data if a page reload occurs when using this concept local session storage or using a different store? Yes, you can use local storage in general. This is something that I think a lot of framework co-authors actually advise against, and it's the fact that, like, people very often rely on effects to do this kind of stuff. But very often, it's not needed. Like, effectively, what you can do is, like, if you want to store inside the local storage, for example, you could use an effect to synchronize. And that's actually decent to do. But the very worst thing that you can do is reassign state inside an effect. And so, whenever you do, like, what I would do is probably just create a wrapper around it so that whenever you set the state, instead of doing it in a side effect, in the same line, you can set the state and then also store it in the local storage. So, if you do something like this, like, the code is much more contained. It's much more, how can I say? Like, one line after the other, you can clearly see what you are doing. You are setting the state and storing the value in the local storage. And it's much easier to reason about instead of, oh, if I change this value, an effect in the other side of the project, sorry, the lab that was the other side of the project is changing. Clearly, that was the other side of the project. Cool. Thank you.

Can you describe one of the top complex scenarios that Svelte had to handle in the signals implementation? So, if you're asking about, like, what's the complex part of the signal-based reactivity system of Svelte, I would say that it's the unknown derived. So, the problem with signals is that you generally always have to clean up your memory. So, obviously, I didn't delve into this inside this presentation, but generally, what every signal framework do is create a root effect which is more memory efficient than the normal effect and you store, like, basically, you use that as an entry point so that at the end of the page, that effect is responsible to cleaning up all the effect that you create because otherwise, you would have a bunch of memory, like, just left there. And the problem is, like, in Svelte, for example, as long as you are inside the component, that component can handle the memory of the signals that you create inside it. But in Svelte 5, you can also create signals just in a module and a derived that is created inside a module, it's called an unknown derived because obviously, you are going to use that derived everywhere in your application, so not in a specific component. So, this means that, like, we need to do all sorts of, like, to actually clean up, like, to avoid memory leaks with the unknown derived. So, that's the most complex part of the signal-based implementation. Got it. Thank you. I thought, like, what is the most complex part about implementing anything is, like, working with others and making sure that something happens.

I thought, like, what is the most complex part about implementing anything is, like, working with others and making sure that something happens. Will the implementation be obsolete after the TC39 proposal for signals, if that passes? So, if that implementation is my implementation, yes, probably. The reason is that, like, if the TC39, like, signals come into the web platform, you will basically have this, like, management of dependency and stuff like that built in into the platform. However, that implementation actually doesn't come with an effect. And the reason for this is because, as I've said, effects are very specific to every framework, which means that you will need to implement your own effect to make it really, like, operable with your framework. So, like, you still need to implement the effect part of it, which is simpler maybe. But, so, yeah, this implementation can definitely go away and you can just implement a quick effect. Frameworks, this is one of the things that I'm more skeptical about the TC39 implementation is that a lot of people think that that will unlock cross framework creativity. I don't think that's true because most likely every framework will still need to build on top of that proposal to then integrate correctly with the framework itself. All right. There was another question that was very similar and I just archived it. I felt like it was answered. I hope you'll agree with me and otherwise, you know, you're not on stage. I'm on stage. I make the rules.

So, what prerequisites are there to start working with signals, in your opinion? I don't think there is a prerequisite. Like, I would say that signals, they are getting very popular. But to be fair, they are a bit of a leaky obstruction because, like, if you know how they work, and that's basically the reason why I did this talk, like, if you know how they work, you can work better with them. So, if you have this mental model of, okay, it's just setting, like, storing the function that I'm currently running in inside a set and then doing some, like, rerunning that function when it changes. If you have this mental model, it's very easy to work out why something is not working like you think. But, yeah. I don't think there is a high ceiling, especially in Svelte because in Svelte, well, like, you basically treat them as normal variables. So, while, in for example in solid, which is super cool, but one of the problem of solid is that you have to call a function because if you read a value in JavaScript, that's it. Like, you've read it and you can do anything about it. So, in solid, you always have to call functions to keep the reactivity alive. In Svelte, it's less problematic because we can call the function for you with the compiler.

Is there a solution for the async problem or is this a limitation for signals? The solution is Svelte.

Thank you. Let's see. Is there a solution for the async problem or is this a limitation for signals? The solution is Svelte. No. I know I sound like a broken record. But there is actually a new proposal in Svelte that it's in an experimental branch for the moment that kind of unlocked the ability to use a sync inside a Svelte component. And we are doing a bit of, like, compiler work to make it work. But, yeah, as of today, like, basically there's, like, there's no way to get something after the first await. Another solution that solid was about to implement was, like, just to read all the values initially. So, you basically have a dependency array just like in React. You read every signal and then all the things are passed in a second part of the effect. So, you basically cannot wait everything because, like, the first part, which is synchronous, already read all the values. All right. Thank you so much. I'll defer everyone to the Q&A corner with you if they have any more questions. Thanks again, Paolo, for your time. Thank you. Thank you for your time. Thank you.