Build Your Own Reactivity: A Deep Dive Into Signals

All right. Hello. Hello, everybody. Nice to be here. My name is Karl Vorden and today I'm going to be talking about signals and we are actually going to build one. Before we go into that, maybe a quick show of hands. How many of you have actually used signals yourself? Yeah, pretty many. Yeah. Good. And the rest of you, how many of you have heard about signals? I think that's the rest of you. And maybe those who would interest a hand, they are probably React developers. Just kidding. Just kidding.

Signals are basically a container for a value. Nothing special about that. But with it, the state and UI updates automatically when the value changes. And so this is the part that's the reactivity. And well, why would we want to build this ourselves? Because there's already many implementations. Well, that's mainly for learning purposes. But for you to be able to effectively use it, it's helpful to understand how it works under the hood so that in case you run into any problems, you can easily, more easily, like figure out what's going on.

And at least for me, when I see a piece of technology that's new to me, looks a little bit like a magical. I don't really understand what's happening under the hood. I'm curious to know how it works and really like understand it better. So that's the goal here. So we all see that there's no magic. It's just JavaScript. And well, obviously, it's not the only way to achieve reactivity. React has the virtual DOM where you run the render function again and build a virtual DOM and compare it to the actual DOM. Yeah, it works also.

Yeah, it works also. It achieves reactivity. And in Angular, there's the dirty checking where they keep track of all of the values that they're using in the template and then compare them every time anything happens. Both of those approaches might not be optimal as there's a lot of work you have to do every time. With signals, we get more fine-grained and efficient reactivity because only the code that uses the values that are changed are updated and recalculated without any extra work. Before starting the implementation, we need to identify who uses the value and when the value changes, which are key points for the implementation.

Comparing signals to a plain old variable, the latter lacks the ability to know who uses it or when the value changes. However, in JavaScript, functions provide a solution. Functions can return a contained value and accept a new value, acting as a container. While functions know when they are called, knowing who calls them is an aspect that needs to be addressed. Before delving into the code, it's essential to examine various signal implementations in current frameworks to gain a better understanding.

In frameworks like solid JS, there are implementations like createSignal function, which returns getter and setter functions for values like count. The getter function retrieves the value, while the setter function updates it. This structure might resemble familiar concepts like useEffect in React but operates differently behind the scenes. Exploring these examples before diving into the actual code can provide insights into how signals are utilized in different contexts.

But in JavaScript, we have these magical things called functions. So from a function, we can return a contained value, and we can pass in a new value. So that's the container part. A function knows when it's called. You know, it executes. But does it know who calls it? Well, that's something we need to maybe figure out.

But before we dive into the actual code, let's look at a few small examples of different signals implementations in current frameworks. Here's like solid JS signals. You see there's the createSignal function, which returns two functions, count in this case, and setCount. The first one is the getter function. You call it, and you get the value. Then the second one is the setter function. You can call it to give a new value.

And for all of the React developers, it might look a bit familiar to useEffect and stuff like that, but it works totally differently under the hood. In the snippet below, you can see how you can use it in the template. In Angular, we have a function called signal to create one, and it only returns one thing, which is kind of like a function. You can call it to get the value, but it's also kind of like an object because it has a dot set method where you can set the new value. So a little bit of an unconventional approach, in my opinion, but, yeah, it works.

Then in Vue, the signals are called refs, and you create one with the ref function, and what you get back is an object. The object has a dot value that looks like it's a property, but actually under the hood it's implemented with a getter function and a setter function. So it's, again, two function calls, even though it doesn't look like that in here. You can just do the plus plus, and actually what happens is two function calls. In the template, you don't have to put the value, but that's because Vue parses it and handles it for you.

Then there's also in Svelte, for example, the signal implementation is called runes, but we don't have time to go into that much. Okay. So let's start building something. I'm going to have to go quite fast because the time limit is 20 minutes, so I hope you can follow along and I'll try to explain. So first we will begin by defining the function signal, which acts as the container for the value. We will return an object that has a getter method and a setter method for the value. So in this case, we are going to do it kind of like a little bit of Vue.js way of using the getter and setter methods. But at this point, what we have is not that exciting yet. It's basically like a variable that we can instantiate, and then we can change the value. And if we console.log like this, and if we then execute, yeah, it's not that exciting.

But earlier when I said that the function knows when it's called, it's nothing that exciting, just that we can execute code here. That's basically what I mean. We can execute code here so we can see the get and set methods get called when the value is used inside the function. Now, if you remember back from the slide, there were two points. So the first one was to know when a value changes, sorry, know who uses the value. So to get started with that, here in the getter method, we need to track who uses the value. So for that we will implement a track function, which will take a signal as a parameter. And then we need a place to store somehow the usage. So let's define a usage as we will use a WeakMap for this. And the reason we are using WeakMap is that instead of like a normal just object, we can use the signal object itself as the key. So we can check if there is already something in there. And if not, then we can set it as an empty array. And then going on, we will get, and then we have the array and we will put something in the array. But what should we put there? Okay. Now, the goal here is that we can get rid of the second console log.

