8

I'm a bit confused with what unregisterModule is actually doing.

If we have a module like so:

{
    state: {
        page: 1
    }
}

Then un/register it dynamically:

beforeCreate() {        
    this.$store.registerModule('items', store);
},

beforeDestroy() {
    this.$store.unregisterModule('items');
},

If we make a change to page navigate a way (which triggers unregister) then navigate back.

It seems the state persists? I would think unregister completely kills the module and all data, states, etc?

I can make the state a function like so:

{
    state() {
        return {
            page: 1
        }
    }
}

But, then it still doesn't change the question then of what does unregisterModule actually do then?

Also does it mean I would either have to change all my state objects into functions or have some kind of reset method on unregister. This seems quite pointless, what am I missing here?

Rob
  • 10,851
  • 21
  • 69
  • 109
  • one example i use it. its in tabs. i have tabs which can create dynamicly. each tab has its own module where all the state is saved. now when the user delete the module i need to unregister the module. and when the user create tab i need to dynamic create a module for it. and about the function state. the diffrence is when you use it as function. each module you will create will have its own state. just like the data components – eli chen Jul 04 '19 at 19:59
  • Are you shure that beforeDestroy method is called? Vue-router reuse components when only dynamic params was changed: https://router.vuejs.org/guide/advanced/navigation-guards.html#in-component-guards – Alexandr Vysotsky Jul 12 '19 at 10:30
  • There could be a use where a module is generated from an API call, then registered. It would require a call to `unregisterModule` when making a subsequent API call (to modify the module). Still struggling to fit that into a real-world scenario. –  Jul 12 '19 at 21:19

1 Answers1

8

unregisterModule removes the module and you cannot access it.

The state doesn't persists but you have to use the state as a function

From docs:

If we use a plain object to declare the state of the module, then that state object will be shared by reference and cause cross store/module state pollution when it's mutated.

This is actually the exact same problem with data inside Vue components. So the solution is also the same - use a function for declaring module state.

See it live on codesandbox:

  • In Home page (the module registers), increase the counter
  • In About page (the module is unregistered)
  • In Contact page we re-register the module.
  • Observe that the counter is NOT persisted.
Community
  • 1
  • 1
Roland
  • 24,554
  • 4
  • 99
  • 97
  • 2
    I guess the question is, what is the advantage of not having the module accessible? –  Jul 11 '19 at 22:25
  • 1
    I don't think that is the question, but if so, then it's really simple. Say you have a vuex module which is used ONLY in Home page. Why to have that module accessible in all other pages? You will end up having dead code. Read more -> https://itnext.io/vue-js-app-performance-optimization-part-3-lazy-loading-vuex-modules-ed67cf555976 – Roland Jul 12 '19 at 05:23
  • 1
    After a bit more experimenting I'm seeing it better now. So basically "unregister" will keep that store/modules data from being available "globally". However it still keeps the data (state) in memory? My concern here is then that every module/state I load up never gets released from memory? I would think that there maybe needs to be two methods then `unregisterModule` and `deleteModule`, something like that. But I guess I don't see anything in the docs about a "delete". Or am I missing something further here? @roliroli – Rob Jul 12 '19 at 10:20
  • @HiramK.Hackenbacker yes this is a good question as well. If by design the data is never deleted. But I can see it just being a matter of private/public data, so that things don't get abused. – Rob Jul 12 '19 at 10:21
  • @roliroli fyi `this.$store.commit('module/clearState')` you don't need to do that if you return the state as a function (show in my original question). – Rob Jul 12 '19 at 10:23
  • Not convinced, turning off a module per page is at best a development-time feature. Not worth the extra code and testing. As for lazy loading (the article you referred), the sample given does not illustrate that very well. –  Jul 12 '19 at 21:13
  • @Rob, maybe setting a module's root state to `null` would allow garbage collection of data? –  Jul 12 '19 at 21:30
  • But the code is controlled (say) by webpack, so not sure it would be released from memory when unregistered. –  Jul 12 '19 at 21:31
  • IMO this is a design flaw. if a module unregister API is provided, it should make sure the state is cleared at that moment or at least when registering it again. – João Melo May 25 '22 at 13:10