DEV Community: Luciano0322

Query, Mutation, and Stream Are Not the Same Kind of Async Work

Luciano0322 — Tue, 14 Jul 2026 05:25:42 +0000

In the previous article, I discussed a common but dangerous oversimplification:

Async work should not be reduced to Promise.resolve() followed by setState().

The real problem is not that setState() is inherently wrong. The problem is that we often treat every asynchronous result as if it were the same kind of thing.

API request completed       → write to state
Form submitted successfully → write to state
WebSocket message received  → write to state
Background job updated      → write to state

From the UI's perspective, all of these eventually cause something on the screen to update. But from the perspective of data flow semantics, they are not the same kind of work.

Some async work reads data.
Some async work changes the state of a remote or local system.
Some async work continuously observes changes over time.

In other words, they should at least be separated into three different concepts:

Query
Mutation
Stream

Many frontend architectures eventually flatten all of them back into the same pipeline:

async work resolved → update state → render again

This path is familiar and convenient. It is also one of the major sources of state confusion. Because the difference between Query, Mutation, and Stream is not merely their API shape. They have different requirements around data ownership, lifecycle, caching, invalidation, cancellation, retries, and consistency.

Query: Reading a Data Fact

A Query is often understood as something like this:

const users = await fetchUsers()

But this is only the execution form. It is not the semantic meaning.

The essence of a Query is:

I want to know the current state of a particular data fact.

For example:

GET /users
GET /users/:id
GET /posts?authorId=1

These operations mean that we are retrieving a piece of identifiable, cacheable, and revalidatable data. That is why one of the most important properties of a Query is identity: how this piece of data is identified within the system.

For example:

users.list()
users.detail(id)
posts.byAuthor(authorId)

Once a Query has identity, it should not merely be treated as temporary async logic inside a Component.

The same Query result may be consumed by multiple places:

a list page needs users
a detail page needs user
a search box may need partial user data
permission checks may depend on user data
background synchronization may need to revalidate users

If every place performs its own fetch → setState, data ownership becomes confused. Eventually, you end up with multiple pieces of state that look like the same data, but have no semantic relationship with one another.

A Query should not belong to the render lifecycle. It should be a Resource Node inside the Reactive Graph. It owns its identity, knows when it should reload, knows which sources it depends on, and manages its own loading and stale states.

The responsibility of the Render Layer is simply to subscribe to and read the Snapshot of this Node.

Mutation: Changing System State

A Mutation often looks like this:

await updateUser(id, patch)
setUser(updatedUser)

The real complexity of a Mutation is not sending the request.

The hard part is what happens after the request succeeds:

Which data in the system is no longer trustworthy?

For example:

PATCH /users/:id

This Mutation may affect:

GET /users/:id
GET /users
GET /teams/:teamId/members
GET /audit-logs
GET /permissions

If we only treat Mutation as “sending a request,” then after success, we usually end up with patterns like:

setUser(updatedUser)
refetchUsers()
refetchUserDetail()
invalidateQueries(["users"])

These approaches can work. The problem is that the semantics are often scattered across the application. Component A knows it should refetch the list. Component B knows it should update the detail. Some hook knows it should invalidate the cache. Some effect adds an extra synchronization step.

Over time, the system enters a difficult-to-maintain state:

The impact of a Mutation is global, but the logic for handling its consequences is local.

This is the biggest difference between Mutation and Query.

The core question of a Query is:

Which data do I want to read?

The core question of a Mutation is:

What did I change, and which existing data became invalid because of it?

A Mutation should not merely return data. It should also declare its impact on the data graph.

Semantically, it should be closer to this:

updateUser.mutate({
  id,
  patch,
  invalidates: [
    users.detail(id),
    users.list(),
    teamMembers.byUser(id),
  ],
})

Or:

mutation(updateUser, {
  invalidates: ({ id }) => [
    userResource(id),
    usersListResource(),
  ],
})

The exact API shape is not the important part.

The important part is the semantic model:

A Mutation should describe the invalidation relationships it creates, instead of pushing invalidation responsibility into the UI.

If a successful Mutation requires certain Queries to be revalidated, that should be the responsibility of the data layer, not a side effect inside some Component.

A Component is not the owner of the data graph. A Component only knows what it wants to display. It should not be responsible for understanding which nodes in the entire data world need to be recalculated after a Mutation changes something.

The better abstraction is:

Mutation changes the data graph
        ↓
related nodes become invalid
        ↓
Reactive Graph propagates the change
        ↓
UI updates passively

Stream: Not a Continuous Query, but a Long-Lived Data Source

Streams deal with things like WebSocket, Server-Sent Events, AI token streaming, or real-time collaborative updates.

Many times, we simplify Stream handling into this:

socket.onmessage = event => {
  setMessages(prev => [...prev, event.data])
}

Or:

for await (const chunk of stream) {
  setText(prev => prev + chunk)
}

This is fine for small demos, but it quickly exposes another semantic mismatch.

A Stream is a long-lived data relationship.
A Query has a beginning and an end.
A Mutation has submission and completion.
A Stream continuously pushes data over time.

Its concerns are not limited to loading, success, and error.

It also needs to deal with:

connection health and reconnection
the distinction between Current Value and Stable Value
backpressure
subscription lifecycle
whether multiple consumers should share the same Stream

These concerns cannot be properly described by a normal Promise<T>.

For example, consider AI token streaming:

for await (const token of response) {
  setText(prev => prev + token)
}

On the surface, this is just appending text.

But semantically, there are at least three different states:

currentValue   // the value currently flowing
stableValue    // the completed value that can be treated as stable
streamStatus   // streaming / completed / cancelled / error

If we use a single state value to represent all of these, they are easily mixed together. The UI may need to display tokens in real time. The cache may only want to store the completed result. Derived State may not want to recompute on every token. Effects may only need to run after the stream is completed.

This is the biggest difference between Stream and Query. A Query result can be treated as a snapshot. A Stream result is a trajectory of changes over time. It should be modeled as a long-lived Async Resource, not as an endless setState loop inside a Component.

When All Three Are Mixed Together, the System Loses Its Boundaries

If Query, Mutation, and Stream are all flattened into the same process:

async work → setState → render

the system gradually loses its Async Boundary.

You eventually start asking questions like:

Is this loading state for a Query, or is it a Mutation pending state?
Is this error caused by data fetching, or by submission failure?
Is this data a stable result, or an intermediate Stream value?
Who triggered this refetch?
Is this effect synchronizing Derived State, or patching up invalidation after a Mutation?
Is this state the source of truth, or just a snapshot of an async result?
Why does this Component know so many data invalidation rules?

These questions are not obvious at first. In small applications, the differences between Query, Mutation, and Stream can still be remembered by humans. But as the system grows, relying on human memory to maintain semantic boundaries eventually fails.

What remains is a pile of code that looks reasonable, but is semantically confused:

useEffect(() => {
  refetch()
}, [submitted])

useEffect(() => {
  if (success) {
    setLocalUser(data)
  }
}, [success, data])

useEffect(() => {
  if (streamDone) {
    saveToCache(text)
  }
}, [streamDone])

useEffect(() => {
  if (mutationSuccess) {
    reloadList()
    reloadDetail()
    reloadPermissions()
  }
}, [mutationSuccess])

These examples are not necessarily wrong. But they reveal something important:

The async semantics of the system are hidden inside the UI lifecycle.

Once async semantics are hidden inside Components, it becomes difficult to understand where the real ownership of the data flow lives.

Render Should Not Be Responsible for Understanding Async Semantics

The responsibility of Render should be simple:

Describe what the UI looks like under the current Snapshot.

But the responsibility of Query, Mutation, and Stream is different:

Describe how async data exists, changes, becomes invalid, stabilizes, and is consumed.

These two responsibilities should not be mixed.

When Render needs to know too many details about async events, the architectural boundary has already started to shift in the wrong direction.

For example, a Component may look like this:

const users = useUsersQuery()
const updateUser = useUpdateUserMutation()
const stream = useUserActivityStream()

useEffect(() => {
  if (updateUser.success) {
    users.refetch()
  }
}, [updateUser.success])

useEffect(() => {
  if (stream.completed) {
    users.refetch()
  }
}, [stream.completed])

This kind of code is very common in frontend applications.

But from the perspective of ownership, it reveals something deeper:

The Component is patching holes in the data graph.

It is no longer just rendering. It knows which Queries should be updated after a Mutation succeeds. It knows which data should be refreshed after a Stream completes. It knows causal relationships between async states.

Once this knowledge is scattered across Components, the system becomes increasingly difficult to reason about. The rules of data flow are no longer centralized in the data layer. They are hidden across hooks, effects, callbacks, and lifecycles.