And we would make only define console log once and it would get executed anytime a value changes. And for that we need a second part of the signal implementations, which is a function called effect. And it takes a callable function as a parameter, which it then executes. And then we could define our console log as a reactive, so to speak. So how to make this work?

Now, as we can see here, the value is now red inside of the effect function. And this effect function is also what we want to execute again later. So we need to keep track of what happens during the execution of the effect. So we can define a current effect, which we will assign the callable function before we execute it. And after we execute it, we clear it away. And this is what we will put in the usages, but only if there is one.

Okay. I like this. Now, the second part, number two, was to know when the value changes. And that happens in the setter function here. And so instead of console logging, we will execute. And let's define an execute function. Takes a signal. And then we will get from the usages of this signal, which might not be there, so we'll play it safe. And it is an array of the callables, which we will then execute. You think?

Just to see, let's put a few more here. It's a reactive signal. Normally, our state doesn't consist only of simple single values, like numbers and strings. We need ways to combine them and do calculations. Let's introduce the third part of the common signal implementation, which is computed. With computed, we can define a function to handle more complex operations. We can use computed within effects to create a reactive flow.

To summarize, a test signal is defined, a computed value is created using the signal, and an effect is defined utilizing the computed value. Value changes trigger the recalculations of the computed, which then re-executes the effect. This sequence ensures the reactive behavior of the system. Pitfalls may arise with conditionals inside effects, potentially leading to unexecuted signals, affecting the system's awareness of signal changes.

Understanding the signal implementation, we can anticipate potential challenges such as conditional statements impacting signal execution. The interplay of signals, effects, and computed values forms the core of reactivity in the system. By recognizing these intricacies, we can optimize signal handling and ensure the proper execution of reactive behaviors.

But to make it reactive, we will also wrap it in an effect like this. And now everything is working like this. So we... Thank you. Thank you.

So to quickly recap, we define a test signal, create a computed using the signal, and define an effect utilizing the computed. Every time a value changes, the computed recalculates and triggers the effect again, resulting in the observed outcome.

We defined a signal as a value container, an effect to track signals during function execution, and signal updates triggering effect re-execution. Potential pitfalls include conditionals affecting signal execution, async operations delaying signal tracking, and destructuring causing issues by removing the value from the container.

We defined an effect that tracks signals during function execution, triggering re-execution. The computed is a syntax sugar for a signal calculated from the effect. Potential pitfalls include conditionals affecting signal execution, async operations delaying tracking, and issues with destructuring values from containers.

If conditionals like if and switch statements are used inside effects, signals may not execute, causing undetected issues. Async operations with promises or callbacks delay function execution, leading to tracking problems. Destructuring values from containers can render them ineffective, especially with reactive objects in frameworks like Vue.

Console logging for demonstration may lack excitement, prompting a demo using raw HTML and vanilla JavaScript with no frameworks. Despite the simplicity, the speaker assures their expertise. The demonstration imports the signal implementation previously discussed for practical illustration.

If we had code inside of the effect that uses promises or callbacks or timeouts or something like that, then the functions we passed into those, they will not be executed until later. And if you remember, the current effect is only assigned during the execution of the callable function. So again, they are not going to be tracked. So these type of situations can cause hard-to-debug problems because nothing happens and you think something should happen. But when you know how it works under the hood, then you can easier try to reason about what's happening.

And finally, destructuring. So basically, if you take the value out of the container, then it doesn't work anymore. This is more common maybe with reactive objects than signals because signals only hold one value, so it's not that common to take it out. But for example, in Vue, there's a reactive object that hooks into the same reactivity system. And with objects that have many properties, it's more common to use destructuring to take out only something you need. But if you then use it in an effect, it's not working because it's out of the container.

Okay. Now that we have maybe a few minutes of time, using just console logging is not that exciting, so let's do another demo. So just to give you a little heads up, this demonstration is going to have raw HTML, vanilla JavaScript, no framework, no bundling, no build stuff, nothing. But don't worry. I'm a trained professional. I can handle it. Okay. I have this little HTML snippet here. And... It imports this signal implementation that we just now did. Gives a few errors. Now we have to just make the exports here for the three functions that we use. All of the rest is internals. Only export these three. And what we will do is... Let's make a calculator, if I can type. Okay. This is a little bit too big, I think. Okay.

So for this we need a few signals. We will call them value one, value two, and operation. And I have prepared a little snippet of HTML here. We have a number input field and then a drop down for the operations and another input field. And these are updating the signals here.

And to start our implementation, let's define a result as computed. And first, just to check that our signals are working, let's console log them out real quick. Like this. And then we can see, okay, yeah, seems to be working. Let's continue to use a switch on the operation.

