feature/before-route-change

[TeoTN]

Implement #8 - optional parallel call to a saga before any other sagas

[jfairbank]

Thanks for the PR. Only issue is that we need to ensure that beforeRouteChange runs before the matched route saga.

[jfairbank]

By placing this in the array, it will potentially run in parallel to the matched route instead of technically running before it. We'll need to ensure that it can run first. If you need any help with this, let me know.

[TeoTN]

I have reimplemented it in a synchronous manner by adding an optional extra state. I hope that you'll like the solution :)
BTW I really enjoyed working with your code, it's extra clean and extensible.

[jfairbank]

When we hit this line after BEFORE_HANDLE_LOCATION, we will have lost reference to the location. In fact, the location argument will be equal to a task object that redux-saga will return for the spawn effect. We'll need to probably save a reference to the location. Maybe create a let currentLocation with the other let declarations above? Then HANDLE_LOCATION will have to use the currentLocation if the location argument is missing.

We'll also need another state after BEFORE_HANDLE_LOCATION. While the spawn is outside the array now, it is still a non-blocking effect in redux-saga, meaning it has the potential to run concurrently with the matched saga. If you add an additional state, you can use the join effect on the task to basically wait for the beforeRouteChange saga to finish before handling the location with the route saga.

[jfairbank]

This is a good start @TeoTN!

I left some more detail in my review comment. Please let me know if my comment makes sense. Also, working with fsm-iterator can be cumbersome, so let me know if you have any issues with the implementation. Thanks!

[TeoTN]

Thanks for your review @jfairbank! You've pointed out a few quite important things that I had overlooked.
I hope that my latest commit solves the problem, although I'm not sure whether I'm testing it properly, i.e. by passing task mock via next argument.
The fsm-iterator itself seems to be rather intuitive, at least to the extent I use it and after having seen my mistakes with the way I use it :)
I'll be waiting for the next review impatiently, thanks!

[jfairbank]

This looks good, @TeoTN. Good job!

I'll work on a release soon. Thanks!

[TeoTN]

Thanks!