release the saga monitor store + selectors as a separate package

[yelouafi]

Releasing the non UI separately would benefit to to other redux devtools. the monitor's selectors could present normalized data into multiple forms (effects by parent/child relation, by action/reaction, task fork/join relation, channels inter-communication etc)

[zalmoxisus]

According to the README it will endup as a browser extension and could be integrated with Redux DevTools extension as well. As the extension is in a separate process, we'll have to stringify the data from the client side everytime to get it there. So there're 2 possible implementations:

1. To add a subscribe callback to saga monitor store, and whenever it is changed, send the state to the extension. To implement that, we'd have to remove connect from the current containers and pass the state from the root container as a prop we can change.
2. Pass a custom dispatch callback to createSagaMonitor, which will get the actions and will just send them to the extension, and dispatch them there.

[yelouafi]

The saga monitor uses its own internal store (not the app store). The monitor is connected to the saga middleware and receives monitor events directly from it (not via redux actions).

But there maybe still an issue because monitor events may contain non serializable data (mainly functions & symbols)

[zalmoxisus]

@yelouafi, yes, because the store is independent we are able to implement it on the extension side and just pass actions from the client side. We can serialize functions, symbols and other special types as Redux Extension does, just it will be slower.

[zalmoxisus]

Basically, we'll pass a custom dispatch to createSagaMonitor from client side like:

const dispatch = (action) => { window.postMessage(action, '*') }

So, effectTriggered, effectResolved... will just call this function instead of store.dispatch.

Then on the extension side we're getting the action and do store.dispatch(action).

[zalmoxisus]

The problem is that parsed objects would be different here. I guess we should somehow add action id here and compare ids. This would also allow not to include the action payload in the effects multiple times, which could be huge for serialization.

[yelouafi]

the action object is stored from here. We also compare by ref here to find sagas who took an action.

If a unique id should be assigned to actions, I think it should be done on the redux-saga side because actually the saga monitor (residing in the extension process) will see 2 different objects (one in actionDispatched and another in effectResolved for take effects).

Another possible way (perhaps) is for the saga monitor to use the fact that effectResolved for take effects will occur immediately after an actionDispatched events. So when we get an effectResolved for takes we could assume it relates to the lasted dispatched action and save the info directly to the store (instead of computing it in demand)

[zalmoxisus]

Another possible way (perhaps) is for the saga monitor to use the fact that effectResolved for take effects will occur immediately after an actionDispatched events...

If that would work, it would be awesome. We could add a parameter with a custom createActionId which would return the action ID from Redux DevTools lifted store. So, we could select effects for actions right from Redux Monitor.