BeWellUp - Blog

Introducing bwu_redux_devtools: A Redux DevTools GUI for Rust

2026-07-18T00:00:00+00:00

Following bwu_redux</a> out the door, we've now open sourced bwu_redux_devtools — the Redux DevTools GUI and gRPC server we built to inspect bwu_redux</code> stores, published onGitHub</a> under a dual MIT/Apache-2.0 license.

What it does</h2> Connected apps stream every dispatched action and the resulting state to the DevTools server. The GUI shows the action history per app and lets you inspect any recorded state as a collapsible tree, JSON, or RON. The tree view — shown above — color-codes what changed since the previous action (added, removed, changed), with a toggle to hide everything that didn't change, so a large state doesn't bury the one field you actually care about. It's built with Dioxus</a>, the same GUI framework as BWU Designer, and runs as both a desktop app and a web GUI. Not on crates.io yet</h2> Unlike bwu_redux</code> itself, this crate isn't published to crates.io: it depends on the official Dioxus components, whose dioxus-primitives</code> crate is currently only available as a git dependency, not a published release. Once that lands upstream, we'll publish here too. Until then, install straight from GitHub: # Desktop GUI (embeds the DevTools gRPC server) cargo install --git https://github.com/BeWellUp/bwu_redux_devtools --bin bwu_redux_devtools # Headless gRPC server only (e.g. to serve the web GUI) cargo install --git https://github.com/BeWellUp/bwu_redux_devtools --bin bwu_redux_devtools_server --features standalone-server</code></pre>Connecting an app</h2> Enable devtools on the store config in the app you want to inspect — this needs the redux_devtools</code> feature of bwu_redux</code>, which is on by default: let config = StoreConfig::new(initial_state, reducer) .with_devtools(true) .with_app_name("my-app");</code></pre> Start the DevTools GUI, then your app; it appears in the sidebar and its action history fills in live. An MCP interface, for free</h2> With the mcp</code> feature enabled, the same server also serves an MCP</a> endpoint alongside its usual gRPC one — no separate binary or process. That means an AI agent — Claude Code, for instance — can inspect a connected app's live Redux state directly: list connected apps, pull an app's action/state history, read its current state, or pause forwarding for noisy actions. For us, that turned out to be a genuinely useful way to let an agent debug state issues in BWU Designer without us relaying screenshots back and forth. Try it</h2> Issues and pull requests are welcome on GitHub</a>. If you're already using bwu_redux</code>, this is the other half of the picture — go give it a try.