And then have a few cases. Return value one plus value two. And then do this four times for all of our different operations. Next, if we were building some framework, we would then just type something like this and it would magically work. But in this case, we have to do what the frameworks actually do when they parse your template and they encounter code like that. They will create an effect.

They will create an effect. And inside the effect, they will write code that updates the DOM. So we will go directly to the inner HTML. We put an equal sign and then result value or maybe empty. Okay. Now, let's see. Twelve times four. Okay. Now, any time I change this value or this value or the operation, it updates automatically.

And, well, one question. If we do a plus, anyone know what is 13 plus 5? 135. You know why? Yes, you do, because this is JSConf. Yeah. Okay. So that was it. I'm Karl Vorden and I'm on BlueSky and on GitHub. There's the slides and demos on my GitHub if you want to take a look. Yeah. Thank you.

Thank you, Karl. The first one is pretty much, is the underlying implementation similar to what MobX does? Yeah, I think a little bit. MobX uses their proxy objects, but it's a little bit similar. Is there a benefit to using a proxy object over getter and setters? Well, it's just that the object can have many properties instead of just one or predefined ones. Yeah. Fair enough. Fair enough. All right. I don't know what happened there. I think I checked off a question before I answered it. The next question is, what is the difference between a signal and a proxy? Well, I think the signal is more like the reactivity.

So, it's not just – you can implement something like signals with the proxies, but it also needs the effect part to make something happen. So, as I said already, in the talk, Vue.js has the reactive object concept that also hooks into the same reactivity. So, in Vue, those are implemented with proxies. And then there are other things you can do with proxies that aren't reactivity. Yeah. So, it can be used. Yeah. Proxies are always one of those – for me, they're always like that thing that goes into frameworks. You don't really use them yourself. Yeah. Touch those proxies.

And one thing I forgot to say during the talk, that this implementation, obviously, it's a pretty naive one. There's lots of room for improvement. And so, the real implementation is obviously a little bit longer. More efficient. If we could build full-on implementations in just 20 minutes, then we would have built ourselves out of a job by now. Yeah. Excellent.

Somebody asked – well, somebody said it was a great way to learn. I also like live coding as a way to see something. Also, I encourage you to maybe try to build your own and learn more. Absolutely. But the question was – Build a better one. Build a better one, yeah. The question was, have you seen Evan you do a demo like this at all? No, I haven't. Maybe something else to check out afterwards. Also, if you enjoy live coding of signals implementation, you only need to go downstairs because I learned yesterday that Paula, whose talk is next downstairs, is doing exactly the same thing. Nice. I thought that'd be really interesting.

I thought that'd be really interesting. But it's a little bit SWELT-specific. So, if you're into SWELT, go downstairs. It'll be a slightly different take on the SWELT thing. It actually gives you a good rounded view of the whole thing, I think, which is kind of cool, yeah.

Do you have a favorite signals framework? Mostly, I've been using Vue, so maybe that. But I don't know. Are they all pluses and minuses? Yeah. Cons? Yeah. Because signals have been a proposal for JavaScript. Is that still going through? But even if it goes through, it's not something you would use in your code. It's more for the framework developers to build on top because it still needs the framework-specific thing to tie the reactivity into the framework. Got it, got it.

I guess once that makes it through, it will be easier for those framework developers to do so. It would be more efficient if the system hooks into C code and stuff like that. Nice. All right. Okay, so a React question on this. What's the – or do you know what the biggest advantages for React to use Shadow DOM and their version of – it's not really reactivity, I suppose, as opposed to signals like you've shown? Not a React expert. I think the whole concept of how they've built the framework, it would not be easy for them to use signals, I think. Yeah, it breaks the whole React, like, the UI as a function of states thing, right? Because the state changes without – and hooks different parts of it individually rather than doing the whole tree. Different way of looking at it totally.

Different way of looking at it totally. So we're unlikely to see React kind of really lean into signals. Although React does have signals, so I don't know what they are doing. Have to investigate that maybe, I guess, yeah.

Is this pattern useful on top of frameworks? Are there any examples you can give on that? On top of frameworks, I think – well, you could even use a standalone signals library for something that if you need some reactivity in your own business logic stuff. But if you use a specific framework, then the reactivity should be hooked into the framework somehow to make the UI reactive. Maybe if you want to use it only for business logic things. Yeah, fair enough. You need that framework interaction to actually properly get the benefits of it. Yeah.

One more question. Do you know why this pattern is called a signal? No. No idea. It's not a new concept. It's pretty old, actually. All right. Well, I'm going to stop the questions there. But there is more opportunity – another glass gone – there is more opportunity to ask our questions about this down at the Q&A on the first floor. So go catch them there. But otherwise, give them a massive round of applause for an incredible live coding performance. Thank you.