On Mon, Aug 24, 2026 at 1:05 PM Evan Rusackas <[email protected]> wrote: [...]
> Until things like Dashboard components are de-coupled from Redux > accordingly, this seems like it’ll be rewiring a whole lot of things that > should be un-wired first. > [...] I think there is indeed evidence for this complexity due to the redux/zustand bridge, e.g. see C1/C2: https://github.com/apache/superset/pull/41548#issuecomment-5360234619. ...however, I'm not sure abstracting into extensions *first* is the best route. I agree that extensions should ultimately have no knowledge of Redux or its replacements — but an extension interface designed around the Redux store's shapes would need to be redesigned as soon as the store under it changes, so decoupling-then-migrating likely means building the abstraction twice: once over Redux, and again over Zustand. My hunch is that we can't separate "decoupling" from "migration" all that easily — un-wiring a consumer means moving it onto some interface, and that's the same consumer-by-consumer work the migration forces anyway. On the instability concern: the C1/C2 class of breakage is real, but it's also preventable without waiting for the extensions architecture — typing the boundary modules against the real RootState (so a removed slice becomes a compile error rather than a silent undefined), plus a one-time sweep for locally-declared state types naming migrated slices, would have caught both. That seems like a reasonable merge gate rather than a reason to hold the port. So I'd actually propose that sequence with one reordering: plan the contraction of the remaining Redux pieces, port to Zustand/TanStack with that boundary hardening as a merge gate, and then draw the extension interface over the settled result — once, at the end. That way the interface extensions depend on is designed against the state layer we intend to keep, not the one we're retiring. -Mike
