Dynamically starting sagas

[tappleby]

This might have some overlap with with the runSaga idea mentioned in #13 (comment).

Currently all sagas need to be provided during startup, I am curious if it make sense to have the ability to dynamically start them.

After writing the example below I think the main use case would be larger apps that use code splitting, if you know all your sagas ahead of time its probably simpler to have watchers which fork based on dispatched actions (compatible with time travel).

---

For example if we only want the onBoarding saga to be running while in a specific section of our app it could be started/stopped with a container component:

componentWillMount() {
  this.onBoardingTask = runSaga(onBoarding, this.props.store);
}

componentWillUnmount() {
  cancelSaga(this.onBoardingTask);
}

[yelouafi]

While I understand the code splitting requirement. I tend to not agree with starting sagas from inside containers elements. Perhaps, it'd be better to start the dynamic sagas in the same place we update the store. For example, if we load some dynamic module with new reducers and sagas I can imagine

function updateAppWithNewModule(module) {
  updateStoreWithNewReducer( module.reducer )
  runSaga(module.saga)
}

FYI, I've already pushed changes in the master branch which include runSaga support (along with monitoring support).

[tappleby]

Yeah a component was probably a bad example (though I have been curious if proc could be used locally within a component to manage complex flows). I mainly wanted to show the cancelling of saga on unmount.

Starting the saga at module load time seems like the correct approach; I could see this working well with dynamic routes in react-router.

[yelouafi]

though I have been curious if proc could be used locally within a component to manage complex flows

technically yes. actually proc has a signature like (iterator, subscribe, dispatch) -> Promise. So you can hookup take and put to any external input/output (aka csp channels). But I wouldn't recommend using an internal function, as the signature may change in the future.

This is another item on my todo list. Initially, I imagined runSaga(iterator, {subscribe, dispatch}) which would work with Redux Stores out of the box. But the store doesn't actually provide the triggered action to its subscribers, and I read in a related Redux issue that this is intentional (reduxjs/redux#1057).

Another solution I m considering is keeping the generic runSaga(iterator, {subscribe, dispatch}) and exposing the utility function storeChannel so we'll end up with something like

runSaga( iterator, storeChannel(store) )

With the benefit of being able to connect the Saga to any external channel

[tappleby]

I do like the idea of keeping it generic, would remove the need for things like emitterFromStore or store enhancers mentioned in #13.

Is there a common interface that other libraries seem to be using for channel like functionality? closest thing I can think of is Rx.Subject.

[yelouafi]

Is there a common interface that other libraries seem to be using for channel like functionality? closest thing I can think of is Rx.Subject

Node duplex streams seems to mimics channel's take/put, but uses 2 independent channels reads/writes. It doesn't also use promises for communication

[yelouafi]

FYI. the new v0.4.0 supports runSaga

[tappleby]

👍

[guoqing2015]

看看这个： https://github.com/GuillaumeCisco/redux-sagas-injector