vuejs / vuex

🗃️ Centralized State Management for Vue.js.
https://vuex.vuejs.org
MIT License
28.42k stars 9.58k forks source link

Switching to a nested route is automatically running the last commit event from parent's store #1593

Open farazshuja opened 5 years ago

farazshuja commented 5 years ago

Version

3.1.0

Reproduction link

https://codesandbox.io/s/vue-template-c2gtb

Steps to reproduce

  1. Open https://codesandbox.io/s/vue-template-c2gtb
  2. Click on 'Go to Page with nested router' link
  3. Click on 'commit event', it will show an alert box
  4. Now change the nested route by clicking 'change nested route to reporting'

What is expected?

Route changed to reporting without showing the 'hello' alert box.

What is actually happening?

Its showing the 'hello' alert box again.


One of the releated issues https://github.com/vuejs/vuex/issues/1570

LinusBorg commented 4 years ago

There's no commit triggered - the getter is re-evaluated. Which happens because regsitering a module forces vuex to re-build the whole state object, which triggers all getters that have deps to re-evaluate.

This is currently required by the implementation of vuex, and we can't really change this, at least I am not aware of any ideas of how to improve his behaviour to not have this side-effect. We can probably solve it with the better reactivity in Vue 3, but not for the current version using Vue 2

The best thing to do is to check in your watchers if the state actually changed:

watch: {
    event: {
        handler(newVal, oldVal) {
           if newVal === oldVal return
            switch (this.event.id) {
                case 'new_requirement': {
                    alert('hello');
                    break;
                }
                default:
            }
        },
    },
},
kiaking commented 4 years ago

@farazshuja Hi! Do you have any updates on this issue? Does comment from @LinusBorg work for you?

farazshuja commented 4 years ago

@kiaking Yeah, for now its the only way to go!!

kiaking commented 4 years ago

OK, thank you for the confirmation! While this could be a bit confusing, let's improve this in new version of Vuex.

ReinisV commented 1 year ago

The best thing to do is to check in your watchers if the state actually changed

@LinusBorg this is not a solution if you are deep watching an object reference, as both newVal and oldVal will be the same instance and thus exactly equal in both cases, when an actual change has happened to the object by changing some field, and when the watcher is triggered due to vuex rebuilding its state.

Lets say you have two submodules:

1 contains a filter object that is used for filtering data in a table, there is a watcher watching it for changes to automatically requery data for the table.

2 contains data for a modal on the same page, it is registered when the modal is opened and it is deregistered when the modal is closed.

So now every single time the modal is opened or closed (and thus submodule is registered or deregistered) will trigger a backend call to refresh the table, even though tables filter hasnt changed, and theres no way around that.

that is absolutely awful.

is there maybe some kind of a way to hook into dependency management and make it skip watchers when vuex state is being rebuilt due to a new submodule?

also, does Pinia fix this? this is the kind of breaking behaviour that would force me to say goodbye to Vuex and move to Pinia.

weier910 commented 1 year ago

你的邮件我已收到!

ReinisV commented 1 day ago

also, does Pinia fix this? this is the kind of breaking behaviour that would force me to say goodbye to Vuex and move to Pinia.

exactly a year after asking this question, I have moved my project to Pinia, and can say, yes, that Pinia removes this problem, by simply not having modules at all.

remember, this issue is when registering/deregistering a submodule to a store, but Pinia doesnt have a concept of submodule, only stores.

there is also no real way of dynamically creating and registering stores (or multiple instances of them at the same time), but that is something that can be resolved in Pinia user land with factory functions.

anyway, since then I have learned that Vue watchers come with a lot of caveats around how they work, adding deep equality checking for objects, etc, etc, so you really need to be careful with these things and sometimes it might even be better to just trigger the action you want manually instead of using a watch (those updates are no longer as easy to find, as the concept of mutations has been removed from Pinia, but oh well).

I think this issue can be closed as wont fix, because Vuex is out of active development, and this, as noted above, is actually implementation working as intended.