reduxjs / redux-devtools

DevTools for Redux with hot reloading, action replay, and customizable UI
http://youtube.com/watch?v=xsSnOQynTHs
MIT License
14.07k stars 1.17k forks source link

replaceReducer with shouldHotReload: false erases action history #378

Open bdwain opened 7 years ago

bdwain commented 7 years ago

I am trying to implement code splitting in my app, and I call replaceReducer when a new reducer is loaded. I use the shouldHotReload: false option to avoid rerunning actions, but now the actions dispatched before replaceReducer are erased from the action history when viewing the devtools. I just see @@Init and then ASYNC_LOAD_COMPLETE, which is dispatched after replaceReducer runs successfully.

Is it possible to preserve the state transitions and actions from before replaceReducer?

Note: I am using the redux devtools chrome extension, so it may just be an issue in that project. But since it uses this library, I just assumed this behavior came from here and not there. If that's wrong I can refile with them.

jmar777 commented 7 years ago

Running into the same issue - all state transitions prior to replaceReducer() being called disappear (although the actions themselves still appear in the Inspector and Log monitor views).

Methuselah96 commented 4 years ago

See more details in this issue: https://github.com/reduxjs/redux-devtools/issues/559.

BenLorantfy commented 3 years ago

@Methuselah96 would you accept a PR to fix this? This is causing issues with the redux-injectors library that I help maintain

markerikson commented 3 years ago

My half-informed suspicion is that there might not be a feasible resolution, because the DevTools relies on replaying actions to show the state at that point in time. If a reducer gets swapped out now, running the "old" actions through it would presumably result in states that don't match what the state was when the original dispatches happened. Happy to be proven wrong here, but that's my first thought.

bdwain commented 3 years ago

One option to improve it would be to store old reducers as well as the current one, so that when replaying actions, it uses the reducer that was current at that time.

Another would be to show the action history but disable replayability before the last call to replaceReducers.

I think both of those would be an improvement over the current behavior. Thoughts?

markerikson commented 3 years ago

Hmm. That could hypothetically work, although there'd have to be bookkeeping to know which actions were dispatched when a given reducer was in use.

DanielCashlink commented 2 years ago

I know this thread is somewhat dead, but I wonder if there's a way to differentiate between the replaceReducer used by the hot reload and user usage of the replaceReducer function. It's actually really annoying having to set shouldHotReload to false, simply because I'm trying to code split my reducers and use the devtools.

piechoo commented 2 years ago

Still running into this issue, which is really annoying, is there any progress with it ?

DanielOrtel commented 1 week ago

Now that there is first-class support for combineSlices in redux-toolkit, with #1326, might I ask if there are plans to fix this issue? It really is a hassle to not be able to enjoy easy code-splitting and devtools at the same time.

markerikson commented 1 week ago

@DanielOrtel this is an old issue and I don't have any of the context loaded into my head.

Can you expand on that train of thought? What are you trying to accomplish that isn't working? How does combineSlices change the situation here? How does that relate to code-splitting (if anything other than just "I'm using combineSlices")?

DanielOrtel commented 1 week ago

Yeah, sorry, I'll expand as best I can:

The original issue was that replaceReducer, with shouldHotReload: false option to avoid rerunning actions, caused the devtools to essentially erase the action history, leaving only the @init action dispatched after the reducer was replaced. The desired option here would be to somehow keep the state when dynamically injecting reducers.

I'll have to be honest, I haven't tested that this is also happening with combineSlices and inject of redux-toolkit, since I used replaceReducer directly. I assumed it was based on the fact that the issue is still open. My comment was looking for some kind of resolution to this issue, though if needed, I can try to test whether this issue persists with devtools tomorrow.

markerikson commented 1 week ago

combineSlices was designed to eliminate the need to call replaceReducer at all - it generates one consistent reducer function reference, and then loads in the later injected reducers as you tell it to.

I haven't wrapped my head around how that might interact with HMR, though. (Honestly it's been a long time since I tried to specifically set up / use HMR with Redux)