Exploring Reactivity: Part 1

I used to take reactivity for granted. The first JavaScript framework I picked up was Vue. It was an easy framework to start with. I learned that keeping things reactive is a common and important part of writing frontend code, and that I should use ref and computed ¹. It’s quite easy to point my fingers and say this variable is reactive and that one isn’t, solely based on the usage of ref and computed as a signal.

Yet, I don’t grow my roots in Vue land forever. Every now and then at my job, I need to touch React. It happens much more often recently. This sparked my curiosity to figure out how these frameworks work. It’s not like they are built from Rust™ or a true reactive programming language, they are just plain JavaScript. How can things react to changes in other things? That’s what I will explore in this two-part series.

Why do we need reactivity?#

Let’s take a look at an infamous counter example ²:

let count = 0

const isEven = () => count % 2 === 0
const parity = () => isEven() ? 'even' : 'odd'

const render = () => element.innerText = parity()

const setCount = (value) => {
  count = value
  render()
}

input.addEventListener('input', (e) => setCount(parseInt(e.target.value)))

This code renders the even or odd text to an element based on the state count, which is updated from an input element. It’s very nice and clean code (if I were to write it myself, everything would’ve been in the input event handler 😛). However, there are a few problems:

• We render whenever we setCount. That is because it’s the only signal we know that something might change, therefore we need to act. This couples count with rendering.
• When we render, there’s a recomputation of parity if isEven hasn’t changed. We can’t opt out of it since everything is pure function calls.
• If we want to render isEven or parity in other parts of our UI, we need to manually instruct render to do so.

The problem is writing vanilla JavaScript to update UI is very imperative. The great minds in our time recognized this problem and then reactivity emerged.

What even is reactivity?#

It’s beyond my expertise to fully explain this concept. I highly encourage you to read this article: What is Reactivity?

In essence, the main takeaway is that reactivity helps us write declarative code that updates UI based on state changes. It allows us to achieve a simple model for building UI:

view = render(state)

Every UI (view) is a declarative representation of some state.

How were JavaScript frameworks invented to solve reactivity?#

React#

Here’s the same counter example written in React:

const Counter = () => {
  const [count, setCount] = useState(0)
  const isEven = useMemo(() => count % 2 === 0, [count])
  const parity = useMemo(() => isEven ? 'even' : 'odd', [isEven])

  return (
    <div>
      <input
        type="number"
        value={count}
        onChange={(e) => setCount(parseInt(e.target.value))}
      />
      <p>{parity}</p>
    </div>
  )
}

The first thing we notice is the clear separation between the state and the view. A React component is a function that renders the state (in the function body) into the view (the returned HTML). This maps perfectly with our view = render(state) model.

This declarative approach, along with its component-based architecture gave React so much love and adoption. That said, being early to the game, some of React’s design choices became a burden to its users later, especially the reactivity model.

Reactivity in React is at the component level. Every time there’s a state change, it’ll rerender the component to produce a snapshot, and compare it with the previous snapshot. Only the diffs between the two snapshots will be updated to the DOM.

While React’s diffing algorithm successfully prevents most unnecessary DOM updates, the performance cost of running these comparisons can lead to slower applications if developers don’t implement proper optimization techniques like using useMemo, useCallback, or React.memo.

This created an opportunity for frameworks built on a different concept to form.

Signal-based frameworks#

The term “signals” was popularized by Solid.js but its history goes way back. And Solid isn’t the only framework using signals — Vue, my beloved framework, and a bunch of others all align on this concept to back their reactivity model ³. It’s also referred to as fine-grained reactivity.

To me:

Signals are reactivity at the state level.

Let me explain with an example:

<script setup>
import { ref, computed } from 'vue'

const count = ref(0)
const isEven = computed(() => count.value % 2 === 0)
const parity = computed(() => isEven.value ? 'even' : 'odd')
</script>

<template>
  <div>
    <input type="number" v-model="count" />
    <p>{{ parity }}</p>
  </div>
</template>

This Vue component does the exact same thing as the React component above. The state - view seperation is still clear: we have the state in the <script setup> tag and the view in the <template> tag. Nevertheless, several key differences stand out:

• Only values created from ref or computed are reactive. These are signals. Any signal referencing another signal is kept reactive. For example, isEven references count so it’s kept up-to-date whenever the value of count changes.
• The template (view) is kept reactive to any state being referenced, meaning it is automatically rerendered when the state changes. Furthermore, this reactivity is fine-grained — for example, Vue knows the <p> tag depends on parity and can update the <p> tag directly when parity changes. There’s no need for a snapshot diffing process (although Vue still uses diffing for some types of updates).
• The dependencies of a reactive signal is tracked automatically. computed is a signal type that caches its value to prevent unnecessary computation when none of its dependencies change. In React, the similar concept is useMemo and we need to provide a dependency array to allow it to work correctly.

What’s so great about this is less cognitive overhead for developers. We often think in terms of state, so having a non-redundant syntax to declare reactive state makes much more sense. And since signals are fine-grained reactivity, the framework is by default as performant as it can be, unlike in React where we have to remember to use useCallback, useMemo, React.memo, etc.

Closing Part 1#

Having written Vue for years at this point, there was rarely any case that I needed to dig deep into how the framework works. But a few months of React already inspired me to learn about the core fundamentals of reactivity because React very often gets in the way.

Personal rant aside, this concludes the first part of my reactivity exploration journey. In the next part, we’ll try to build a signal-based reactivity model from scratch to have a deeper look into the magic of these frameworks.