Adding liftedState to every monitor action would have performance cost as it has to be serialized everytime. Adding a way to request it from the extension if needed or specifying for what action to include it would be reasonable.

For TOOGLE_ACTION it sends current liftedState and should get modified one (as actions starting from that toggled one will be recomputed and states will be different after that). Same is true for REORDER_ACTIONS, and we should indeed add liftedState for that too. It just doesn't work in any monitors anyway. It was implemented in alexkuz/redux-devtools-inspector#64, but later reverted (as there was not much interest for adding that complexity in the UI). So at the moment it cannot be dispatched, and can ignore it.

SWEEP is handled on the monitor side here for non-redux, and there should be no need to do anything from client side. If that doesn't work out of the box, then you app was interpreted as redux here because you were sending liftedState instead of only store state from start. We should handle it better, expecting that non-redux implementations can do that too.

We should probably handle LOCK_CHANGES as well from monitor side. Same as for jumping, we're just assuming that the client part will handle it in the right way.

For redux we have liftedState doubled on the client side in instrumentation). The reason we're keeping a copy is to implement hot-reloading even if the extension is not in use. When the extension is not in use (its window wasn't opened) for redux the extension doesn't store liftedState history, so we don't have perf waste on serialization if not needed. There's a way to use it without that only for logging.

However for non-redux apps the recommendation is not to maintain a copy of liftedState as it would add extra complexity, especially if the state can be mutated. It should be directly available from the extension as you suggested.

@zalmoxisus: thank you for a detailed explanation.

Interesting, I actually don't send the liftedState from the start. I only send liftedState back on each TOOGLE_ACTION and on IMPORT_STATE. I don't think my app should be recognized as redux. I call init with plain state and then call send for each action dispatched also with plain states, they look just like:

So my questions are then following:

1. On each SWEEP dispatched from the monitor, I really do not need to dispatch anything back to extension? (since nothing happens) For now I cache the liftedState on each TOOGLE_ACTION dispatched, clean it up and send back to extension (but it has an obvious drawback that any actions dispatch after any states toggled is lost since not reflected in cached liftedState). sweep action is following:

The options passed to extensions are the following:

let options = ReduxDevTools.enhancerOptions(
  ~name="ReductiveTests",
  ~serialize=ReduxDevTools.serializeOptions(
    ~symbol=true,
    /* ~replacer=Helpers.serializeWithRecordKeys, */
    ()
  ),
  ~features=ReduxDevTools.enhancerFeatures(
    ~pause=true,
    ~lock=true,
    ~persist=true,
    ~export=Obj.magic("custom"),
    ~import=Obj.magic("custom"),
    ~jump=true,
    ~skip=true,
    ~reorder=false,
    ~dispatch=true,
    ~test=true,
    ()
  ),
  ()
);

@ambientlight I checked now, I see SWEEP is not working. I'll fix it, it should work from the monitor part. There's nothing necessary to do from client part, as it's just visually removing the skipped actions. I will also make the lock button to toggle from the monitor part (together with refactoring for new UI), so you don't need to send anything back, just to lock any changes from your part if possible.

@zalmoxisus: that would be great, looking forward, thanks!

Is it also possible to add liftedState inside REORDER_ACTIONS action?

@ambientlight sure, will add in case it will be supported in future on monitors side.

@zalmoxisus: how's everything been going, just checking if this issue is still relevant here?