Idea: portable core-store traces for notifications and reducer replacement

[PerchAnton]

I prepared an external Redux core example for interaction-check, a JSONL regression runner I maintain. It calls legacy_createStore, combineReducers and applyMiddleware to make notification and middleware order inspectable after each action.

The traces cover no-op dispatch still notifying, unsubscribe, and replaceReducer preserving existing state while initializing a new slice. Would this be useful as an optional core API reproduction? It is not a recommendation to replace Redux Toolkit in applications.

Adapter · Three traces · External PR. Tested with redux 5.0.1: 3 scenarios / 11 steps pass locally on macOS, Node 24.19.0.

From that checkout, with Python 3.10+ and Node 24.19.0:

npm --prefix adapters/javascript ci --ignore-scripts --no-audit --no-fund
python interaction_check.py scenarios/redux/*.json -- node adapters/javascript/main.mjs redux

[timdorr]

Thanks for sharing this! I'm having a little trouble understanding what you're proposing we do with this.

These sound like existing Redux behaviors that we already cover in our own test suite. Is the idea that we'd incorporate your regression runner into Redux's testing infrastructure, or that you'd maintain an external set of tests that we could reference when debugging issues?

What would this let us test or reproduce that our existing tests can't?

[markerikson]

Yeah, I see the posts in all our repos, and honestly I don't understand what the actual proposal is. Even tried looking at some of these "adapters" in the linked repo.

What is this tool, what problem does it solve, and what concrete changes or suggestions are you proposing?

[PerchAnton]

Thanks @timdorr and @markerikson. I should have explained the use case before posting examples across your repos.

interaction-check is a Python command-line tool. It reads a JSON file containing actions and expected values, runs a small program that calls the library being tested, and reports the first difference. In this Redux case, that program creates a real store, subscribes a listener, dispatches a no-op, then sets the count to 2. The expectations check listener calls and state before and after middleware runs.

I meant an external example that I maintain. The possible use is attaching a small, repeatable sequence to a bug report and running the same case against different revisions with a compatible adapter. It still requires that adapter and the Python runner.

These examples cannot test anything your regular Redux tests cannot. They cover existing behavior; I have not shown missing coverage, a new bug, or an advantage over a normal Redux reproduction. There is no concrete upstream change justified by them, and I am not asking you to add the runner to Redux's CI or dependencies. I will keep these examples external.

[timdorr]

Ah, OK. Thanks for clarifying. Best of luck with the project!

[PerchAnton]

Thanks, Tim. I appreciate your feedback and kind words!