Resolve thunks about redux-promise-middleware HOT 13 CLOSED

Why isn't it possible with a resolved thunk?

from redux-promise-middleware.

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.

from redux-promise-middleware.

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

from redux-promise-middleware.

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.

from redux-promise-middleware.

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).

from redux-promise-middleware.

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

from redux-promise-middleware.

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

from redux-promise-middleware.

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 }}
    };
}

from redux-promise-middleware.

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.

from redux-promise-middleware.

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 ?

from redux-promise-middleware.

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.

from redux-promise-middleware.

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

from redux-promise-middleware.

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

from redux-promise-middleware.