A Better Model: Return Async Work to the Reactive Graph

If we model Query, Mutation, and Stream as different kinds of nodes in the Reactive Graph, the responsibilities become much clearer:

Query   (resource)       → readable, cacheable, invalidatable data node
Mutation (mutation)      → operation node that changes system state and declares invalidation relationships
Stream  (streamResource) → long-lived node for time-series data, with current value and stable value separated

Under this model, the UI only consumes Snapshots:

const userView = useResource(user)
const streamView = useStreamResource(chatStream)

The data graph itself is responsible for:

cancelling obsolete Queries when Sources change
invalidating related Queries after Mutations succeed
updating Current Value while a Stream is flowing
committing Stable Value when a Stream completes
making Derived State depend only on the nodes it actually needs
executing Effects only at semantically correct moments

This is not about making simple things complicated. It is about giving each kind of async work the correct semantic home. If we do not build the abstraction here, the complexity does not disappear. It simply flows into UI Components as useEffect. This is also why understanding async work purely as a request wrapper is usually not enough.

fetch, cache, retry, loading, and error are all important. But they solve problems at the request execution level.

The harder question is:

After the request completes, what does it mean inside the data graph?

Conclusion: Async Data Flow Needs Semantics, Not Just State

Query, Mutation, and Stream all affect the UI. But they are not the same kind of async work.

If we only look at them from the perspective of Render, they all look like this:

something changed → update UI

But from the perspective of system architecture, they are three fundamentally different behaviors:

Query    → Read a fact
Mutation → Change the world
Stream   → Observe a timeline

These three behaviors require different ownership models. They also require different runtime semantics.

Only by separating the semantics of Query, Mutation, and Stream can frontend architecture avoid forcing the UI lifecycle to carry the burden of the entire async world.

This is also the core philosophy behind how I designed the async runtime in signal-kernel.

The goal is not only to make async work easier to trigger UI updates. The goal is to give async work the correct semantic position within the system architecture. And this becomes even more important once AI Agents begin participating in software development.

If Query, Mutation, and Stream are scattered across Components, hooks, effects, and callbacks, even humans will struggle to reason about their boundaries. An AI Agent has even less chance of understanding the true semantics of the data flow.

That is the topic I want to explore in the next article:

When AI Agents can generate more and more code, does your system have clear enough architectural boundaries for both humans and Agents to reason about it correctly?

Decoupling Async State from UI Lifecycles

Luciano0322 — Mon, 06 Jul 2026 06:45:59 +0000

In my previous articles, I’ve consistently emphasized a core architectural principle: once the render layer no longer dictates the entire data flow, the boundaries between State, Derived State, and Effects become critical.

When we fall into the habit of stuffing every UI-affecting variable into generic "state," the system quickly loses its semantic structure. In modern frontend applications, this architectural gap becomes most glaring when dealing with asynchronous work.

Async data is never merely "a value that will appear in the future." It carries complex semantics regarding its source, temporal validity, cancellation, error recovery, and invalidation. If these semantics aren't modeled explicitly, they inevitably get pushed down into the UI framework’s lifecycle—indirectly patched together through component mounts, effect dependencies, and callback guards.

This brings us to the core question of this article:

What does a system lose when the correctness of async work is forced to depend on the UI lifecycle?

We are all incredibly familiar with this pattern:

const data = await fetchSomething()
setState(data)

Or, using a standard UI framework hook:

useEffect(() => {
  let cancelled = false

  fetchSomething().then(result => {
    if (!cancelled) {
      setData(result)
    }
  })

  return () => {
    cancelled = true
  }
}, [])

There is nothing inherently wrong with this code for simple use cases. It’s intuitive and perfectly aligns with how Promises are designed to work: trigger the operation, wait for the resolution, and write the result back into state.

However, this mental model has a subtle downside. It encourages us to think of async work as simply calling setState after a Promise resolves. That may hold up for simple screens, but as an application grows, the model starts to expose structural problems.

Promise Only Describes Completion, Not Ownership

A Promise solves a very specific problem:

A piece of work will complete in the future, and it will either succeed or fail.

It can perfectly describe the transition from:

pending → fulfilled

or:

pending → rejected

But a Promise itself does not answer these questions:

Who owns this data?
Is the data still valid when the Promise resolves?
How does this result cascade to other derived data nodes?
If an error occurs, who owns the recovery state?
During a refetch, should we discard the old data or implement a stale-while-revalidate pattern?

A Promise describes the lifecycle of an execution, but it does not define where that execution belongs within the application’s broader data flow. The true challenge in frontend engineering isn't waiting for a Promise to finish; it's orchestrating how that result correctly enters the system. If we just shove the payload into component state, we are making the UI lifecycle responsible for data coordination that it was never designed to model.

`setState` Is Not the Boundary of Async Correctness

The responsibility of setState is simple:

Write a value into a state container and notify the UI that it may need to re-render.

But async correctness involves far more than assigning a value.

Take the classic race condition example:

const userId = state.userId

const user = await fetchUser(userId)

setUser(user)

What happens if userId changes while the request is still in flight?

Imagine this sequence:

fetchUser(1) starts
fetchUser(2) starts
fetchUser(2) finishes first
fetchUser(1) finishes later

If we simply call setState after each Promise resolves, the UI may end up showing:

userId = 2
user data = user 1

This isn't a flaw in the Promise—it's faithfully delivering the payload. The real problem is that the system lacks a clear semantic layer for deciding whether this async result still belongs to the current data state.

So we start adding guards:

let requestId = 0

async function loadUser(userId: string) {
  const current = ++requestId
  const user = await fetchUser(userId)

  if (current === requestId) {
    setUser(user)
  }
}

Or we use cancellation:

const controller = new AbortController()

fetch(url, { signal: controller.signal })

These techniques are practical, and they do solve local problems.

But fundamentally, they are patching the same issue:

Async work has not been placed inside the semantics of the data flow. It is treated as an external process that pushes a result back into state after completion.

Loading, Error, and Data Are Not Independent States

Another common pattern is to split async work into several pieces of state:

const [data, setData] = useState(null)
const [loading, setLoading] = useState(false)
const [error, setError] = useState(null)

Then we manually synchronize them during the request:

setLoading(true)
setError(null)

try {
  const result = await fetchSomething()
  setData(result)
} catch (err) {
  setError(err)
} finally {
  setLoading(false)
}

From the UI perspective, splitting async work into data, loading, and error feels reasonable. The UI does need to render different things based on different async states. But semantically, these three values are not unrelated pieces of state. They describe different aspects of the same Async Resource.

In other words:

data, loading, and error should not just be scattered fields inside a component. They should be understood as different projections of the same resource state.

Otherwise, the system can easily enter inconsistent combinations:

loading = false
error = null
data = stale data

loading = true
error = previous error
data = previous data

loading = false
error = error
data = new data

Some combinations are valid. Some are bugs. Some depend on product semantics.

For example, when reloading data, should the previous data be preserved?

status = loading
data = previous data

This can be perfectly reasonable because the UI may want to display stale-while-revalidate behavior.

But if these values are just split across multiple setState calls, the system itself does not know which combinations are valid. The developer has to manually preserve these relationships in every component.

Effects Should Not Coordinate Every Async Task

In many frontend architectures, Effects are treated as the universal solution for async work. This is understandable. API requests, WebSockets, and timers are all interactions with the external world.

However, when Effects take on too much async coordination, they become the center of system complexity.

It is easy to end up with logic like this:

Effect A fetches data
Effect B listens to data and updates derived state
Effect C writes derived state into cache
Effect D listens to mutation results and triggers refetch

On the surface, this looks reactive. But in reality, it has degraded into a process network maintained by execution order.

Correctness no longer depends on clear dependencies. It depends on:

Which Effect runs first?
Which state is cleared first?
Which callback observes which intermediate value?

The nature of an Effect is to execute a side effect, not to express a data relationship. If starting requests, cancelling requests, checking validity, synchronizing status, and updating cache are all pushed into Effects, the problem is not merely that the code becomes longer.

The real problem is that the semantic boundaries of the architecture have collapsed.

Async Results Carry Temporal Semantics

Synchronous state changes are relatively intuitive:

count = 1
count = 2
count = 3

But async results are different. An async result carries time semantics. It is not merely: value = result

It also implies:

Which request produced this result?
Is this result later than the current state?
Does this result still correspond to the current source?
Has this result already become stale?
Should this result overwrite the existing data?

So async state is not ordinary state. It is data state with source, time, and validity semantics. If we simplify it into “call setState after the Promise resolves,” we are hiding those temporal semantics.

