Reactivity with SolidJS

Reactivity Overview

Ryan Carniato

Ryan Carniato

SolidJS Creator
Reactivity with SolidJS

Check out a free preview of the full Reactivity with SolidJS course

The "Reactivity Overview" Lesson is part of the full, Reactivity with SolidJS course featured in this preview video. Here's what you'd learn in this lesson:

Ryan describes reactivity as the ability to declaratively express the relationship between values that change over time. It consists of an observable state which notifies any derived values. When these values change a side effect like a render is triggered.


Transcript from the "Reactivity Overview" Lesson

>> Our journey today starts with reactivity. And that's really the update core for pretty much any UI framework. And in the case of SolidJS is actually the single kind of driving force. Understanding reactivity is really understanding SolidJS. So that's why we start here. So what is reactive programming?

It's actually a lot of different things to a lot of different people. Not to mention, it's become kind of a buzzword for the last couple years. It is actually a bit tricky to nail down, which is why I love this comic. Because I think it's fair to say that there's a lot of confusion with the topic and it's sometimes because it's in some ways simple hard to explain.

Honestly, I've been trying to explain this to people for years and I still have a hard time. So here we are and the problem is looking at the answer doesn't really help. I mean, there's a lot of text not to worry about it too much. But if you go to Wikipedia, and it's like in computing reactive programming is a declarative programming paradigm concerned with data streams and propagation of change.

With this paradigm, it is possible expressed static or dynamic data streams with ease and also. I'm sorry, this for me at least this doesn't say anything to me. And you keep on looking around a bit more and you're like, okay? Stack Overflow, well, this like don't worry about the blob of text.

But if someone goes and gives you a full history of functional reactive programming in academia and talks about various papers that as historical markers. There's also something called the reactive manifesto, which probably might sound good to your boss. It's about how to make systems that are reactive from like a development planning perspective.

There's also reactivity used for responsive design. The word kinda doesn't mean anything anymore. I'm gonna try and focus on the programming paradigm, and more specifically the programming paradigm that you find commonly in the UI frameworks. This is just as I said, it's very hard to find a specific answer.

So I tried to come up with my own, it is not perfect. But this is the best I've come with so far. This is probably too generic, it's not amazing. But it's kind of hard to define such loosely defined terms. So for me reactivity is to declaratively express the relationship between values that change over time.

What do I mean by that? See the problem with this definition is I still need an explanation. The way I think about it is like a system of live equations. See like a normal assignment represents like a single point of time, you say that after this happens a reflects the sum of b plus c.

But if b or c change, then you do another assignment. This is just kind of standard algebra, so to speak. This relationship does not hold. But reactive programming is a programming paradigm around modeling your system based on rules so that this does hold. So that at any point in the future if b or c updates, a is also updated and you've seen this all before in application.

The spreadsheet is probably the most common one that kind of helps people think about it like if you have equations in cells. You update one cell, it immediately updates in the other location. In JavaScript, reactivity is kinda come out in two forms primarily. And it's Interesting both of these kinda came out of Microsoft in the mid 2000s.

Basically, there's the first type here that I'm gonna mention, which is what we're gonna focus on today, which I call fine-grained signals. It's a simple event emitters that hold a value that represent that value over time. The key part to take away here is that it's about a primitive that owns the value.

You can think of it as a variable or as a value. The other one, Reactive Streams or Rx, which in a lot of circles are more popular. If you've heard of RxJS or RxJava is a series a collection of data events that are emitted over time. There's a lot of overlap between these concepts and between these approaches.

But because they're kinda set up to solve different problems, I'm only really gonna focus on the first one today. The second one is better for async transformations, values that change over time and that's why we see a lot on the server. The first one is about synchronization. And synchronization is very important for UI frameworks.

And this is why we like fine-grained reactive programming. First of all, it's declarative. I mean, most reactive programming is. That means relationships are set once and then executed. You can describe the behavior rather than the implementation. It's also composable. It's easy to kinda build higher level behaviors, wrap them and modularize them.

But the main reason that I like fine-grained reactivity is because of the language aspect of it. There's really only three concepts you need to know. You need to know about signals, which are this observable state that updates. You need to know about derivations, which are these computed values and then you need to know about side effects.

That's like when you console.log something or render something. It's very convenient, if you've ever used or seen something like RxJS, which has a different purpose. There's like over 50 or 70 different operators to interact with this. What's really nice about reactivity, is you can basically just write normal looking expressions.

And that's what we're gonna look at here because this is not new. Some of this might even sound familiar and you might have seen in some other frameworks. I'm gonna show a few examples of it in different frameworks. So you can get some familiarity here, see if kinda it ties it all together for you.

I just wanna emphasize how widespread these ideas are, especially from a language perspective. So I mentioned this one before, my old favorite KnockoutJS, back in 2010, kind of introduced this kind of reactivity. And it has different names, they called their primitives observables and computed and pure computed. And this is lovely like ES5 style JavaScript with this.

You can kinda see that it had this kind of idea of like having like first name and last name and full name, all being kind of built from basically a special data type. Move forward a few years and we see reactivity make a bit of a comeback in React around 2015, with MobX.

This time they took a slightly different approach. They still call their stuff observable, but now there is a decorators doing it. So they said that hey, this component is the observer or in our case our side effect. And then they annotated different variables to say that hey this is React like seconds past here is an observable.

Svelte 2019, four years later, they did a very minimalist syntax. What we see here is in fact their let variable is actually very special. It's not a normal JavaScript let, it's actually a signal or a reactive variable under the hood. And they use $ signs to indicate that these are derived or computed values and continuing this trend Vue Composition.

They use things like ref and reactive to define these variables. And this is what I would focus on here. These frameworks are actually still based on based around these three language features that I'm talking about. They have other APIs you can look at it, but you're gonna find in all of them you're gonna find a reactive atom or that signal, that state.

You're gonna find a derived value and you're gonna find effects. It's all the same kind of language and I've got one more example for you kind of think about. React has those three primitives too, useState, useMemo, useEffect. So I often like posing this question is React reactive, is even been some discussion acknowledgement from the core team in the past that React isn't like purely a reactive system.

But this is a pretty nuanced discussion. And in my opinion, React has every right to claim to being as reactive as something like Svelte. Both on their data change or their primitives, they actually trigger an invalidation that causes a component to rerun. Some people might get hung up on the fact that, in some frameworks it's magical.

You just use an assignment, other ones you call set state. But mechanically, we're talking about these same language. So while I'm gonna admit that React is not like the reactivity that we're gonna be covering today mechanically, we are seeing this sort of convergence on the language of user interfaces, which I think is very interesting.

And something kinda keep in the back of your mind as we continue through this session.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now