reduxkotlin

An agent that can't tell whether its change worked will loop, confidently, until your tokens run out. Most of the 1.0 cycle went into fixing that.

rk snapshot renders real Compose screens from seeded store state and diffs them against goldens. Plus a semantics dump that catches what pixel diffing misses.

An in-app debug drawer, a desktop monitor with time travel, and a CLI that prints one JSON object per line: three surfaces over one instrumented store.

A singleton store survives rotation for free and dies with the process. StateSaver fixes that in four lines. Then there's the bug you hit after it works.

No provider, no CompositionLocal, no hooks. You pass the store as a parameter, and each component binds exactly the slice it renders. Then you prove it with a test.

store.subscribe fires on every dispatch, so everyone hand-rolls the same re-read-and-compare boilerplate. subscribeTo does the diffing and only calls back on change.

The thread-safe store I recommended in 2020 put a lock around every function, including getState. ConcurrentStore keeps writes serialized and makes reads lock-free.

The exact KMP target matrix for ReduxKotlin 1.0: what every module supports, what got dropped, and the single platform shim the Redux layer actually needs.

ReduxKotlin 1.0.0-alpha04 is on Maven Central. A concurrent store, granular subscriptions, Compose bindings, DevTools, and a CLI. Here is what changed, and why.

Writing code with Redux for web really doesn't require consideration of threading and concurrent modification of variables. Given Javascript is single threaded

Earlier this year I began work on ReduxKotlin.org – a port of the Javascript library Redux. This series of posts will describe the what, why, how, and the visio