Define a meta object on an action

I have a middleware that looks for actions that have a special property. In classic Redux I normally added a meta key to the action object, which holds information like this, e.g. meta.canUndo or meta.batched. I thought maybe the second parameter of the action() helper could be used for something like this, but as of now it seems to only support the listenTo option.

Is there a way to have static meta information on an action right now? Or is it considerable to add this in the future?

Btw: With or without a meta object - easy-peasy is an amazing library! Thank you! 😃

[allpro]

I worked around this by mixing data and metadata keys in thunk payloads. I use dedicated thunks and requests handlers for each endpoint so can customize the code to separate metadata from real data at each level. It would be nice to have a standard way to receive metadata - like as helpers.meta - but I’ve been able to work around it.

For those wanting a generic way to handle metadata, the payload param in thunks could replicate the standard action structure, like…

thunk((actions, action) => {
  const { payload, meta } = action;
  ...
})

This could be an optional pattern in common code, accepting a normal payload when metadata is not needed. This sample helper will never change the ‘payload’ value and always returns a ‘meta’ object for consistency…

const parseAction = action => ({
  payload: (action || {}).payload !== undefined ? action.payload : action,
  meta: (action || {}).meta || {},
});

function handler(action) {
  const { payload, meta } = parseAction(action);
  ...
}

A couple of ideas for anyone wanting the same metadata option as provided by the FSA action shape.

[allpro]

can’t this data be encapsulated within the payload

The Flux-Standard-Action (FSA) includes a meta key for anything that’s not part of “the payload”. In the reducer pattern below, the data returned by the API does not include a category_id, but both the API and reducer need it. The action argument contains { type, payload, meta }, but type isn’t needed here

const updateCollectionByCategoryId = (state, { payload, meta }) => {
    const id = meta.category_id
    let newState = state
    newState = set(newState, `category.${id}`, payload)
    newState = set(newState, `state.categoryDataLoaded.${id}`, true)
    return newState
}

To keep intermediate methods dumb, meta-data should be passed in a standard/generic way, just as payloads are. Without a separate key/param for this, payloads need a nested, non-standard structures, like this:

action = {
    type: "saveName",
    payload = {
        content: { first: "Sean", last" "Matheson" },
        meta: { companyId: 1234 }
    }
}

However the FSA pattern is simpler and more standard. No longer need a custom payload design.

action = {
    type: "saveName",
    payload = { first: "Sean", last" "Matheson" },
    meta: { companyId: 1234 }
}

Occasionally an API and/or reducer requires meta-data. A passed ‘action’ contains both payload and meta. If ‘payload’ becomes it’s own argument, it’s natural for meta to be the next arg. This maintains the flexibility and simplicity of the FSA pattern { type, payload, meta }. That’s my pitch!