Support monitors reducers

[zalmoxisus]

Due to Chrome restrictions, an extension cannot communicate directly with the page script, so the only thing the injecting script does is adding instrument enhancer and relaying all the changes to the extension's background script, where we have all the orchestration.

Before we open a monitor window, no data are relayed to the extension and no monitors are rendered. In this way the extension wouldn't have signifiant impact on the app while not using it.

We need somehow to consume monitors' reducers on the app side without rendering the monitors. Also we should keep the ability to add / remove monitors on the fly.

[khankuan]

Hmm, do you mean that because the monitor may not be launched at the start of the app, the monitor reducer might not work as expected?

[zalmoxisus]

@khankuan, we don't render monitors inside the user's app, so they are not present there at all. Applying all available monitors and hiding the rendered html just to access their reducers wouldn't be a reasonable solution I think.

[khankuan]

Hmm not sure if I got the flow correct. Could we use monitor reducers the same way as the current reducer?

[zalmoxisus]

Actually, I looked into the shift toggle implementation, and you don't need any reducers applied on the user's app side, everything should be done on the remote side monitor. We should just allow sending the changes from there to the app, which should be an easy fix in remotedev-app. I'll look into it.

The current issue is related only to filterable-log-monitor, which is for now the only monitor that we cannot support here.

To understand the flow, take a look at remote-redux-devtools. It's the same principle and it's agnostic to any monitors, because they are applied outside (it can be even on the other device).

[khankuan]

Hmm, i checked out filterable-log-monitor. Which part of it required code on user's app side?

Cheers

[zalmoxisus]

@khankuan, sorry for the late response.

actionIdToDatumMap should be generated on the user's app side and sent with the liftedState. We could include its monitor as well to get it work, the issue is only to do it only when needed, which can be addressed later if we decide to support this monitor.

Regarding the shift toggle implementation, I tried your fork and it works great now (except the issue I commented).

Give it a try and feel free to reopen the issue if you have any troubles.

[khankuan]

@zalmoxisus hmm, I updated to the latest version but it seems like this.props.dispatch does not dispatch actions with type @...

[zalmoxisus]

@khankuan make sure to update remotedev-app as well, it should be at least 0.3.1 (as specified on package.json) to support this change.

[khankuan]

I'm running on master and also tried updating to 0.3.2 but seems the same :/

[zalmoxisus]

@khankuan, strange. Just checked, replaced redux-devtools-log-montor lib with that generated from your fork, and it works well except for the error I described above that makes it to work only first time.

[khankuan]

I've fix the issue you've described here :)
gaearon/redux-devtools-log-monitor@5b0c7bb

[zalmoxisus]

👍 Tested and it works now without any issues.

Check inside node_modules/remotedev-app whether this change is present and to log what is being dispatched. Also check if the extension receives this and dispatch inside the app.