Visualizing Complex State in Real-Time.

Managing state in a modern frontend application is incredibly complex. Whether you are dispatching actions in Redux or piping data through an RxJS observable stream, relying on console.log() to track your application's state changes is a recipe for a headache.

Bypassing Sandboxed Iframes

The problem with traditional online code editors like CodePen or JSFiddle is that they execute your code inside heavily sandboxed, cross-origin iframes. This completely breaks your browser's native developer tools. You cannot connect the Redux DevTools extension to an isolated iframe.

NitroIDE fixes this by executing your preview inside a transparent, same-origin context when authorized. This allows your local Chrome/Edge extensions to hook directly into the IDE's execution window.

// Connecting Redux to browser extensions natively in NitroIDE
import { configureStore } from '@reduxjs/toolkit';
import rootReducer from './reducers';

const store = configureStore({
  reducer: rootReducer,
  // Redux DevTools will automatically detect the store
  // exactly as it does on your local localhost setup.
  devTools: process.env.NODE_ENV !== 'production',
});

export default store;

Integrated State Visualizer: Even if you don't have browser extensions installed, NitroIDE features a built-in "State" tab in the bottom terminal panel. You can pass any object to window.Nitro.watch('MyState', object), and we will render a real-time, collapsible JSON tree visualization directly in your workspace.

Time-Travel Debugging

Because the React/Redux environment runs natively on your machine via WebAssembly, there is zero network latency between a state dispatch and the UI update. You can drag the Redux time-travel slider and watch your DOM perfectly re-render previous states instantly.

Taming RxJS Streams Without console.log

Observables are invisible by design. Values flow through pipes, subscriptions come and go, and the only evidence anything happened is a side effect somewhere downstream. The usual debugging response — a tap(console.log) in the middle of the pipe — produces a scrolling wall of text with no sense of timing, no stream identity, and no way to see what you didn't get: the completion that never fired, the error that was swallowed two operators up.

Piping the stream into the State visualizer changes the shape of the problem. Instead of reading a log, you watch a live, collapsible tree of the latest emission, with each new value appended to a short history. Completions and errors surface as distinct, timestamped events rather than silence:

// Pipe any stream into the built-in State visualizer
const { BehaviorSubject } = rxjs;
const { debounceTime, switchMap } = rxjs.operators;

const search$ = new BehaviorSubject('');
const results$ = search$.pipe(
debounceTime(300),
switchMap(q => fetchResults(q)) // your async lookup
);

window.Nitro.watch('searchResults', results$);
// The State tab now shows every emission, completion, and error — live.

This is particularly revealing for cancellation semantics. A switchMap that drops an in-flight request when a new keystroke arrives looks identical to a mergeMap in a console log — both eventually print results. In the visualizer, the cancelled inner stream's completion event is visible, so you can confirm at a glance that the old request was actually torn down and not just ignored. Race conditions stop being a theory and become something you can see.

Redux: Following an Action From Dispatch to Render

Redux's data flow is a straight line — dispatch an action, run it through reducers, produce new state, notify subscribers, re-render — but in practice the line gets hard to follow once thunks, selectors, and middleware enter the picture. The DevTools extension lays the line out flat: every dispatched action appears in a list, each with the exact state diff it produced, and clicking any entry re-renders the UI at that point in history.

A slice written with Redux Toolkit needs no special instrumentation to participate. Standard actions, standard reducers — the tooling hooks in through the store enhancer:

// Every action below becomes a time-travel checkpoint
const cartSlice = createSlice({
  name: 'cart',
  initialState: { items: [], status: 'idle' },
  reducers: {
    addItem(state, action) { state.items.push(action.payload); },
    removeItem(state, action) {
      state.items = state.items.filter(i => i.id !== action.payload);
    }
  }
});

Dispatch addItem twice and remove one, and the action list tells the whole story: payloads, resulting diffs, and the final state, each independently inspectable. When a selector returns stale data or a component doesn't re-render, the answer is usually visible in the diff — the state updated but the reference didn't change, or the action never fired at all. If you're setting up the React side of this from scratch, our guide to running React without npm gets the workspace going with no build step, and the no-build prototyping guide covers the same pattern for Vue and TypeScript.

Debugging Async State: Thunks, Effects, and Race Conditions

Synchronous state is easy; async state is where applications actually break. A thunk dispatches pending, awaits a network call, then dispatches fulfilled or rejected — three actions for one logical operation, interleaved with everything else the app is doing. When two requests overlap, the responses can land out of order, and the UI ends up showing data from the request the user already abandoned.

Time-travel is the antidote. Replay the action sequence and watch the exact moment the stale response overwrote the fresh one; the fix — ignoring outdated responses via request IDs, or cancelling with an AbortController — becomes obvious once you've seen the failure frame by frame. The same replay technique works for RxJS effects: step through the emissions and confirm that each cancellation actually cancelled.

A practical habit: keep your async state shape explicit. A status field (idle / loading / succeeded / failed) plus a lastRequestId turns "the UI shows wrong data" from a mystery into a checklist — the visualizer shows you the status transitions directly, and a succeeded with a stale request ID names the bug.

A Debugging Workflow That Scales

Visualization is a tool, not a lifestyle — a few habits keep it useful as the app grows. Name your watches after the domain concept (cart, searchResults), not the variable. Watch sparingly: a handful of meaningful streams beats a dashboard of everything, because signal drowns in noise past a certain point. Combine watches with real breakpoints for the hard cases — the visualizer shows you what happened, the debugger shows you why.

And when you've isolated a bug, capture it. A share link to the workspace reproduces the exact state for whoever picks it up next — no "works on my machine," no stale screenshots. Open a fresh codebox workspace, wire up the failing stream or slice, and hand your teammate a running reproduction instead of a description of one.

When Visualization Isn't Enough

Watches and time-travel cover the what, but some bugs need the why — and for that, the fundamentals still apply. A breakpoint inside a reducer or an operator shows you the exact values at the decision point; the network tab settles arguments about what the server actually returned versus what the thunk claimed. The visualizer tells you which action corrupted the state; the debugger tells you which line did it.

The two approaches compose rather than compete. Reproduce with the visualizer, isolate with a breakpoint, then verify the fix by replaying the same action sequence and watching the state land where it should. State bugs feel mysterious right up until you can see them — and then they're just bugs, with fixes.

Debug with Clarity.

Launch a React workspace and connect your DevTools instantly.

Launch React IDE