Remove "context" from "enqueueActions".

[phcoliveira]

Good design is about making good choices easy and bad ones hard, right?

So, the action creator enqueueActions makes a bad choice to be easy. Consider this:

increment: enqueueActions(({ context, enqueue }) => {
  enqueue.assign({
    count: context.count + 1,
    previous: context.count,
  });

  enqueue.sendTo('logger', {
    type: 'incremented',
    data: {
      count: context.count,
      previous: context.previous,
    }
  });
})

So, what will be sent to logger? The original values of count and previous when the action was fired, or the updated ones after assignment?

Such action would be more clear like this:

increment: enqueueActions(({ enqueue }) => {
  enqueue.assign({
    count: ({context}) => context.count + 1,
    // still the same context from the live above, right?
    previous: ({context}) => context.count,
  });
  

  enqueue.sendTo('logger', {
    type: 'incremented',
    data: {
      // new context after enqueue.assign
      count: ({context}) => context.count,
      // the same context from the line above, right?
      previous: ({context}) => context.previous,
    }
  });
})

So, what do you think?

[nightire]

What if you want to pass the previous context to the "logger" event? For example, log the old value just before it changes.

The simple solution is to save a copy of the previous context. Thus, whether the context has already been updated or not, you always have the opportunity to access the value before the change.

Even if we actually want to pass the updated value to the "logger" event, we can still pre-calculate it before calling the assign & sendTo. Old value or new value, you decide.

However, with your suggestion, it seems impossible to access the previous value in the sendTo action. Correct me if I'm wrong.

[phcoliveira]

What if you want to pass the previous context to the "logger" event? For example, log the old value just before it changes.

@nightire, the first question is easy: just send the "old (original)" value before the assign action.

increment: enqueueActions(({ enqueue }) => {
  enqueue.sendTo('logger', {
    type: 'incremented',
    data: {
      // original context before any changes
      count: ({context}) => context.count,
      previous: ({context}) => context.previous,
    }
  });

  enqueue.assign({
    count: ({context}) => context.count + 1,
    previous: ({context}) => context.count,
  });
})

Even if we actually want to pass the updated value to the "logger" event, we can still pre-calculate it before calling the assign & sendTo. Old value or new value, you decide.

I don't see the need to precalculate anything. I think we should always trust the last updated context at hand.

increment: enqueueActions(({ enqueue }) => {
  let originalContext; // if you really need it for some reason.

  // sending to logger before assignment
  enqueue.sendTo('logger', {
    type: 'incremented',
    data: {
      count: ({context}) => {
        originalContext = context;
        return context.count;
      },
      previous: ({context}) => context.previous,
    }
  });

  enqueue.assign({
    count: ({context}) => context.count + 1,
    previous: ({context}) => context.count,
  });

  // sending to logger after assignment
  enqueue.sendTo('logger', {
    type: 'incremented',
    data: {
      count: ({context}) => context.count,
      previous: ({context}) => context.previous,
    }
  });
})

However, with your suggestion, it seems impossible to access the previous value in the sendTo action. Correct me if I'm wrong.

Not really impossible, as I have demonstrated above with the usage of originalContext. Just more difficult, as I believe it should be. As I said above, good choices should be easy, bad choices should be hard. A good choice is to always resort to the last updated context, because that is most likely what you want. But, if you really need to use original context at all times, regardless of the actions you make, then it should be explicit (hard).

[nightire]

I can see your points. That's fair enough. Personally, I'm okay with both solutions, they're not that obviously good or bad to me.
The need to "use original context" does not mean "bad choices", so it should not be harder than accessing the updated context. But it is only my opinion.