Allow enqueued actions to access params

[customcommander]

I initially wanted to submit a bug report but figured it was probably working as intended, but it definitely caught me off guard:

import {createActor, setup, log, enqueueActions} from 'xstate';

const s = setup({
  actions: {
    foo: log((_, params) => params),               // LOG: {x: 1}

    bar: enqueueActions(({enqueue}, p) => {
      enqueue(log((_, params) => params));         // LOG: undefined (expected {x: 2})
      enqueue((_, params) => console.log(params)); // LOG: undefined (expected {x: 2})
      enqueue({type: 'foo', params: p});           // LOG: {x: 2}
    })
  }
});

const m = s.createMachine({
  on: {
    log: {
      actions: [
        {type: 'foo', params: {x: 1}},
        {type: 'bar', params: {x: 2}}
      ]
    }
  }
});

const a = createActor(m);
a.start();
a.send({type: 'log'});

Considering that enqueue({type: 'foo', params: p}) does work, it seems to me that it should be possible (in theory) to pass around params in the actions objects as well.

What do you think?

[davidkpiano]

I think this makes sense for what you want to do, but on the other hand, explicitly passing the parameters would be more clear 🤔

[customcommander]

This post came about after hours of debugging until I figured out what was going on:

enqueueActions(({enqueue, context, event}, params) => {
//                        ^^^^^^^^^^^^^^   ^^^^^^
//        (same thing)    |                | (different)
//          +-------------+  +-------------+
//          |                |
//          vvvvvvvvvvvvvv   vvvvvv
  enqueue(({context, event}, params) => {
  });
});

XState does implicitly (?) pass on things like context and event and I simply expected it would do the same with params.

After sleeping on it, I think it all makes sense now.

This:

{
  entry: {
    type: 'foo',
    params: {
      x: 1
    }
  }
}

Is the same as:

enqueue({
  type: 'foo',
  params: {
    x: 1
  }
})

But these params are for the foo action only and not for any hypothetical top-level enqueueActions action (and vice versa).

So yeah, being explicit about passing params (or not) definitely makes things clearer.

Anyway thanks a lot for XState, I absolutely love it <3

[with-heart]

XState does implicitly (?) pass on things like context and event and I simply expected it would do the same with params.

I think a slight improvement to your mental model here would be to think of the first argument as the current state of the actor rather than things being passed on. Enqueued actions receive the same context, event, etc. because they're part of the current state of the actor while params are specific to that action.

If you think about it that way, it makes sense that params isn't passed on to enqueued actions in the same way that it wouldn't make sense to pass params to some other action that doesn't have a params argument (or a different params type).

Edit: I think you basically said the same thing but with less words. Helps to read someone's whole post before commenting 🙃