Resolve thunks

[pburtchaell]

With the release of 3.x and the inability to resolve thunks, the new API makes it more difficult to modify actions.

From @tomatau's comments on the original 3.0.0 PR:

how would I change the meta value between the pending and fulfilled actions? e.g. I want a special meta value only for the fulfilled but not pending or rejected.

We could either add the ability to resolve thunks or look into other options, such as DSL or a modify hook.

Problem: resolving thunks is not possible

// You can't do this
const actionCreator = () => ({
  type: 'BAR',
  payload: {
    promise: myAsyncAction().then((resolved) => 
      (action, dispatch) => {
        dispatch({ ...action, payload: { ..resolved }, meta: { broadcast: true } })
      }))
   }
});

Solution A: DSL

// example with regular meta that is dispatched in each action (pending, fulfilled/rejected)
{
  type: 'FOO',
  meta: {
    // ...
  }
}

// example with meta for each action
{
  type: 'BAR',
  meta: {
    pending: {
      // meta properties for pending action
    },
    fulfilled: {
      // meta properties for fulfilled action
    }
  }
}

Solution B: Modify Hook

A modify hook that can be supplied that sits between the resolved promise and dispatch so that the action can be modified.

const creator = () => ({
  type: 'BAR',
  payload: {
    promise: myAsyncAction(),
    modify: (action) => {
      // other logic?
      return { ...action, meta: { broadcast: true } }
    }
  },
})

[tomatau]

Why isn't it possible with a resolved thunk?

[pburtchaell]

Why isn't it possible with a resolved thunk?

Resolved thunk functionality was removed from the middleware because of the issues caused, e.g., issue #61. Perhaps I am misunderstanding though?

PS: Sorry for the delay. It has been a busy week.

[tomatau]

I don't follow. This issue is all about resolving objects but thunks are resolving functions, they shouldn't overlap?

[tomatau]

I've made a fork with a branch that keeps the thunk behaviour and also returns the original promise unmodified.

The original error always gets thrown, because it's the original promise. The middleware just creates a new promise internally for creating rejected actions.

Even errors that previously got swallowed (e.g. component errors as the result of an async dispatch) now propagate up.

https://github.com/tomatau/redux-promise-middleware/blob/another-implementation/src/index.js

I've updated the tests on this fork branch too.

[pburtchaell]

Since this is preserved in v2 and you have been maintaining that release, I am going to close this. Maybe you should add a note to the README though (about v2 enabling you to use thunks).

[tomatau]

I would really like to see a solution for this in a latest release -- I'm currently getting warnings from version monitoring systems that say I'm out of date with this middleware (and npm outdated isn't as pretty as it could be) :P

[pburtchaell]

I'm fine with adding it to v3. Do you have time to commit to implementing it in v3?

[rluiten]

I think I understand what you want to achieve and I did it this way.
I am using post() and get() from axios package at moment which is promise based.
I added a then(val) handler to this example, so that fulfilled results get an extra conditionFlag field set.

const OBSERVATION_COMMENT_SAVE = 'OBSERVATION_COMMENT_SAVE';

//
// In this I am capturing the comment.id and making it available on the
// rejected promise result value. This way my reducer has the info.
//
// For my case at least comment may be new and have id === 0.
// My reducer still gets that value.
//
export function saveComment(
    comment,
    newCommentText,
) {
    const { id } = comment;
    const url = id
        ? `${apiUrls.comment}/${id}`
        : `${apiUrls.comment}/`;
    const promise = post({
            url,
            data: {
                id,
                comments: newCommentText
            }
        })
        .then((val) => {
            if (myConditionFlag) {
                val.conditionFlag = true;
            }
            return val;
        });
        .catch((errorVal) => {
            if (id) {
                errorVal.id = id;
            }
            return Promise.reject(errorVal);
        });

    return {
        type: OBSERVATION_COMMENT_SAVE,
        payload: { promise, data: { id, comments: newCommentText }}
    };
}

[tomatau]

This doesn't solve the problem of modifying the meta information for _FULFILLED only.

Imagine you have an app that is connected through sockets and you have a middleware that listens for actions. When an action has a meta with { broadcast: true } you wish to broadcast this action and play it over all other clients connected to the socket. Now - you don't want to play all the pending or rejected actions to everyone as that's sometimes just not very useful... but you do want to broadcast the fulfilled actions!

Thunks solve this problem.

The solution already exists and is working fine in v2.

[rluiten]

If you modify .catch(errorVal) in example and use .then(val) and modify val it will modify metadata returned - I modified the example above to include a .then(val) handler to demonstrate.

I think maybe I still don't fully understand the use case you are describing from your most recent comment though, though I think now that any middleware after the action creator should be able to pick up the flag on a FULFILLED state ?

[tomatau]

The socket middleware reads meta data, not the action type - this is by design as we want to be explicit about the actions that are broadcast.

Your example modifies the payload, not the meta. Anything resolved by the promise is used to populate the payload.

A Flux Standard Action has the shape:

{
  type: string,
  ?payload: any,
  ?meta: object,
  ?error: bool
}

v3 and v4 of redux-promise-middleware take the meta from the original action shape and apply it both the _pending and _fulfilled or _rejected without the capability to modify per type.

[artemjackson]

You can normally live without thunk resolving feature, see the example: #43 (comment)

[tomatau]

@artemjackson not sure I follow, the example you posted is resolving with a name and a thunk!.. :)