Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide option to exclude or explicitly list watched properties #108

Open
davidje13 opened this issue Nov 11, 2020 · 0 comments
Open

Provide option to exclude or explicitly list watched properties #108

davidje13 opened this issue Nov 11, 2020 · 0 comments

Comments

@davidje13
Copy link

I have just encountered a situation where I managed to get an infinite loop due to updating vuex state as part of an asynchronously computed property. In fairness I realise this is against the Vue principles but it is the only way I know of to display a global loading indicator.

The basic setup:

asyncComputed: {
  async thing() {
    console.log('beginning');
    const loadId = {};
    this.$store.dispatch('beginLoad', loadId);
    try {
      await new Promise((resolve) => setTimeout(resolve, 1000);
    } finally {
      this.$store.dispatch('endLoad', loadId);
    }
    console.log('ending');
    return 1;
  },
}

Store setup:

new Vuex.Store({
  state: { loader: [] },
  mutations: {
    BEGIN_LOAD: (state, id) => { state.loader.push(id); },
    END_LOAD: (state, id) => { state.loader.splice(pos, state.loader.indexOf(id)); },
  },
  actions: {
    beginLoad({ commit }, id) { commit('BEGIN_LOAD', id); },
    endLoad({ commit }, id) { commit('END_LOAD', id); },
  },
}

This results in an infinite loop, where the next call is made before the first has entirely finished;

beginning
beginning
ending
beginning
ending
beginning
ending
[...]

It appears to be caused because the change to the loading state at the end triggers a new update.

I would like to be able to explicitly remove the $store as a watched variable, or explicitly list the properties I actually care about. I can achieve this with shouldUpdate by storing previous variables and checking if anything I care about changed, but that makes shouldUpdate change state which is also not good (and makes any explicit update() calls stop working).

If this is not a use-case you want to support, I suggest at least making sure there are not two invocations in-flight at the same time; if inputs change, it should wait until the current request has finished before starting a new one

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant