redux reducer vs action - redux

Question

Newbie question regarding reducer vs action. From redux documentation:
Actions describe the fact that something happened, but don’t specify
how the application’s state changes in response.
and
Given the same arguments, reducer should calculate the next state and
return it. No surprises. No side effects. No API calls. No mutations.
Just a calculation.
So if we consider the following scenario:
User can place points on a map and get route between those points.
When user first clicks on a map this is his starting point. When he clicks for the second time - this is his ending point. Consequent clicks add points between the previous point and end location.
After each point is added (except for the first one) route must be calculated between new point and previous point. So if i have S -> A -> F and add point B (S -> A -> B -> F) two routes must be calculated A -> B and B -> F
So we kind of have two side effects upon adding any 3+ point:
New point is placed not at the end of the list
New route must be calculated to the Finish point.
If i model my Point structure as this:
// typescript
interface Point {
coordinates;
routeTo?;
}
Am I correct to perform item position calculation and route retrieval in Actions, eg:
// pseudo code
export function addMapPoint(newPoint) {
return (dispatch, getState) => {
const {points} = getState();
const position = getInsertPosition(points, newPoint)
dispatch(addPoint(newPoint, position));
if (points.length >= 2) {
const previousPoint = getPreviousPoint(points, position);
calculateRoute(newPoint, previousPoint).then(route => {
dispatch(updateRoute(newPoint, route))
})
}
}
}
To me this somehow contradicts to the "but don’t specify how the application’s state changes" - because from action i'm specifying where to insert my new point.
I could calculate the insert position in reducer, but then how do i fetch route data for the Finish point?
What is the correct approach here?

Answer 1

Assuming we have a calculateRoute function that accepts two points, and returns a promise that resolved the route between them.
First, let's create a simple action creator so we know our points are stored correctly:
let addPoint = (point, index) => {
return {
type: 'ADD_POINT',
point: point,
index: index
}
}
Then, let's handle this action in the reducer:
let reducer = (state = { points: [] }, action) => {
switch (action.type) {
case 'ADD_POINT':
return Object.assign({}, state, {
points: [
...state.points.slide(0, action.index),
action.point,
...state.points.slide(action.index + 1)
]
});
default:
return state;
}
}
Now, after the users add a point, we create an action using addPoint and dispatch it, so far so good, but this is the easy stuff.
The structure I strive for is to have a routes list in my reducer too, so let's extend it to support that:
let reducer = (state = { points: [], routes: [] }, action) => {
switch (action.type) {
case 'ADD_POINT':
return Object.assign({}, state, {
points: [
...state.points.slide(0, action.index),
action.point,
...state.points.slide(action.index + 1)
]
});
case 'UPDATE_ROUTES':
return Object.assign({}, state, {
routes: action.routes
});
default:
return state;
}
}
And the action creator will be:
let updateRoutes = (routes) => {
return {
type: 'UPDATE_ROUTES',
routes: routes
}
}
Please notice we're overriding the entire routes collection. For now it's OK, but probably in a production system you would want to optimize it a little bit.
Now we actually need to write some logic. I will assume a convenient assumption that we have a calculateRoutes that gets a collection of points, and returns a promise that resolves a list of respective routes, each route will be an object, containing two points and the actual route. Having said that, our thunk will now look like this:
addPointAndUpdateRoutes = (point, index) => {
return (dispatch, getState) => {
// First, update the point list
dispatch(addPoint(point, index));
// Now, recalculate routes
calculateRoutes(getState().points)
.then(routes => dispatch(updateRoutes(routes));
};
};
Which is way nicer in my opinion.
Now, off course that assuming we have a magical calculateRoutes function is not a serious assumption, though it's not a super hard task to implement this function in an optimized manner (meaning actually send the server only routes that we did not calculate before, etc). BUT this is just logic and NOT the state of the application, thus, as long as you keep the "contract" defined by the store and reducers, you are free to implement it any way you'd like.
Hope this helps you.