In the short term, the code may look simpler. But in the long term, the complexity does not disappear. It only moves somewhere harder to trace.

From “The Request Completed” to “The Resource State Changed”

The mindset shift is this:

Do not only care whether an async function has completed.
Care about how the state of an async resource changes as its dependencies change.

In other words, we move from this:

fetch completes → setState

To this:

source changes → resource re-evaluates
resource state changes → dependent nodes in the graph update

The former is an imperative process. The latter is a data flow model.

In the former model, the developer has to manually decide every step:

When should we fetch?
When should loading be set?
When should data be set?
When should error be set?
When should a stale result be ignored?
When should refetch happen?

In the latter model, these concerns can be wrapped into the semantics of a Resource:

value
status
error
reload
cancel
invalidate

This does not mean developers should lose control over async work. Quite the opposite. A good async model should make control more explicit.

But that control should not be scattered across render functions and effect chains. It should be concentrated at the semantic boundary of the Resource.

Treating Async Work as a Data Node in the Reactive Graph

When I first started building signal-kernel, my focus was on basic reactive primitives:

Signal
Computed
Effect

But when I began working on Async Resources, I realized that async work is directly related to the correctness of the entire reactive graph.

In real applications, data is rarely produced only synchronously.

Data often comes from:

API requests
WebSockets
Streams
Background tasks
User actions
Mutation responses
Cache hydration
Server snapshots

If all async work can only complete outside the graph and then push its result back through setState, the reactive graph can only guarantee so much. It can guarantee updates for synchronous dependencies.

But it can't fully handle the semantics introduced by async work:

time
cancellation
invalidation
reload
errors

So the purpose of async-runtime is not to wrap Promise in a nicer API.

Its core idea is:

Async work should become a trackable, cancellable, invalidatable, observable data node inside the reactive graph.

This is also why I increasingly do not see Async Resource as merely a UI data-fetching problem. It is an extension of data flow ownership.

UI Should Not Be the Only Owner of Async Correctness

In traditional frontend thinking, async work is often tied to the component lifecycle:

Fetch when the component mounts
Cancel when the component unmounts
Refetch when dependencies change
Call setState when the Promise resolves

For simple screens, this is intuitive and completely reasonable. The problem appears when the scope of async data is much larger than a single component.

For example:

User information
Permission data
Shopping cart state
Notification state
Background synchronization
Mutation results
Cache hydration
AI agent execution state

These pieces of data may be consumed by multiple screens, multiple components, multiple derived states, and multiple effects at the same time.

If their lifecycle is fully attached to a single component, the system starts to become rigid and inconsistent:

The component unmounts, but the data still needs to be preserved.
The component mounts again, and the same data is requested again.
A mutation succeeds, but the system does not know which resources should be invalidated.
One screen has updated, but another screen is still showing stale data.

So the point is not that UI should never use async state.

The point is:

UI should not be the only owner of async correctness.

Promise + setState is a perfectly valid implementation detail for one-off forms, local modals, and short-lived component state. But if it becomes the async architecture of the entire application, the system quickly loses its boundaries.

Only when async work is formally brought into the semantic boundary of the reactive graph can the system pull async correctness back from scattered control flow and restore it as an understandable, traceable, and maintainable data structure.

In the next article, I will discuss another problem that is even easier to confuse:

Query, Mutation, and Stream are not the same kind of async work.

They all look related to async operations, but their semantics in the data flow are fundamentally different. If we treat all of them as merely “a Promise,” the system will quickly lose its boundaries again.

A lot of frontend bugs do not start from bad code. They start from a small semantic mistake: Treating Derived State as if it were real State. Full article is here👇

Luciano0322 — Tue, 30 Jun 2026 12:47:10 +0000

Luciano0322

Jun 29

Deconstructing the Semantic Confusion Between State, Derived State, and Effects

#webdev #frontend #javascript #typescript

5 min read

Deconstructing the Semantic Confusion Between State, Derived State, and Effects

Luciano0322 — Mon, 29 Jun 2026 09:28:29 +0000

In modern frontend architecture, the word “state” has gradually become overgeneralized.

API payloads, user input, computed frontend values, request loading status, and even the result of a side effect are often all placed under the broad category of “state.” At the UI level, this seems reasonable—anything that triggers a UI update looks like state. And once something is considered state, we tend to put it into a component, a store, a ref, a reactive object, or whatever state management tool is at our disposal.

But this is exactly where the problem begins. When the semantics of State, Derived State, and Effects are blurred together, the boundaries of the system’s data flow gradually start to collapse.

State is Not a Catch-All Term

From an architectural perspective, I prefer to think of State as the source of truth within a data flow.

It is the starting point from which subsequent derivations are produced. State should not be a value computed from something else, a temporary cache produced by a side effect, or a duplicated copy created merely for rendering convenience. It is the true entry point of data into the system. It can be changed by external events, user actions, or asynchronous results, driving the rest of the data flow forward.

For example:

// This is real State: the source node in a data flow
const count = signal(0)

But the following case is different:

// This is Derived State: it depends on count and shouldn't own an independent lifecycle
const double = computed(() => count.get() * 2)

double is also data, and it may need to be rendered. But semantically, it is Derived State. Its existence depends entirely on count. It lacks an independent data source, so treating it as independently owned State introduces synchronization cost and the risk of Data Drift. Once we promote Derived State into normal State, the cost of synchronization and the risk of Data Drift immediately follow.

The Core Problem of Derived State: Misplaced Ownership

Almost every complex application requires Derived State—subtotals, form validation statuses, filtered lists, and so on. The computation itself isn't the issue. The real architectural question is: Who owns this Derived State?

When Derived State is written into Component State, it becomes a "fake source of truth" that must be manually synchronized. Consider this common React pattern:

const [users, setUsers] = useState([])
const [activeUsers, setActiveUsers] = useState([])

// Synchronize data through lifecycle and Effect
useEffect(() => {
  setActiveUsers(users.filter(user => user.active))
}, [users])

This code splits a simple derivation into three disjointed parts:

The source
The duplicated copy
The synchronization logic

This is where system boundaries blur. We are forced to ask a series of architectural questions:

Is activeUsers a source or a derived result?
What state is the system in during that tiny window after users has changed but before the Effect has run?
If the Effect is skipped due to a flawed dependency array, will the data become permanently out of sync?

When data correctness is no longer guaranteed by structural relationships, but instead relies on execution timing, the maintenance cost of the system skyrockets.

The Danger of Effects: The Illusion of Omnipotence

Effects are arguably the most easily abused mechanism in frontend development simply because they are convenient.

An Effect can sync data, call an API, subscribe to events, write to localStorage, manipulate the DOM, or write Derived State back into State. Because Effects can do almost anything, complex data-flow problems often end up being pushed into them.

Looks like Derived State:

useEffect(() => {
  const next = expensiveCalculation(source)
  setResult(next)
}, [source])

Looks like Async Work:

useEffect(() => {
  fetchData(id).then(data => {
    setData(data)
  })
}, [id])

Closer to an actual external Side Effect:

useEffect(() => {
  if (data) {
    analytics.track("data_loaded")
  }
}, [data])

In real-world projects, these three distinct semantics are routinely crammed into the exact same mechanism. As a result, the Effect gradually devolves into a universal escape hatch.

Hard to express a data relationship? Use an Effect. Need to keep two states in sync? Use an Effect. Don't know where a workflow belongs? Just throw it in an Effect. In the short term, it's convenient. In the long term, it destroys your data-flow boundaries.

When Sync Logic Becomes an Effect, You Rely on Execution Order

The relationship between State and Derived State should be structural. Once the source data is known, the derived result should be deterministic:

source state -> derived state

But when Derived State is synchronized via an Effect, correctness no longer relies solely on dependencies; it relies on whether the Effect executes at the right time:

source state -> render -> effect -> set derived state -> render again

This path introduces unnecessary uncertainty. Effects are usually attached to a lifecycle or rendering process after the fact. This means updates might be delayed until after the render, fail due to stale closures, or clash with interleaved Effects.

This is one of the root causes of many async bugs and inconsistent data states. The issue isn't careless developers; it's a system forcing distinct data semantics into a single execution model.

Restoring Semantic Roles

I prefer to separate these concepts into three distinct roles:

State: The source data of the system. It can be changed by external events or user actions.
Derived State: Data derived from State or other Derived State. It should not be manually synchronized.
Effect: An action that produces impact outside the data graph after data changes.

A healthier data flow should look more like this:

State
  ↓
Derived State
  ↓
Effect / Render / Async Boundary

