@zeix/ui-element

<!doctype html> <html lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Rethinking Reactivity – UIElement Docs</title> <meta name="description" content="Reactivity ensures that your user interface stays up to date automatically. It simplifies the code when we need multiple inputs, derived values, and complex state relationships." /> <link rel="stylesheet" href="../assets/main.css" /> <script type="module" src="../assets/main.js"></script> </head> <body class="blog"> <context-router> <header class="content-grid"> <h1 class="content"> UIElement Docs Version 0.13.3 </h1> <section-menu> <nav> <h2 class="visually-hidden">Main Menu</h2> <ol> <li> <a href="../index.html"> 📖 Introduction Overview and key benefits of UIElement </a> </li> <li> <a href="../getting-started.html"> 🚀 Getting Started Installation, setup, and first steps </a> </li> <li> <a href="../components.html"> 🏗️ Components Anatomy, lifecycle, signals, effects </a> </li> <li> <a href="../styling.html"> 🎨 Styling Scoped styles, CSS custom properties </a> </li> <li> <a href="../data-flow.html"> 🔄 Data Flow Passing state, events, context </a> </li> <li> <a href="../examples.html"> 🍽️ Examples Common use cases and demos </a> </li> <li> <a href="../blog.html"> 📜 Blog Latest articles and updates </a> </li> <li> <a href="../api.html"> 📚 API Reference Functions, types, and constants </a> </li> <li> <a href="../about.html"> 🤝 About License, versioning, getting involved </a> </li> </ol> </nav> </section-menu> <card-callout class="content danger" hidden> </card-callout> </header> <main class="content-grid"><section-hero> <h1 id="rethinking-reactivity"> <a name="rethinking-reactivity" class="anchor" href="#rethinking-reactivity"> 🔗 </a> Rethinking Reactivity </h1> <div> In our previous post, we saw how components help organize frontend code into manageable, encapsulated pieces. But what happens when we need multiple inputs, derived values, and complex state relationships? <module-toc> <nav> <h2>In this Page</h2> <ol> <li><a href="#what-is-reactivity-and-why-should-you-care">What Is Reactivity, and Why Should You Care?</a></li> <li><a href="#frameworks-to-the-rescue">Frameworks to the Rescue</a></li> <li><a href="#reactivity-without-a-framework">Reactivity Without a Framework</a></li> <li><a href="#signals-are-going-native">Signals Are Going Native</a></li> <li><a href="#a-thin-layer-you-can-use-today">A Thin Layer You Can Use Today</a></li> </ol> </nav> </module-toc> </div> </section-hero> <section> <h2 id="what-is-reactivity-and-why-should-you-care"> <a name="what-is-reactivity-and-why-should-you-care" class="anchor" href="#what-is-reactivity-and-why-should-you-care"> 🔗 </a> What Is Reactivity, and Why Should You Care? </h2> At its core, reactivity is a programming model where the system keeps your user interface up to date automatically. You declare what should happen when state changes, and the system ensures that it does – consistently and efficiently. Compared to imperative code, reactivity offers a few key benefits: <ul> <li>Declarative logic: You describe relationships between state and output, not the steps to manually keep them in sync.</li> <li>Consistency: The system ensures derived values are always up to date.</li> <li>Less wiring: You don't need to write handlers for every possible source of change.</li> </ul> Let's illustrate this with a simple example. We have: <ul> <li>Two input fields: First name and Last name.</li> <li>A checkbox: Use full name name as display name.</li> <li>Two derived values:<ul> <li><code>displayName</code>: first name or full name depending on checkbox.</li> <li><code>userName</code>: first initial + last name, lowercased.</li> </ul> </li> <li>Two <code></code> elements that display these values.</li> </ul> <module-codeblock collapsed language="html" copy-success="Copied!" copy-error="Error trying to copy to clipboard!"> html <pre class="shiki monokai" style="background-color:#272822;color:#F8F8F2" tabindex="0"><code><greeting-config> <label> First name <input name="first" type="text" /> </label> <label> Last name <input name="last" type="text" /> </label> <label> <input name="full" type="checkbox" /> Use full name as display name </label> <p>Display name: <span class="display-name"></span></p> <p>User name: <span class="user-name"></span></p> </greeting-config> </code></pre> <basic-button class="copy"> <button type="button" class="secondary small"> Copy </button> </basic-button> <button type="button" class="overlay">Expand</button> </module-codeblock> Now try writing a Web Component that keeps all of that in sync manually. You'll need: <ul> <li>Change event listeners on both fields.</li> <li>A change listener on the checkbox.</li> <li>A <code>#updateDisplay()</code> method that gets called from every handler.</li> <li>Manual DOM updates.</li> <li>Guards against inconsistent state during updates.</li> </ul> It gets surprisingly tricky – even though the logic is simple. <module-codeblock collapsed language="js" copy-success="Copied!" copy-error="Error trying to copy to clipboard!"> js <pre class="shiki monokai" style="background-color:#272822;color:#F8F8F2" tabindex="0"><code>class GreetingConfig extends HTMLElement { #first = '' #last = '' #full = false connectedCallback() { this.querySelector('input[name="first"]').addEventListener('change', e => { this.#first = e.target.value this.#updateDisplay() }) this.querySelector('input[name="last"]').addEventListener('change', e => { this.#last = e.target.value this.#updateDisplay() }) this.querySelector('input[name="full"]').addEventListener('change', e => { this.#full = e.target.checked this.#updateDisplay() }) } #updateDisplay() { const displayName = this.#full ? `${this.#first} ${this.#last}` : this.#first const userName = `${this.#first[0] ?? ''}${this.#last}`.toLowerCase() const displayNameEl = this.querySelector('.display-name') if (displayNameEl) displayNameEl.textContent = displayName const userNameEl = this.querySelector('.user-name') if (userNameEl) userNameEl.textContent = userName } } customElements.define('greeting-config', GreetingConfig) </code></pre> <basic-button class="copy"> <button type="button" class="secondary small"> Copy </button> </basic-button> <button type="button" class="overlay">Expand</button> </module-codeblock> This imperative approach works, but notice the problems: <ul> <li>Repetitive event handling: Every input needs its own listener</li> <li>Manual DOM updates: We have to remember to update the display everywhere</li> <li>Coarse-grained updates: <code>#updateDisplay()</code> recalculates everything, even when avoidable</li> <li>State synchronization bugs: It's easy to forget to call <code>#updateDisplay()</code> somewhere</li> </ul> As components grow, these issues compound. This is exactly the problem reactivity solves. </section> <section> <h2 id="frameworks-to-the-rescue"> <a name="frameworks-to-the-rescue" class="anchor" href="#frameworks-to-the-rescue"> 🔗 </a> Frameworks to the Rescue </h2> Now that we've seen the manual approach, let's look at how frameworks address this. Frameworks like React and Vue were invented to solve this very problem. In both, you can express derived values directly: <ul> <li>React uses <code>useState()</code> and <code>useMemo()</code>.</li> <li>Vue uses <code>ref()</code> and <code>computed()</code>.</li> </ul> Their underlying reactivity systems track dependencies, re-run derivations, and update the DOM efficiently. Here's what the example looks like in React or Vue: <module-codeblock collapsed language="js" copy-success="Copied!" copy-error="Error trying to copy to clipboard!"> js <pre class="shiki monokai" style="background-color:#272822;color:#F8F8F2" tabindex="0"><code>// React component import React, { useState, useMemo } from 'react' function GreetingConfig() { const [first, setFirst] = useState('') const [last, setLast] = useState('') const [full, setFull] = useState(false) const displayName = useMemo(() => { return full ? `${first} ${last}` : first }, [first, last, full]) const userName = useMemo(() => { return `${first[0] ?? ''}${last}`.toLowerCase() }, [first, last]) return ( <div> <label> First name <input type="text" value={first} onChange={e => setFirst(e.target.value)} /> </label> <label> Last name <input type="text" value={last} onChange={e => setLast(e.target.value)} /> </label> <label> <input type="checkbox" checked={full} onChange={e => setFull(e.target.checked)} /> Use full name as display name </label> <p> Display name: <span>{displayName}</span> </p> <p> User name: <span>{userName}</span> </p> </div> ) } </code></pre> <basic-button class="copy"> <button type="button" class="secondary small"> Copy </button> </basic-button> <button type="button" class="overlay">Expand</button> </module-codeblock> <module-codeblock collapsed language="js" copy-success="Copied!" copy-error="Error trying to copy to clipboard!"> js <pre class="shiki monokai" style="background-color:#272822;color:#F8F8F2" tabindex="0"><code>// Vue component <template> <div> <label> First name <input v-model="first" type="text" /> </label> <label> Last name <input v-model="last" type="text" /> </label> <label> <input v-model="full" type="checkbox" /> Use full name as display name </label> <p>Display name: <span>{{ displayName }}</span></p> <p>User name: <span>{{ userName }}</span></p> </div> </template> <script setup> import { ref, computed } from 'vue' const first = ref('') const last = ref('') const full = ref(false) const displayName = computed(() => { return full.value ? `${first.value} ${last.value}` : first.value }) const userName = computed(() => { return `${first.value[0] ?? ''}${last.value}`.toLowerCase() }) </script> </code></pre> <basic-button class="copy"> <button type="button" class="secondary small"> Copy </button> </basic-button> <button type="button" class="overlay">Expand</button> </module-codeblock> These solutions work well and have powered countless applications. However, they come with trade-offs that may not fit every project: <ul> <li>Bundle size: Framework code must be downloaded and parsed before your app starts.</li> <li>Runtime overhead: Client-side rendering (CSR) adds computational cost that delays interaction and may cause layout shifts.</li> <li>Complexity: Server-side rendering (SSR), hydration and build tooling add infrastructure complexity and imposes tighter coupling between frontend and backend.</li> <li>Vendor lock-in: Components written for one framework can't easily move to another.</li> </ul> For many applications, these trade-offs are worth it. But what if you could get the benefits of reactivity less costy? </section> <section> <h2 id="reactivity-without-a-framework"> <a name="reactivity-without-a-framework" class="anchor" href="#reactivity-without-a-framework"> 🔗 </a> Reactivity Without a Framework </h2> While frameworks solve the reactivity problem, they introduce new challenges. What if reactivity wasn't tied to a rendering model? What if you could have: <ul> <li>Fine-grained updates to the DOM,</li> <li>Automatic dependency tracking,</li> <li>Without needing a virtual DOM, compiler, or bundler?</li> </ul> That's possible – with just a few functions. We call these reactive primitives that track dependencies and trigger updates signals. Here's what a minimal signal-based reactivity system might look like: <module-codeblock collapsed language="js" copy-success="Copied!" copy-error="Error trying to copy to clipboard!"> js <pre class="shiki monokai" style="background-color:#272822;color:#F8F8F2" tabindex="0"><code>import { state, computed, effect } from '@zeix/cause-effect' // State signals const first = state('Ada') const last = state('Lovelace') const full = state(false) // Computed signals const fullName = computed(() => full.get() ? `${first.get()} ${last.get()}` : first.get(), ) const userName = computed(() => `${first.get()[0] ?? ''}${last.get()}`.toLowerCase(), ) // Effects effect(() => { console.log(fullName.get()) }) effect(() => { console.log(userName.get()) }) </code></pre> <basic-button class="copy"> <button type="button" class="secondary small"> Copy </button> </basic-button> <button type="button" class="overlay">Expand</button> </module-codeblock> Notice: <ul> <li>All necessary recalculations and DOM updates are performed automatically.</li> <li>Unnecessary updates are avoided:<ul> <li>When you change the last name, the effect that depends on <code>displayName</code> will only run if the checkbox is checked.</li> <li>When you change the first name, the effect that depends on <code>userName</code> will only run if the the first letter of the first name changes.</li> <li>When you toggle the full name checkbox, only the effect that depends on <code>fullName</code> will run.</li> </ul> </li> </ul> This is fine-grained reactivity – the system tracks exactly what depends on what and updates only what's necessary. This model: <ul> <li>Works with server-rendered HTML.</li> <li>Hydration is done by the browser.</li> <li>Performs only minimal reconciliation in the signal graph.</li> <li>Keeps JavaScript optional for initial rendering.</li> <li>Makes each state update cheap and predictable.</li> </ul> And best of all – it's not hypothetical. This approach is already being standardized. </section> <section> <h2 id="signals-are-going-native"> <a name="signals-are-going-native" class="anchor" href="#signals-are-going-native"> 🔗 </a> Signals Are Going Native </h2> The idea behind signals (a reactive primitive with <code>.get()</code> and <code>.set()</code> methods) is so powerful that it's making its way into the JavaScript language itself. The TC39 signals proposal is currently at Stage 1, meaning the syntax and API are still evolving. However, the core concepts are well-established and unlikely to change significantly. Here's a preview of what native signals might look like: <module-codeblock collapsed language="js" copy-success="Copied!" copy-error="Error trying to copy to clipboard!"> js <pre class="shiki monokai" style="background-color:#272822;color:#F8F8F2" tabindex="0"><code>// State signals const first = new Signal.State('Ada') const last = new Signal.State('Lovelace') const full = new Signal.State(false) // Computed signals const fullName = new Signal.Computed(() => full.get() ? `${first.get()} ${last.get()}` : first.get(), ) const userName = new Signal.Computed(() => `${first.get()[0]}${last.get()}`.toLowerCase(), ) // State updates first.set('Betty') </code></pre> <basic-button class="copy"> <button type="button" class="secondary small"> Copy </button> </basic-button> <button type="button" class="overlay">Expand</button> </module-codeblock> This is the future of reactivity – minimal, composable, efficient, and framework-agnostic. Th