Allow action subscribers to catch rejections.

[jmplahitko]

Enhancement request to allow Vuex plugins to subscribe to rejected action promises.

[kiaking]

This is kinda interesting. Could you elaborate a bit more on specific use case for the feature? What might plugin just do by catching this error instead of letting users handle it?

[jmplahitko]

@kiaking - Sure. Since actions are asynchronous, it's helpful to delegate tracking of which actions are "outstanding" to an outside source. This can drive a number of UI features like spinners, progress bars, etc, especially when actions ultimately result in an http request that blocks user interaction: "While this action is outstanding, do this thing (spin, etc..)". Vuex plugins would work great for this, except for when http calls (in this use case) result in a rejection. The action never gets resolved as far as the plugin is concerned. While rejections could be handled by the caller, this gets unwieldy to do on a case-by-case basis in a large system.

Aside from this use case, it seemed like a missed opportunity to allow for subscribers to know when an action resolve, and not when it rejects. It implies that subsequent events only need to occur on the happy path, and not on the sad path.

I can discuss further if needed.

[kiaking]

Thank you for the detailed explanation! Yeah it make sense. Also there was other issues wanting to have this feature as well.

@ktsn What do you think? I think it would be nice have a dedicated error handling hook on subscribeAction. If this is the way to go, I think we can further discuss on implementation details (like maybe we shouldn't throw at the end to avoid a braking change).

[ktsn]

Yeah, this is something we should support, I think.

[kiaking]

@jmplahitko Please remove dist folder from the commit. Also, could you check the comment I made?

[kiaking]

Let's not throw here since this is technically a breaking change.

[jmplahitko]

@kiaking - I was not aware this was a breaking change, as existing tests pass with the throw. Without throwing here, the catch handler on the original dispatch call does not get called, which actually breaks an existing test in store.spec.js 'detect action Promise errors'. Am I missing something here? Let me know how to proceed.

[jmplahitko]

@kiaking - Understand the dist folder, but please advise on the comment I added after yours regarding the throw.

[jmplahitko]

@kiaking - I figured out how we can keep dispatch catch handlers in tact and not throw the error, but I got a little confused about removing dist from the commit 🗡️ - Is there a particular git strategy you prefer for this?

[kiaking]

Added 2 more comments due to some change in the latest commit.

[kiaking]

Please change process.env.NODE_ENV !== 'production' to __DEV__. This change was introduced in the latest commit.

Suggested change

	if (process.env.NODE_ENV !== 'production') {
	if (__DEV__) {

[kiaking]

This one as well.

Suggested change

	if (process.env.NODE_ENV !== 'production') {
	if (__DEV__) {

[kiaking]

I figured out how we can keep dispatch catch handlers in tact and not throw the error, but I got a little confused about removing dist from the commit 🗡️ - Is there a particular git strategy you prefer for this?

Thanks a lot! You could revert the commit by cherry picking, but, as I commented about some latest change, it might be cleaner to create a new PR from the latest dev branch.

[kiaking]

@jmplahitko Sorry for splitting the comments. Also could you rename catch to error? There was a discussion about the naming for the option at #1558.

const waitPlugin = (store) => {
  store.subscribeAction({
    before: (action) => {
      console.log(action.type);
    },
    after: (action) => {
      console.log(action.type);
    },
    error: (action, error) => {
      console.log(action.type);
    }
  });
};