Once the data graph is established, it becomes obvious that not everything needs to serve the Render cycle.

Components Shouldn't Bear the Weight of All Data Semantics

Frontend architecture becomes heavy because Components are forced to do too much. They describe UI, but they're also expected to manage Local State, compute Derived State, fire Async Requests, execute Effects, and manually juggle useMemo to prevent rendering bottlenecks.

When we use lifecycles to patch data flow, it's a glaring symptom that the system lacks distinct data boundaries.

This Is Also Why I Started Rethinking `signal-kernel`

Initially, I thought I was just building a fine-grained reactive system—providing primitives like Signal, Computed, and Effect for precise updates. But its true architectural value isn't just "more granular updates."

The deeper value is this:

It establishes a data-flow model based on a Reactive Graph, making semantic boundaries clear again.

In this model, business logic and data flow are no longer owned by the UI framework:

Signal holds Source State.
Computed holds Derived State, ensuring derivations are automatically tracked, not manually synced.
Effect handles actual side effects (I/O, DOM manipulation).

Once this Reactive Graph is established, Render is just another consumer. The data flow is structured inside the graph first, and the UI simply reflects the current slice of that graph.

Let Data Semantics Return to Their Proper Place

As frontend apps grow, state increases naturally. More state isn't the enemy—semantic confusion is.

When Source State, Derived State, Effect Results, Async Statuses, and Render Caches are all treated as the exact same thing, boundaries vanish. You lose track of the true source. You rely on memoization to hide unclear ownership.

The true challenge of frontend architecture isn't just updating the screen efficiently; it's giving every piece of data a clear semantic owner. When these boundaries are restored, the system evolves from "patching data through lifecycles" to being "driven by data relationships."

This is the true value of a Reactive Graph. It makes the invisible boundaries of data visible again.

When Render No Longer Owns the Entire Data Flow

Luciano0322 — Mon, 22 Jun 2026 09:16:01 +0000

In frontend development, it is very easy to think of data flow and rendering as the same thing. After all, for most applications, the final goal is to display data on the screen. Data comes back from an API, gets written into state, the component re-renders, and the UI updates.

This path is so familiar that we often unconsciously assume:

The purpose of data changes is to trigger render.

But as an application scales, this assumption begins to crack. Data flow does not exist exclusively to serve the UI. In a complex system:

Some data changes simply update derived state.
Some trigger background tasks.
Some synchronize local caches.
Some orchestrate async resources.
Some happen entirely under the hood, with no need for the UI to ever know.

When every piece of data is forced to route back through a component—tangled up in render lifecycles, hooks, watchers, or effects—the architecture inevitably turns into a mess. This isn’t a flaw in React or Vue. It happens because, fundamentally, render was never meant to own the entire data flow.

Render Is a Consumer of Data Flow, Not the Owner

Over time, I've come to deeply embrace this mindset:

Render is just one side effect.

This sentence deeply changed the way I think about frontend architecture, because it reframes the core problem.

Render is, of course, extremely important. Without render, there is no visible output for the user. But from the perspective of a reactive system, render should never be the center of the data flow. It is only one possible side effect produced by data changes.

When a piece of data changes, the system may trigger a chain of reactions:

source state changes
        ↓
derived state updates
        ↓
effects run
        ↓
render may happen
        ↓
async work may continue

Render is one result of the system.
It is not the owner of the system.

However, many frontend architectures and usage patterns make us unconsciously treat render as the ownership boundary of data flow.

For example, in React, we often store data inside component state, then use useMemo, useEffect, and useCallback to manage derived data and side effects.

In Vue, the reactivity system is more fine-grained, but if the application’s data flow still revolves heavily around component scope, watch, watchEffect, or template consumption, data ownership can still become scattered.

This is not about whether a framework is capable or not.

It is about where the center of architectural thinking is placed.

Frameworks usually care about this question:

When should the UI update?

But when I was designing signal-kernel, the question in my mind was different:

After data changes, who should own the update logic?

These two questions may look similar, but they are fundamentally different.

Why Components Should Not Carry All Data Flow Responsibilities

Components are great at describing UI. They are good at composing views, receiving props, handling events, and presenting state.

But they are not ideal ownership boundaries for the entire data flow. This isn't obvious when your state is simple, but once derived state and async state start piling up, components are quickly crushed under responsibilities they were never meant to hold.

Consider a common flow like this:

userId changes
  → fetch user profile
  → fetch permissions
  → compute available actions
  → update form visibility
  → trigger validation
  → maybe render

If this entire flow is placed inside a component, it often becomes something like this:

useEffect fetch data
useMemo compute derived state
useEffect sync another state
useEffect trigger validation
conditional render

At first, this may still look acceptable. But as requirements grow, the component slowly turns into a data-flow scheduler.

It no longer only describes the UI. It also has to decide:

Who depends on whom?
Who should update first?
Which values can be recomputed?
Which side effects are allowed to run?
Which async work needs to be cancelled?
Which state must not drift?

At this point, the responsibility of the component has already gone far beyond render. And the most troublesome part is that these dependencies are usually not explicit. They are hidden inside hooks, watchers, callbacks, and dependency arrays.

The system may still work on the surface, but the ownership of the data flow has been shattered.

The Boundary Problem of Derived State

Derived state is where this architectural leak is most glaring. By derived state, I simply mean data that can be programmatically inferred from other data:

cartItems → totalPrice
userRole + permissions → availableActions
searchKeyword + filters + rawList → visibleList

Ideally, these are just nodes in a reactive graph. When source state changes, the derived state naturally marks itself as stale and recomputes only when necessary.

But in a render-centric codebase, these derivations are trapped inside components through useMemo, computed, or similar component-scoped mechanisms. This is fine in isolation. This is fine in isolation. The ownership boundary starts to blur, however, when that derived state is needed by an async task, a cache, or a business rule outside the UI layer.

Suddenly, state that looks like it belongs to the UI is actually carrying the weight of domain logic. This is the exact ambiguity of ownership I keep emphasizing.

It's About Ownership, Not Performance

When people talk about signals or fine-grained reactivity, the first thing that usually comes to mind is performance.React re-renders; Solid updates the DOM directly; Vue tracks dependencies precisely; Signals bypass unnecessary recomputations.

These are real, practical benefits. But over time, I’ve realized that performance is just the most visible byproduct. The actual paradigm shift is ownership.

Render-centric model: The UI owns the data flow. Data mutations must pass through the UI lifecycle (hooks, component scopes) before they can be organized, derived, and synchronized.
Graph-centric model: The reactive graph owns the data flow. Events trigger signals, signals derive a computed graph, and effects, resources, and renders are all simply downstream consumers.

This realization became my North Star while building signal-kernel. I wasn't trying to write another UI framework, nor was I trying to prove React or Vue wrong. I just wanted to answer one question:

If render is no longer the center of data flow, who should take over?

My answer is the reactive graph.

Let Render Return to Its Proper Position

When the reactive graph takes over, render is drastically simplified. It doesn't need to know how data is derived, it doesn't orchestrate update orders, and it doesn't juggle async consistency. It just reads the state it cares about and paints the screen.

This isn't about downplaying the importance of the UI. It’s about letting the UI return to what it's actually good at. In this model, the boundaries are strict:

Signal owns the source state.
Computed owns the derived state.
Resource owns the async state.
Effect owns the side effects.
Render owns the visual output.

By extracting data flow from the render lifecycle, we give data its own independent ownership boundary. This is the core semantic philosophy behind signal-kernel.

What This Means for React and Vue

For React developers, this pain point is acute. Because React is fundamentally render-driven, data-flow issues inevitably turn into interrogations about useState, useMemo, useEffect, dependency arrays, and re-render optimization. This is exactly why large React codebases suffer from dependency array fatigue, stale closures, and effect overuse.

For Vue, the situation is more nuanced. Vue already has a built-in reactivity system; ref, computed, and watch describe data dependencies beautifully. A Vue developer reading this might think: "Isn't Vue doing this already?"

To an extent, yes. Vue brought reactive graphs into mainstream application development much earlier. But there is a key distinction: Vue’s reactivity can be used independently, but its primary design context is still the Vue application model.

What signal-kernel explores is a framework-agnostic reactive graph. I'm not asking, "Should we use signals to update Vue components?" I'm asking, "Can we build a standalone data core that React, Vue, background jobs, async runtimes, and even AI agents can all consume simultaneously?"

That’s why the React and Vue adapters for signal-kernel are intentionally thin. A framework adapter shouldn't seize control of the data flow; it should merely bridge the graph to the UI.

A System You Can Actually Reason About

