Why React Should Not Adopt Signals

Hello everyone from Dresden in Germany. I hope you're having an awesome conference so far. I only have 10 minutes, so let's jump right into the topic.

Today I want to talk about why, in my opinion, React should not adopt signals. To get into this, we first have to discuss the elephant in the room, the signal. What exactly is a signal? As you can see here, a signal is created with a function or a constructor with a new signal or whatever. You get a container back, and this container has usually two functions, one for setting the value and one for retrieving the value. That means that it's a static container that you define once and then you can continue reading and writing values from this one static container. You always have a function for writing and for reading the value, whether that's a direct function call or if it's just accessing a property that has a getter function behind the scenes. Of course, the syntax varies between frameworks. Frameworks like Solid, Angular or Vue.js all use something like signals under the hood with varying syntax. In the end, it's always the same, a static container with two functions, one to set and one to get to retrieve the value. If that's a set of property or a getter, it doesn't matter in the end, it's function calls.

Now, the question is why should we want to adopt signals in something like React? We already have states. The first benefit is that we would be able to automatically track dependencies for effects or for memos. Here, as you can see, this is the Solid.js syntax, but it looks very similar to React, so we can just take a look at it. You can see that we are creating the signal in the first line and then we are using an effect to always lock the number whenever the number changes. Additionally, we have this double number where we have a memo, where you just access the number, you call the function to retrieve the value and multiply it by two. By calling the function, the dependencies can be registered automatically. Whenever the number changes, it's totally clear that the effect needs to rerun and our memo needs to rerun. This works automatically without us having to specify the dependencies as in React currently. This can also lead to more efficient component rendering. If you take a look at this example, we have a top component, a mid component and the bottom component. Top renders mid, renders bottom. As you can see at the top, we are defining and creating the signal, a static container. We are passing it to the mid component and this just takes this container and forwards it to the bottom component, where the value is used. As you can see in the mid component, the signal is never read. It's just forwarded to someone else. Now if you could imagine a future where the framework would just rerender the components where the signal is actually read, we don't need stuff like React.Memo or a shouldComponentUpdate or something like that. We could just always update those components that read a signal only if the signal changes.

This would not really change anything about our mental model, because it still could rerun the whole component, but it could automatically track which component needs updates without having to render all the way from the top to the bottom.

If we take a look at this last example, the bottom component, and maybe if we make this a bit more complicated, then we can see an even more interesting fact. Here we create another signal and we are logging the signal and then we are reading the props, the number in the JSX. But we are only accessing the signal in this small part of the JSX, in this curly braces. It should also be possible to only update this specific part in the Rome, because nobody else in the whole application is even reading the signal. This then leads to the holy grail, fine-grained reactivity across component boundaries.

Whenever we update a signal, only those specific parts that read the signal, doesn't matter if it's an effect, a memo or a part in the JSX, only those components that really consume the signal should get updated whenever the signal changes.

In this way you could get huge performance benefits, because you're not doing any work, you don't have to diff anything for changes, because you already know which places in the application need to be updated. Of course this has a cost. Frameworks like Solid or Angular and Vue with this upcoming VaporMode already try to achieve this, but of course it has downsides.

First of all in React if you would adopt signals in React we have to migrate to the single execution components. You no longer have this guarantee that a component will read run, the function will no longer rerun whenever something changes, but only those specific parts in the application changes. This has of course massive implications for what you can and what you can not do in the body of a component. It will be very interesting to see how this transition pans out in something like Angular or Vue, but we can already take a look at the end result in Solid.js that started with signals from the get-go.

Additionally I added this single execution components in quotes, because it's not really single execution. Yes, the outer component, the outer function, only runs once to create all the effects, create all the signals, wire everything together, but then you have within your component all those different places that update at various points in time. For example, here we have three places, the two effects and the place in the JSX, and all of those places have to rerun at certain points in time. Even if you have this model of only creating your components once initially, certain parts of it will rerun again and again depending on the signals that are read in those specific scopes. This can get very complicated very quickly if you have complex components that read from different signals.

In the React world, on the other hand, you can just slap a console lock somewhere, because you know for a fact when the first line of the component runs because something rerendered, then the last line of the component also has to rerun. This gets this problem that certain places run out of order and at various points in time get more complicated the more signals you're using in the application. Additionally, let's imagine we have an even more complex component and maybe another developer came along and now we start mixing the different properties. So A, B, and C are accessors as it's called in Solid to retrieve the value or could also be directly signals. We have the value D, which is just a number, a plain number that will never change. All of a sudden, we have to juggle those two worlds of containers that contain changing values and values themselves that now no longer can update, because in the end we migrated to the single execution component, so it only runs once from the top to bottom.

Everything that isn't a signal will not update and cannot update. Now we are in this world where when you write a component some properties are allowed to change while others, the property D, are not allowed to change or changes would just be ignored. Of course, in something like Solid the compiler works around this a bit so that all properties that are passed to a component are automatically wrapped so that all properties can change. However, you still have the same problem when writing something like custom hooks or the equivalent of custom hooks, because there you still need to manually explicitly specify what arguments can change and what arguments cannot change. The React world on the other hand assumes that everything can change. Every argument and every property of your function can change, and it forces us with linters, compilers etc. It forces us to always hold up this assumption so someone that is using a component they don't have to look inside of the component, because they can safely assume whatever property they change the component will update accordingly and it will still work.

This leads in the React land to more robust code that you have to update less, because in Solid when you write a hook you start out with only one argument being a signal and then sooner or later you realize that a second argument also needs to change in some other use case. You start refactoring the code, adjusting that all arguments are signals, then you have to refactor all the old use cases and the old call places. This then all leads to this mess of having to think about and actually having to explicitly decide which arguments can be signals and which arguments should just be plain values. In React world everything is a plain value and everything can change. Yes the downside is that within our custom hooks, within our components right now we manually have to specify dependencies, the linter screams at us, we have to always memorize functions for example so that it doesn't lose identity and they don't change. However with something like the upcoming compiler this may get better in the future.

To summarize React forces us to assume that everything can change in our application and in turn we get to work with plain values, can just take any arbitrary value, a number, a data type, an object, a plain object, whatever and we can pass those around and everything will still work as long as we have these plain values and follow the assumptions of React. If you now still want to have signals in React or if you have performance issues in your application and you hope that signals can solve those or if you're just interested in real world experiences from a real world signal-based project then let's chat! Contact me via Twitter, via email or on Discord. I'm available there as well and I hope you learned something today and have some interesting questions for me. Have fun in the conference and talk to you later!