Meet Stan DevTools
2025 was quite a year for Stan. From early conceptual work, through:
- the initial release,
- many, many bug fixes,
- performance optimizations,
- improving caching,
- fixing catastrophic memory leaks,
- preventing infinite loops,
- improving Suspense support,
- shipping more examples,
- refining the React bindings,
- trying to make the documentation not suck (it still kinda sucks, though),
until finally reaching version 1.7.2 - a significant milestone marking what I like to refer to as relative stability, both API surface and internals. To capitalize on that wishful maturity, Stan now ships with dedicated devtools, distributed as a Chrome extension.
Why do you need devtools at all?
While maintaining a relatively simple API surface, Stan happens to be very dynamic in nature. A change that seemingly happened in the context of one store may actually have happened in the context of another. An API response you expect to be cached may end up refreshed on the next access (via selector re-evaluation) because of how you've configured your cache policy. A change of seemingly isolated state may trigger re-evaluation in 10 other places. Wouldn't it be nice to be able to peek under the hood as these changes happen?
Stan DevTools let you:
- dynamically switch between all active stores,
- inspect and track the history of state changes,
- search and filter state entries.
Why a Chrome extension, not <framework_name>?
Unlike other state management libraries, Stan is framework-agnostic at its core. Shipping devtools as components would basically mean one implementation per stack, which feels sub-optimal. Whereas, whether you're using vanilla Stan, React bindings, or <framework_name> bindings, a Chrome extension will just work™️.
Resources
Enjoy!
Photo by maks_d on Unsplash.