When render relinquishes control, you don't just get better performance—you get a system you can actually reason about. You stop asking framework-specific syntax questions and start asking architectural ones:

Is this source state or derived state?
Is this a synchronous derivation or an async result?
Is this a data-layer effect or a UI-layer effect?
Should this state live inside the component, or inside an independent reactive graph?

Conversely, when everything is pushed back into the component lifecycle, profound architectural flaws are disguised as hook usage questions:

How do I write this dependency array?
Why is this useEffect firing twice?
Should I wrap this in useMemo?
Is watchEffect too automatic?

These questions all have technical answers, but they mask the deeper, underlying problem:

Who is actually supposed to own this piece of the data flow?

Downgrading Render Into One of Many Outputs

UI frameworks are incredibly important. React, Vue, and Solid have all solved very difficult problems in their own dimensions.

But in complex frontend applications, we need to recognize one thing:

Render should no longer be treated as the only center of data flow.

Only when data flow has its own ownership can a system move from UI-driven state management toward graph-driven state ownership.

On the surface, signal-kernel is a signal library. But at its core, it is an exploration of how frontend data architecture can be rebuilt when render steps back and becomes just one kind of side effect.

In the next article, I will continue breaking down this problem:

When state, derived state, and effect are mixed together, how does a system gradually lose its boundaries?

From Signals to Ownership: Why I Built a Dataflow Kernel

Luciano0322 — Mon, 15 Jun 2026 07:17:57 +0000

When I first started building signal-kernel, I thought I was simply writing a signal library—a fine-grained reactive system not tied to any specific UI framework. On the surface, it had all the basic building blocks you would expect from a signal library:

Core primitives: Signal, Computed, and Effect
Mechanisms: dependency tracking and scheduling
Extensions: async resources and framework adapters

It could build a reactive graph, track dependencies, update derived state precisely when data changed, and bridge the result into React or Vue. But the deeper I dug into the implementation, the more I realized the real problem wasn't about building another signal library. The core question was actually this:

In a complex application, who should truly own the dataflow?

Fragmented Dataflow and the Derived State Problem

In modern frontend applications, dataflow often feels natural at first. API data comes back, gets written into state, and components render the result. If we need derived data, we use useMemo. If we need side effects, we use useEffect. If we need async requests, we use a query library, and if we need shared state, we introduce a store.

Individually, none of these solutions are wrong. React is not wrong. Vue is not wrong. TanStack Query is not wrong. Zustand and Jotai are not wrong either. The real problem appears when the system grows larger. At that point, the exact same logical dataflow starts getting split across multiple ownership models.

Some state belongs to components, while other state belongs to a store. Some derived state is trapped inside the render phase, and async state lives inside a query cache. The system still works, but the boundaries of the dataflow start to depend heavily on conventions, team discipline, and developer memory. It becomes incredibly hard to answer one seemingly simple question: Who actually owns this derived state? Is it the component, the store, the framework runtime, or just a temporary value calculated inside a hook?

Render Should Not Naturally Own the Entire Dataflow

Frontend developers often treat render as the center of the system. This is completely understandable—what we look at and debug every day is the UI. So when data changes, our first instinct is usually: "Which component needs to re-render?"

But if we reverse the question, the architecture looks very different. When data changes, perhaps the first question should be: "Which pieces of derived data are actually affected?" Render is simply one kind of side effect caused by data changes. It is extremely important, but it should not naturally own the entire dataflow.

This became one of the core architectural lessons I learned:

The reactive graph should first describe the relationships between data, while render should only be one consumer of that graph.

From Signal Library to Dataflow Kernel

If I only saw signal-kernel as a signal library, then most design questions would stay at the API surface: Should it feel more like Solid? Should computed values be lazy or eager? Should it support batching? These are important, but they hide the deeper issue: When a piece of state changes, who is responsible for deciding which derived states are affected?

In a traditional component-driven model, this usually happens during render:

Data changes → component re-executes → derived data is recalculated.

This model works beautifully for small applications, but it forces the lifecycle of derived state to follow the lifecycle of render. Once derived state becomes expensive, needs to be shared across frameworks, or needs to be deeply connected with async streams, this model becomes fragile.

That is why the real goal of signal-kernel was never simply to “reduce re-renders.” The goal was to detach derived dataflow from render ownership. What I actually wanted to build was a dataflow kernel.

A system that focuses on lower-level architectural concerns:

How state becomes a pure source of truth.
How derived state is tracked stably inside a reactive graph.
How effects can be separated cleanly from the render lifecycle.
How async work and continuously written streams can become part of the reactive graph while keeping clear state boundaries.
How render can return to its proper role: a consumer, not the owner.

Keeping the Boundary: Thin Framework Adapters

This way of thinking also directly shaped how I designed the React and Vue adapters. At the beginning, I naturally wanted to provide many convenient hooks and APIs that felt familiar to framework users. But over time, I became much more conservative.

If an adapter becomes too thick, it quietly pulls ownership back into the UI framework. And once that happens, the data independence that signal-kernel is trying to preserve starts to fade away.

A cleaner and more stable boundary should look like this:

Core owns the reactive graph.
Async-runtime owns the consistency of async state.
Framework adapters only subscribe to and read snapshots.
Render only draws the current result to the screen.

An adapter should not redefine the dataflow. It should only be a transparent pipe into the framework.

Rethinking Framework Responsibility

I want to make one thing clear: this series is not meant to criticize React or any other UI tool. React is still excellent at handling UI consistency, and TanStack Query solves a very real, difficult server-state problem.

What I want to explore is a deeper architectural question:

When we habitually put all data logic into the model of a UI framework, are we accidentally making render responsible for too much?

If reactive dataflow itself can be an independent system, then what role should a UI framework actually play?

What I Was Really Studying Was Ownership

While implementing the core and async-runtime of signal-kernel, I kept running into a series of uncomfortable architectural questions:

After a Promise resolves, is it really just a simple setState?
If a stream keeps emitting chunks, who should own its stable value, status, and error?
After a mutation succeeds, is invalidation the responsibility of the query cache, or the reactive graph?

All of these questions eventually point to the same word: Ownership.

I originally thought I was building a signal library. But the more I built, the more I realized that what I was really studying was how the boundaries of dataflow should be redefined in increasingly complex frontend applications. APIs can change. Implementations can be replaced. But the core question remains the same:

When data changes, who is responsible for understanding that change?

If the answer is always render, then we are forced to keep layering workarounds around the UI framework. But if the answer is the reactive graph, then render can return to its most reasonable position. It is one outlet of the dataflow. It is one side effect. It is a consumer of the system, not the owner.

That is the most important lesson I learned while building signal-kernel. If this idea resonates with you, I’m exploring it through signal-kernel, a framework-agnostic reactive dataflow kernel.

The project is still evolving, but its direction is clear: render should be a consumer of the dataflow, not the owner.

In the next article, I want to continue exploring this question:

What actually changes in frontend architecture when render no longer owns the entire dataflow?

What I Learned After Building a Signal System from Scratch

Luciano0322 — Mon, 08 Jun 2026 02:27:19 +0000

Recap

At this point, this series on Signals and fine-grained reactivity is temporarily coming to an end.

This article will not introduce new technical details. Instead, I want to share some personal reflections and thoughts after writing the whole series.

The Influence of Ryan Carniato

In some sense, this entire series was inspired by Ryan Carniato, the creator of Solid.js.

Ryan has always been able to point directly at the pain points we face in React development. As a senior React engineer, I often find myself thinking:

Yes, this is exactly the problem I run into every day.

Solid.js is undoubtedly an excellent framework, although its learning curve can be high for beginners.

However, from my perspective, many of its design choices feel more reasonable than the direction React has taken. For example:

Effects without dependency arrays
Separating mounted logic from cleanup logic
JSX without the Virtual DOM

These are all things that many developers in the React community had asked for before, but they were never truly prioritized.

The Dilemma of React and Next.js

Over the past few years, React’s direction has become increasingly influenced by the needs of the Next.js ecosystem.

Server Components introduced an important architectural shift, but they also forced many frontend engineers to adopt a model that still feels immature in everyday application development.

To be clear, I am not saying Server Components are useless. They solve real problems around server-side data access, streaming, and reducing client-side JavaScript. But from a frontend developer’s perspective, they also make the mental model of React significantly more complex.

To be honest, I sometimes miss the era of “Next.js without Server Components.” React was simpler back then. Its problems were obvious, but at least the boundaries were easier to reason about, and we had more freedom to choose our own solutions.

People in the community have proposed ideas such as “Should React introduce signals?” or even “Should React explore a version without the Virtual DOM?” These ideas may not align naturally with the current product direction and incentives around React and Next.js, but I still think they are worth discussing seriously.