Introducing bwu_redux: Redux-Style State Management for Rust, Now Open Source 2026-07-17T00:00:00+00:00 In our last post</a> we made the case for pairing Redux-style state management with Rust. Today that's no longer just an argument — it's a crate you can add to your project. bwu_redux is now open source, published on crates.io</a> and GitHub</a> under a dual MIT/Apache-2.0 license. It's the same state management library behind BWU Designer's frontend, extracted so anyone can use it independently of our app. What it does</h2> bwu_redux is an async, Redux-style store for Rust: a single immutable state, actions dispatched through a middleware chain, and a pure reducer that produces the next state. State changes are broadcast to subscribers as async streams, driven by selectors that extract just the slice of state a subscriber actually cares about — so a subscriber is only woken up when the value it selected actually changes, not on every dispatch. A few things worth calling out specifically: Undo for free. With the history</code> feature enabled (on by default), the store keeps the last N states automatically. Undo isn't a separate system bolted on top — it falls out of the same append-only state log that makes the store predictable in the first place.</li> Time-travel debugging. The redux_devtools</code> feature streams every state change to a DevTools gRPC server for live inspection, using the same wire format whether your app is running natively or in the browser.</li> One codebase, two runtimes. The exact same store, actions, and reducer logic run unmodified on native targets and in WASM via wasm-bindgen</code>/gloo</code> — including the DevTools connection, which just switches to gRPC-web in the browser.</li> </ul> Getting started</h2> use std::sync::Arc; use bwu_redux::{StoreConfig, StoreWrapper}; #[tokio::main] async fn main() { let config = StoreConfig::new(String::from("initial"), |state: String, action: &String| { if action.is_empty() { state } else { action.clone() } }); let store = Arc::new(StoreWrapper::new(config)); store.run(); store.dispatch(String::from("hello")).expect("store is running"); store.close(String::new()).await.expect("close failed"); assert_eq!(store.select(|s| s.clone()), "hello"); }</code></pre> State and action types just need Clone + Debug + PartialEq + Send + Sync</code> — add serde::Serialize</code>/Deserialize</code> if you want the redux_devtools</code> feature. The README</a> has a more complete example with tracing set up, and the full feature-flag reference. Try it, and tell us what breaks</h2> This is a 0.1.0</code> release: the core store, middleware, undo history, and DevTools integration are all in daily use inside BWU Designer, but the crate is young and the API may still shift. If you try it and hit a rough edge — or just want to see how the DevTools protocol works — issues and pull requests are welcome on GitHub</a>. [dependencies] bwu_redux = "0.1"</code></pre> The Case for Redux and Rust in Frontend Development 2026-07-17T00:00:00+00:00 Frontend state has a way of sprawling. Data gets fetched in one place, mutated in another, and read somewhere else entirely. Six months into a project, the hardest bugs are rarely about what the state contains — they're about when and how it got that way. Something changed state out from under a component that assumed it owned it, or two pieces of code raced to update the same value in slightly different orders. None of that shows up in a type signature. It only shows up at 2am. The Redux pattern was a direct answer to that problem, and it holds up well over a decade later. What the pattern buys you</h2> Redux's core idea is almost boringly simple: there is exactly one source of truth for your application's state, and the only way to change it is by dispatching a typed action through a pure reducer function. No component reaches in and mutates state directly; no side effect quietly rewrites something a different part of the UI is relying on. Every state transition is (old_state, action) -> new_state</code>, full stop. That discipline sounds restrictive, but it pays for itself almost immediately. Because reducers are pure functions, every state transition is inspectable, replayable, and testable in isolation — no mocking a DOM, no simulating a component lifecycle. And once your state changes are just a log of (action, resulting_state)</code> pairs, time-travel debugging and undo/redo stop being hard features to build. They're closer to a side effect of the architecture than a project in their own right. Framework independence</h2> This is the part that gets undersold. Because business logic — actions, reducers, selectors — has no dependency on the rendering layer at all, the GUI framework becomes a thin, swappable consumer of state rather than the thing everything else is built around. Your reducers don't know or care whether they're being rendered by React, a native toolkit, or nothing at all. That means you can replace the rendering framework later, run a second UI alongside the first — a CLI, a mobile shell, a server-side render — or upgrade the framework version without touching a single reducer, because there was never a dependency to begin with. That's a structural property of Redux itself, independent of language. But it turns out Rust is a particularly good place to build on top of it. Why Rust sharpens the pattern further</h2> A few things compound nicely: Actions as enums. When every action is a variant of an enum, reducers match exhaustively over them. Add a new action and forget to handle it somewhere, and the compiler stops you — not a silent no-op discovered by a user three releases later.</li> Ownership rules eliminate a whole bug class. The classic Redux footgun in dynamically-typed languages is something reaching in and mutating shared state outside the reducer path. Rust's borrow checker makes that structurally impossible, rather than a matter of team discipline and code review.</li> Types catch invalid states at compile time. Instead of a runtime warning about an unexpected prop shape, an invalid state transition simply doesn't compile. The feedback loop moves from "someone notices in production" to "the build fails."</li> </ul> The usual objection</h2> The standard complaint about Redux is boilerplate — action creators, type constants, switch statements sprawling across files. That complaint is largely an artifact of building Redux in a language without a real type system to lean on. Enums, derive macros, and pattern matching collapse most of that ceremony automatically, and the compiler is doing validation work that a dynamically-typed Redux setup has to do by hand, action by action. Where this actually earns its keep</h2> This combination isn't the right tool for a static marketing page. It earns its complexity in applications with genuinely long-lived, intricate state — undo history, multiple views that need to stay in sync, sessions that persist across a lot of user interaction. That's also where the framework-independence point from earlier stops being theoretical: the same reducer and action logic can target multiple runtimes, not just multiple UI frameworks, since none of it depends on a JS runtime, a DOM, or any particular platform to execute. Framework-independence and runtime-independence turn out to be two sides of the same coin — logic that genuinely doesn't know anything about the view layer runs anywhere a view layer might eventually need to exist. We've been finding this combination genuinely useful, and expect to keep writing about what we learn as we go. Hello, world! 2026-07-14T00:00:00+00:00 This is the first post on the BeWellUp blog. More updates about BWU Designer will follow here as the product takes shape. Subscribe to our newsletter</h2> Get updates about BWU Designer in your inbox.

BeWellUp - Blog

Introducing bwu_redux_devtools: A Redux DevTools GUI for Rust

Connecting an app</h2> Enable devtools on the store config in the app you want to inspect — this needs the redux_devtools</code> feature of bwu_redux</code>, which is on by default:</p>

Try it</h2> Issues and pull requests are welcome on GitHub</a>. If you're already using bwu_redux</code>, this is the other half of the picture — go give it a try.</p>

Introducing bwu_redux: Redux-Style State Management for Rust, Now Open Source

The Case for Redux and Rust in Frontend Development

Hello, world!

Subscribe to our newsletter</h2> Get updates about BWU Designer in your inbox.</p> Subscribe</button> </form> </div> </div>

`Try it</h2> Issues and pull requests are welcome on GitHub</a>. If you're already using bwu_redux</code>, this is the other half of the picture — go give it a try.</p>`

Subscribe to our newsletter</h2>
Get updates about BWU Designer in your inbox.</p>