Request descriptor's payload/meta functions not passed the parsed action

[mattlubner]

It looks like the request type descriptors' payload and meta functions are being passed the raw, top-level RSAA as the action argument, instead of an action with parsed values.

For instance, if we take the example from the README:

// Input RSAA
{
  [RSAA]: {
    endpoint: 'http://www.example.com/api/users',
    method: 'GET',
    types: [
      {
        type: 'REQUEST',
        payload: (action, state) => ({ endpoint: action.endpoint })
      },
      'SUCCESS',
      'FAILURE'
    ]
  }
}

The documentation implies that the above RSAA action should result in the following FSA request action being dispatched:

// expected…
{
  type: 'REQUEST',
  payload: { endpoint: 'http://www.example.com/api/users' },
}

Instead, the dispatched FSA request action has an empty object as it's payload:

// actual…
{
  type: 'REQUEST',
  payload: {  },
}

Cause

This is because the payload function is being passed the unparsed, top-level RSAA action here:

// We can now dispatch the request FSA
if (
  typeof requestType.payload === 'function' ||
  typeof requestType.meta === 'function'
) {
  //          top-level [RSAA] action ⌄⌄⌄⌄⌄⌄
  next(await actionWith(requestType, [action, getState()]));
} else {
  next(requestType);
}

Based on the docs, I was expecting the following:

// We can now dispatch the request FSA
if (
  typeof requestType.payload === 'function' ||
  typeof requestType.meta === 'function'
) {
  const parsedAction = {
    ...action[RSAA],
    method,
    body,
    headers,
  };
  next(await actionWith(requestType, [parsedAction, getState()]));
} else {
  next(requestType);
}

This behavior appears in both the master and next branches.

I'd be happy to submit a PR, if this is indeed a bug.

[nason]

Nice catch @mattlubner -- thanks for the detailed issue 🖖

You're right it is getting the entire RSAA now, so something like this should work:

payload: action => ({ endpoint: action[RSAA].endpoint })

I'm not sure it's a bug, unless there is a different action that makes more sense here. Either way, we should update the docs / that example!

[mattlubner]

No problem, happy to help! I do think the best thing to do would be to adjust the action that those request type descriptor functions are called with.

If we have an endpoint that needs data from the store, we have to do something like this:

{
  [RSAA]: {
    endpoint: state => `https://example.com/api/users/${state.user.id}`,
    method: 'GET',
    types: [
      {
        type: 'REQUEST',
        payload: (action, state) => ({ endpoint: action[RSAA].endpoint(state) })
      },
      'SUCCESS',
      'FAILURE'
    ]
  }
}

I think it would be better if those descriptor functions were passed the pre-parsed values for a given action, so that the developer doesn't have to know internal details of how the RSAA middleware invokes these other functions (such as action.endpoint).

Just my 2¢! 🙂

[mattlubner]

If that change would be welcome, I'd be happy to submit a PR for it.

[nason]

@mattlubner thanks for the clarification! Ah I see -- the meta properties on a REQUEST_TYPE action should be the resolved values, not the functions passed to this middleware to generate them. Is that the same page you're on? Makes sense to me!

I think v3 is going to ship without this change, but I'm open to this change in a future release