My point is not that React is wrong or that the Virtual DOM is useless.

The Virtual DOM is still a reasonable abstraction in many scenarios. For example, in cross-platform environments such as React Native, it provides a practical compromise between a declarative UI model and multiple rendering targets.

My point is narrower:

The Virtual DOM is not wrong. It is just no longer the only reasonable center of frontend architecture.

When the problem is fine-grained data dependency, update precision, and scheduler correctness, signals provide a different model that deserves serious consideration.

What I see today is a React ecosystem entering a more conflicted phase. Although projects like TanStack are still doing excellent work to improve the developer experience, if a mature alternative appears in the future, I may no longer choose Next.js by default.

Common Misunderstandings

“Isn’t this just Jotai?”

In the community, you may sometimes hear people say that Jotai — or the atomic state model in general — is basically the same thing as signals. Some even argue that because it is built closer to the framework ecosystem, it is more developer-friendly.

But if you have followed this series and implemented the concepts step by step, or if you have ever implemented a reactive system yourself, you will understand that the two approaches are based on very different design philosophies.

The key difference is whether the system handles dependencies.

Below is a simple conceptual comparison.

Atomic State: The Recoil / Jotai Family

Core idea: Split state into the smallest possible units, often called state atoms. There is no implicit dependency tracking between them.
Composition model: Use selectors or derived functions to organize logic and compose state.
Update model: When state changes, the system does not automatically notify downstream dependents. Instead, selectors are re-executed as pure functions.
Characteristics:
- Easy to understand in a functional way: state is a value, and a selector is a pure function.
- However, the dependency graph is not explicit. Every read may require recomputation, which can lead to repeated calculations.

Signals

Core idea: Signals are also fine-grained state units, but they include an explicit dependency-tracking graph.
Composition model: computed and effect automatically register dependencies during execution. When a source value changes later, downstream subscribers are notified automatically.
Update model: Usually push-based. Once a source value changes, downstream nodes are marked as stale, and the scheduler decides when to run updates.
Characteristics:
- Avoids unnecessary recomputation because the runtime knows who depends on whom.
- Update propagation is faster and more precise.
- Requires the runtime to manage a dependency graph.

Summary of the Difference

In one sentence:

Atomic state: Splits state, but does not deeply manage dependencies. The system needs to “calculate again” through functions.
Signals: Splits state and adds dependency tracking. The system knows who needs to update.

Not handling dependencies does make the model easier to write and understand. Jotai also relies on the framework’s own state model, which naturally aligns with the framework lifecycle and avoids many synchronization problems.

But the trade-off is that this model must rely on framework re-renders to guarantee correctness. Signals, on the other hand, can achieve more fine-grained updates through runtime-level dependency tracking.

Flow Difference

“Isn’t this just Dependency Injection?”

Another common comparison is to treat signals, especially when integrated with Vue or React, as something similar to Dependency Injection (DI) in the traditional OOP world.

At first glance, it does look somewhat similar: you inject external state into a framework and use it inside the application.

But the essential difference is this:

DI solves the composition and management of object dependencies.
Signals solve the tracking and update timing of data dependencies.

They may look similar on the surface, but they solve problems at completely different dimensions.

What Does DI Solve?

It answers: “Which object needs which service?”
Timing: Construction time
Keywords: dependency relationship, object composition
Example: A Car needs an Engine, and the DI framework injects it for you.

class Engine {}

class Car {
  constructor(private engine: Engine) {}
}

What Do Signals Solve?

They answer: “Which piece of data depends on which other piece of data?”
Timing: Runtime
Keywords: data tracking, state update propagation
Example: totalPrice depends on count * unitPrice, and it updates automatically when the source values change.

const count = signal(2);
const unitPrice = signal(100);
const totalPrice = computed(() => count.get() * unitPrice.get());

A Simple Clarification

DI helps objects get the services they need.
Signals help the system know who should update when data changes.

“Signals are just another state management tool”

Many people think signals are just another form of state management.

But after going through the implementation details in this series, you can see that signals touch much more than state management.

A state management library usually helps you organize where state lives and how it is updated.

A signal system goes one layer deeper. It asks:

How are data dependencies tracked?
How are invalidations propagated?
When should derived values recompute?
When should effects run?
How should the scheduler preserve consistency?

This is why reducing signals to “just another state management tool” misses the point.

What signals challenge is not merely state management, but the long-standing assumption that the Virtual DOM must sit at the center of frontend architecture.

That does not mean the Virtual DOM has no value. It means we should treat it as one architectural trade-off among many, not as the only valid mental model for UI development.

Technical evolution is never just about code. It is also about incentives, existing knowledge systems, and the cost of changing how people think.

Signals are uncomfortable because they move the discussion away from component re-rendering and toward data dependency itself.

Adjusting Your Mindset: Facing Irrational Criticism

Some people will directly deny the value of signals. Some may even mock them with comments like:

Signals are useless.

Dan already told you not to use them.

These comments often carry more emotion or tribal position than technical understanding.

To me, these voices are not a threat. They are more like a mirror:

If you already understand the difference between atomic state and signals, you can easily see the blind spots in the argument.
If you do not understand it yet, then it is a useful reminder that you should study the topic more deeply.

Of course, this does not mean we should blindly reject React’s design decisions either. React has solved many real engineering problems, and its ecosystem is still extremely valuable.

But no framework author, no matter how experienced or influential, should become a reason for us to stop thinking.

The healthier attitude is to return to concrete examples, implementation details, and trade-offs.

So when you encounter this kind of criticism, the best response is not to rush into an argument.

Return to the code. Return to the design principles.

Once you can explain the difference in dependency tracking with a simple example, the mockery naturally loses its power.

The Future of Signals

Overall, I am quite optimistic about the future of signals.

The TC39 Signals proposal from last year already shows that signals are becoming increasingly important in frontend development.

Apart from React, which still seems to maintain a “React knows best” atmosphere, most mainstream frameworks have already entered a new era with signal-like ideas:

Vue’s Vapor Mode
Angular 17+ Signals
Svelte Runes
Preact Signals
SolidJS

Some of them are even moving toward removing the unnecessary parts of the Virtual DOM, such as Vue’s Vapor Mode and SolidJS’s JSX compilation model.

This means that developers who truly understand the core ideas behind signals will be much more comfortable in future frontend applications.

In my own experience, once I understood these concepts, switching between different frameworks became much easier.

Why I Started This Series

The reason I started this series was that I was building my own open-source signal system library: signal-kernel.

During that process, I kept running into challenges. Then I realized something important:

Many of the “algorithms and data structures” we learned in school or practiced for interviews are actually useful here.

This made me even more convinced of one thing:

If you want to design the foundation of a framework well, you must understand JavaScript fundamentals and computer science.

What I Learned

To me, this series is not just a set of technical notes. It is also part of my own journey as an engineer.

It started from my frustration with React.
It was inspired by Ryan Carniato’s ideas.
It eventually led me back to the importance of JavaScript fundamentals and algorithms.

The biggest lesson I learned is this:

Frameworks will come and go, but fundamental knowledge and mental models are what allow you to go further.

This series only peels back the first layer of a framework engine: the reactive core.

Of course, the reactive core is also one of the most important foundations of any framework. If we continue going deeper, we will run into topics such as:

DOM rendering
UI rendering schedulers
Component models

Every framework makes different decisions and trade-offs in these areas.

These may become directions for my future research.

Advice for Readers

If you are currently learning React, you do not need to rush into Solid.js or any other framework.

The truly important thing is not which framework you choose. The important thing is understanding the underlying concepts:

The data flow from state → derivation → effect
Why schedulers and dependency graph management matter
The difference between push and pull
The difference between eager and lazy execution

Once you understand these ideas, you can quickly find your direction in any framework.

Do not just learn how to use a framework. Learn the logic underneath it.

Trends will change, but fundamental concepts are the real assets that engineers can carry with them.

Signal Implementation Reference

As usual, I will also attach the implementation code from this series for reference:

reactivity_lessons

The repository includes unit tests for each section, although only the parts that changed in each chapter are tested.

I still hope readers will modify the examples themselves instead of simply copying and pasting the code.

If you only copy the implementation directly, you will miss many opportunities to think through the details.

The examples I provide are intentionally designed choices. In many cases, the data structures and subscription model may not fit every development scenario. However, they make the concepts easier for beginners to understand.

I did not want to switch between too many algorithms and data structures during the explanation, because that would introduce unnecessary confusion.

For more advanced discussion, I recommend focusing on Ryan Carniato’s article series, especially Derivations in Reactivity, which explains many of the trade-offs behind today’s mainstream signal implementations.

New article published: Building Reactive DevTools A reactive system should not be a black box. In this article, I explore how to make a signal-based runtime observable through node inspection, graph visualization, render counters, and hotspot tracking.

Luciano0322 — Mon, 01 Jun 2026 06:06:33 +0000

Luciano0322

Jun 1

Building Reactive DevTools: Inspecting, Visualizing, and Profiling the Graph

#javascript #typescript #frontend #webdev

5 min read

Building Reactive DevTools: Inspecting, Visualizing, and Profiling the Graph

Luciano0322 — Mon, 01 Jun 2026 05:59:47 +0000

Recap

In the previous chapters, we explored:

Scheduler internals
Memory and graph management
Priority and layered scheduling
Time-slicing and cooperative scheduling

All of these mechanisms are essential for making a reactivity system work correctly internally.

But internal correctness alone is not enough.

For developers, the more important question is:

How do we observe, debug, and understand the system?

That is where DevTools and diagnostics become critical.

Inspecting Nodes

Why do we need `inspect()`?

One of the most common debugging needs during development is:

“What is the current value of this signal or computed?”

If the only solution is console.log, debugging quickly becomes inconvenient and intrusive.

A proper inspection layer gives developers visibility without polluting application logic.

Feature Design

The inspector should provide:

Current value
Dependency relationships (deps / subs)
Whether the node is:
- stale
- disposed

Implementation

// devtools.ts
// type reused from previous graph.ts
import type { Node } from "./graph.js";

// Assign IDs using WeakMap without polluting Node structure
const ids = new WeakMap<Node, string>();
let seq = 0;

function getId(n: Node) {
  let id = ids.get(n);

  if (!id) {
    id = `${n.kind}#${++seq}`;
    ids.set(n, id);
  }

  return id;
}

export type InspectSnapshot = {
  id: string;
  kind: Node["kind"];
  inDegree: number;
  outDegree: number;
  deps: { id: string; kind: Node["kind"] }[];
  subs: { id: string; kind: Node["kind"] }[];
};

// Get a flat snapshot of a single node (non-recursive)
export function inspect(node: Node): InspectSnapshot {
  return {
    id: getId(node),
    kind: node.kind,
    inDegree: node.deps.size,
    outDegree: node.subs.size,
    deps: [...node.deps].map(n => ({
      id: getId(n),
      kind: n.kind,
    })),
    subs: [...node.subs].map(n => ({
      id: getId(n),
      kind: n.kind,
    })),
  };
}

Debug-Friendly Logging

export function logInspect(node: Node) {
  const snap = inspect(node);

  console.log(
    `[inspect] ${snap.id} (${snap.kind})  in=${snap.inDegree}  out=${snap.outDegree}`
  );

  if (snap.deps.length) {
    console.log("  deps ↑");
    console.table(snap.deps);
  } else {
    console.log("  deps ↑ (none)");
  }

  if (snap.subs.length) {
    console.log("  subs ↓");
    console.table(snap.subs);
  } else {
    console.log("  subs ↓ (none)");
  }
}

This provides a much friendlier debugging experience than raw logging.

Recursive Graph Inspection

When debugging larger dependency chains, inspecting a single node is often not enough.

We can recursively expand the graph while avoiding cycles.

export function inspectRecursive(root: Node, depth = 1) {
  const seen = new Set<Node>();

  type Row = {
    from: string;
    to: string;
    dir: "deps" | "subs";
  };

  const rows: Row[] = [];

  const queue: Array<{
    node: Node;
    dUp: number;
    dDown: number;
  }> = [{
    node: root,
    dUp: depth,
    dDown: depth,
  }];

  seen.add(root);

  while (queue.length) {
    const { node, dUp, dDown } = queue.shift()!;
    const fromId = getId(node);

    if (dUp > 0) {
      for (const dep of node.deps) {
        rows.push({
          from: getId(dep),
          to: fromId,
          dir: "deps",
        });

        if (!seen.has(dep)) {
          seen.add(dep);

          queue.push({
            node: dep,
            dUp: dUp - 1,
            dDown: 0,
          });
        }
      }
    }

    if (dDown > 0) {
      for (const sub of node.subs) {
        rows.push({
          from: fromId,
          to: getId(sub),
          dir: "subs",
        });

        if (!seen.has(sub)) {
          seen.add(sub);

          queue.push({
            node: sub,
            dUp: 0,
            dDown: dDown - 1,
          });
        }
      }
    }
  }

  return {
    center: getId(root),
    nodes: [...seen].map(n => ({
      id: getId(n),
      kind: n.kind,
    })),
    edges: rows,
  };
}

Mermaid Export

We can even export subgraphs into Mermaid diagrams for documentation or DevTools visualization.

export function toMermaid(root: Node, depth = 1) {
  const g = inspectRecursive(root, depth);

  const lines = ["graph TD"];

  for (const n of g.nodes) {
    lines.push(
      `  ${n.id.replace(/[^a-zA-Z0-9_#]/g, "_")}["${n.id}"]`
    );
  }

  for (const e of g.edges) {
    const a = e.from.replace(/[^a-zA-Z0-9_#]/g, "_");
    const b = e.to.replace(/[^a-zA-Z0-9_#]/g, "_");

    lines.push(`  ${a} --> ${b}`);
  }

  return lines.join("\n");
}

API Summary

inspect(node)
- Fastest single-node snapshot
logInspect(node)
- Debug-friendly console tables
inspectRecursive(node, depth)
- Small graph expansion without infinite loops
toMermaid(node, depth)
- Export subgraphs for docs or DevTools rendering

Graph Visualization

As applications grow larger, textual inspection is no longer sufficient.

At that point, we need dependency graph visualization.

Signal nodes (blue) represent data sources
Computed nodes (green) represent derived values
Effect nodes (yellow) represent side effects

Inside DevTools, we could:

Click nodes to inspect current values
Highlight stale nodes
Visualize link/unlink operations
Observe automatic cleanup and graph pruning

This makes the dataflow fully observable.

Instead of a black box, developers can literally see:

Which state triggered which update.

Render Counters

The Problem

In UI frameworks, one of the most common performance issues is over-rendering.

For example:

Components re-render repeatedly
But nothing meaningful actually changes

Feature Design

A render counter can:

Increment on each render
Display a small overlay badge
Aggregate render statistics in DevTools

Why This Matters

This helps developers identify:

Unnecessary re-renders
Missing memoization
Poor equality strategies
Expensive recomputation chains

It also guides optimization decisions like:

memo
shallowEqual
computed caching

Hotspot Tracking

Why Track Hotspots?

In large applications, knowing that something updated is not enough.

We also need to know:

Which nodes update the most frequently?

That is where hotspot profiling becomes valuable.

Feature Design

We can track:

Update counts
Update frequency
Execution duration
Graph degree statistics

And combine them with:

Heatmaps
Timeline views
Priority scheduling traces

Hotspot Implementation

1. `hotspot.ts`

// hotspot.ts
import type { Node } from "../graph.js";

export type HotspotStats = {
  updates: number;
  lastTs: number;
  freqPerMin: number;
  durTotal: number;
  durCount: number;
};

let stats = new WeakMap<Node, HotspotStats>();

const liveNodes = new Set<Node>();

const alpha = 0.2;

const now = () =>
  globalThis.performance?.now?.() ?? Date.now();

The system tracks:

Frequency
Total execution time
Average execution time
Update counts

without modifying the core graph structure itself.

2. Tracking Signal Writes

recordUpdate(node);

We only inject instrumentation where actual work happens.

For example:

signal.set()
computed.recompute()
effect.run()

This keeps the core runtime clean and minimally invasive.

3. Wrapping Computation Timing

withTiming(node, () => {
  // recompute logic
});

This allows us to measure:

recomputation frequency
average execution duration
expensive reactive chains

Example Usage

logTopHotspots(5, "freq", allNodes());

logTopHotspots(5, "avgTime", allNodes());

logTopHotspots(5, "updates", allNodes());

This lets us quickly identify:

high-frequency nodes
expensive computations
reactive bottlenecks

Real-World Use Cases

Game Loops

Identify states updating every frame.

Forms

Detect extremely hot input fields.

Data Visualization

Locate nodes responsible for expensive re-renders.

Async Systems

Observe retry storms or invalidation cascades.

Why DevTools Matter

DevTools are not just debugging utilities.

They also help developers:

Build Mental Models

Understand how the reactive graph actually flows.

Optimize Performance

Locate bottlenecks quickly instead of guessing blindly.

Learn Reactivity

Make invisible runtime behavior visible and intuitive.

Possible Future Directions

Timeline Profiling

Visualize update propagation over time.

Priority-Aware Diagnostics

Inspect how different scheduler priorities interact.

Automated Suggestions

Examples:

“This signal updates too frequently.”
“Consider memoizing this computed.”
“This effect causes excessive downstream invalidation.”

Final Thoughts

By adding:

node inspection
graph visualization
render counters
hotspot profiling

we transform the reactive system from a black box into an observable runtime.

This not only improves debugging and optimization,
but also helps developers truly understand how reactivity works internally.

DevTools are not just developer conveniences —
they are part of how a runtime teaches its own architecture.

At this point, I’ve shared most of the core knowledge I gained while implementing this series.

There are still many unexplored trade-offs and architectural differences across reactive libraries, and those differences often determine why certain libraries perform better in specific scenarios.

In the next article, I’d like to share some personal reflections and lessons learned from writing this entire series.

I published a new article in my Signals series. In this article, I explore how cooperative scheduling, shouldYield(), and task chunking help avoid blocking the JavaScript main thread.

Luciano0322 — Tue, 26 May 2026 03:17:32 +0000

Luciano0322

May 26

How React-Style Time-Slicing Keeps UIs Responsive

#javascript #typescript #frontend #webdev

2 min read

How React-Style Time-Slicing Keeps UIs Responsive

Luciano0322 — Tue, 26 May 2026 03:11:13 +0000

Quick Recap

In the previous article, we introduced priority-based and layered schedulers, solving the problem of “which tasks should run first.”

However, real-world applications introduce another challenge:
long-running tasks can still block the main thread.

To keep applications responsive, a scheduler must also support:

Time-Slicing
Cooperative Scheduling

The Problem: Long Tasks Blocking the Main Thread

Imagine this scenario:

The UI thread is executing a large rendering task — for example, updating 5000 list items at once.

That operation might take tens of milliseconds, or even exceed 100ms before finishing.

During that time:

Mouse movement and keyboard input cannot respond immediately
The UI may freeze and drop below 60 FPS
Users experience visible stuttering and lag

Priority alone is not enough.

Even if a task has the correct priority, once execution begins, it can still monopolize the main thread.

Time-Slicing

The core idea behind Time-Slicing is:

Split a long task into smaller chunks and periodically yield control back to the main thread.

Workflow

A task is divided into smaller chunks
After each chunk, the scheduler checks whether there is remaining execution time
If not → pause execution and continue later during the next available frame or idle period

This ensures:

User input and animations remain responsive
Background work completes progressively over time

Cooperative Scheduling

In operating systems, there are two major scheduling models:

Preemptive Scheduling
Cooperative Scheduling

In JavaScript’s single-threaded environment, true preemption is impossible.

So frameworks adopt cooperative scheduling instead:

Tasks voluntarily check whether they should yield (shouldYield())
If interrupted, the remaining work is re-queued for later execution

This is essentially the strategy used by React Concurrent Mode.

Example Implementation

Here is a simplified example of a Time-Slicing + Cooperative Scheduler:

let deadline = 0;

function shouldYield() {
  return performance.now() >= deadline;
}

export function runWithTimeSlicing<T>(
  work: () => T,
  timeSlice = 5
): T | void {
  deadline = performance.now() + timeSlice;

  while (!shouldYield()) {
    const result = work();
    return result;
  }

  // Not finished → continue later
  queueMicrotask(() =>
    runWithTimeSlicing(work, timeSlice)
  );
}

Key Idea

Each execution is allowed to run for only timeSlice milliseconds
Once the budget is exceeded, control returns to the browser

This prevents long-running tasks from blocking the main thread entirely.

Combining Time-Slicing with Priorities

On top of a layered priority scheduler, we can integrate Time-Slicing strategies:

Immediate / High Priority
- Execute immediately without slicing
Normal Priority
- Use time-slicing and process incrementally
Low / Idle Priority
- Use requestIdleCallback
- Run only when the browser is idle

This allows the system to balance:

Real-time interactions
Heavy background updates
Overall UI smoothness

Time-Slicing Scheduler Flow

Final Thoughts

Priority scheduling solves the question of:

“Which task should run first?”

Time-Slicing and Cooperative Scheduling solve another equally important problem:

“How do we avoid blocking the UI?”

Together, these techniques allow systems such as Signals, React, and Vue to remain responsive even under massive update workloads.

In the next article, we’ll explore DevTools and Diagnostics, including:

Inspecting reactive nodes
Dependency graph visualization
Render counters
Hotspot tracing
Scheduler debugging tools

These tools help us better understand how signals and schedulers behave in real-world applications.

In my latest signal article, I explore how priority queues and layered execution can help a scheduler preserve interaction responsiveness while still maximizing performance utilization.

Luciano0322 — Thu, 21 May 2026 05:22:37 +0000

Luciano0322

May 21

Building a Smarter Scheduler: Priority Queues and Layered Execution

#javascript #typescript #frontend #webdev

3 min read

DEV Community: Luciano0322

Query, Mutation, and Stream Are Not the Same Kind of Async Work

Query: Reading a Data Fact

Mutation: Changing System State

Stream: Not a Continuous Query, but a Long-Lived Data Source

When All Three Are Mixed Together, the System Loses Its Boundaries

Render Should Not Be Responsible for Understanding Async Semantics

A Better Model: Return Async Work to the Reactive Graph

Conclusion: Async Data Flow Needs Semantics, Not Just State

Decoupling Async State from UI Lifecycles

Promise Only Describes Completion, Not Ownership

setState Is Not the Boundary of Async Correctness

Loading, Error, and Data Are Not Independent States

Effects Should Not Coordinate Every Async Task

Async Results Carry Temporal Semantics

From “The Request Completed” to “The Resource State Changed”

Treating Async Work as a Data Node in the Reactive Graph

UI Should Not Be the Only Owner of Async Correctness

A lot of frontend bugs do not start from bad code. They start from a small semantic mistake: Treating Derived State as if it were real State. Full article is here👇

Deconstructing the Semantic Confusion Between State, Derived State, and Effects

Deconstructing the Semantic Confusion Between State, Derived State, and Effects

State is Not a Catch-All Term

The Core Problem of Derived State: Misplaced Ownership

The Danger of Effects: The Illusion of Omnipotence

When Sync Logic Becomes an Effect, You Rely on Execution Order

Restoring Semantic Roles

Components Shouldn't Bear the Weight of All Data Semantics

This Is Also Why I Started Rethinking signal-kernel

Let Data Semantics Return to Their Proper Place

When Render No Longer Owns the Entire Data Flow

Render Is a Consumer of Data Flow, Not the Owner

Why Components Should Not Carry All Data Flow Responsibilities

The Boundary Problem of Derived State

It's About Ownership, Not Performance

Let Render Return to Its Proper Position

What This Means for React and Vue

A System You Can Actually Reason About

Downgrading Render Into One of Many Outputs

From Signals to Ownership: Why I Built a Dataflow Kernel

Fragmented Dataflow and the Derived State Problem

Render Should Not Naturally Own the Entire Dataflow

From Signal Library to Dataflow Kernel

Keeping the Boundary: Thin Framework Adapters

Rethinking Framework Responsibility

What I Was Really Studying Was Ownership

What I Learned After Building a Signal System from Scratch

Recap

The Influence of Ryan Carniato

The Dilemma of React and Next.js

Common Misunderstandings

“Isn’t this just Jotai?”

Atomic State: The Recoil / Jotai Family

Signals

Summary of the Difference

Flow Difference

“Isn’t this just Dependency Injection?”

What Does DI Solve?

What Do Signals Solve?

A Simple Clarification

“Signals are just another state management tool”

Adjusting Your Mindset: Facing Irrational Criticism

The Future of Signals

Why I Started This Series

What I Learned

Advice for Readers

Signal Implementation Reference

New article published: Building Reactive DevTools A reactive system should not be a black box. In this article, I explore how to make a signal-based runtime observable through node inspection, graph visualization, render counters, and hotspot tracking.

Building Reactive DevTools: Inspecting, Visualizing, and Profiling the Graph

Building Reactive DevTools: Inspecting, Visualizing, and Profiling the Graph

Recap

Inspecting Nodes

Why do we need inspect()?

Feature Design

Implementation

Debug-Friendly Logging

Recursive Graph Inspection

Mermaid Export

API Summary

Graph Visualization

Render Counters

`setState` Is Not the Boundary of Async Correctness

This Is Also Why I Started Rethinking `signal-kernel`

Why do we need `inspect()`?

1. `hotspot.ts`