-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
add hasModule API #833
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
Comments
You can wait for Optional Chaining Operator to get into babel and use that instead. Looks like ES Committee likes the idea and is going to be discussed at the next meeting again. |
I am talking about vuex store modules |
But if you add or remove modules dynamically, you should be able to add a property like |
I try to make any Component to support ssr (not only route components). eg. with hypothetical
|
I see. Still, adding a custom property to the module should work to check if it has been installed |
yes, but who holds the reference to the module ? (Furthermore, it is quite common to have foo.add(), foo.remove() and also foo.has(), imagine a world without the javascript |
This is what I'm saying: import module from './module'
if (!module.registered) store.registerModule('m', module)
module.registered = true The |
ok, but this will break my progressive app, since this code will also run server-side |
why? |
server-side, module.registered will always be true (except the first time of course) |
Well, isn't that the point? Registering only once? |
yes |
@ktsn Does it makes sense to add a module twice? |
(FYI, see PR #834) |
@posva Adding I'm not sure why we still need |
As explained in previous comments, on server-side rendering, modules are shared between all sessions |
I don't think we're in sync here... Wasn't that the point? Do you need to run every request in a new context, at least by user or similar? |
On the server-side (ssr), I process my requests in the same context (runInNewContext: false) this mean that every vuex modules definition will be shared between all the users that access to my application. If I set a flag in the module (eg. registered = true), this flag will be true even it the module has not been registered ! |
As you supposed before, the point is: Registering only once by vuex instance, that is equivalent to:
|
I'm actually not sure about SSR but it makes sense for me. But wouldn't it be better to add like |
It is true that ignoreIfExists option is less verbose than hasModule + registerModule, however, hasModule allow to check module existence before defining it, and this may save performance in the case where initial module data is not static, eg.
In this case, the module will be completely setup but never used (except the first time) |
Makes sense. Let's move on your PR 🙂 |
Hi @FranckFreiburger , what was your workaround? |
Hi,
Note that is is not polished/optimized, it's just a workaround. |
ping! |
Has this proposal gained any traction? |
It is necessary to check private (prefixed with _) properties of the Vuex store, because currently there is no other way of how to check if a component was already registered. See vuejs/vuex#833 Fixes #1
This works for me: if(!me.$store._modules.root._children[`module-name`]) {
me.$store.registerModule(`module-name`, {
...
});
} |
Bahaha I'm with @jcgalindo. The data is definitely there, exactly as he describes, but it's definitely an obtuse data structure. Feels like we're writing Java or something. Oh well, it gets the job done for now. Interestingly you could also do this, which is a little less verbose but should be every bit as reliable: if(!me.$store.state[`module-name`]) {
me.$store.registerModule(`module-name`, {
...
});
} |
I have extended the good solution of @FranckFreiburger to support nested namespaces:
Deep checking Edit: this doesn't work if a module wasn't registered through this extension. Using the answer below yields this:
|
This is my solution : /**
* Check registred module
* @param {Array} aPath - path to module - ex: ['my', 'nested', 'module']
* @return {Boolean}
*/
Vuex.Store.prototype.hasModule = function (aPath) {
let m = this._modules.root
return aPath.every((p) => {
m = m._children[p]
return m
})
} Enjoy ! |
Is there a plan to include this in the core library? |
@KRaymundus Because Edit: It's probably easier explaining with code: Vuex.Store.prototype.registerModuleOnce = function registerModuleOnce(path, rawModule, opts) {
// Path can be an array or a string: ['my', 'nested', 'module'] or 'my/nested/module'
const pathArray = path instanceof Array ? path : path.split('/');
if (this.hasModule(pathArray)) {
return false;
}
return this.registerModule(pathArray, rawModule, opts);
};
Vuex.Store.prototype.hasModule = function hasModule(pathArray) {
let m = this._modules.root;
return pathArray.every(p => {
m = m._children[p];
return m;
});
}; |
Any updates on this? |
Not yet seems like. This is pretty old issue, though I don't think we came to any conclusion yet. @ktsn Do we want this feature...? Or should we be closing it? |
Hi, folks! I need this feature too. |
#834 is merged. |
@ktsn When do you expect an npm release ? |
What problem does this feature solve?
When adding/removing modules dynamically, it is sometimes mandatory to know if a module has already been added.
What does the proposed API look like?
Store#hasModule(path)
The text was updated successfully, but these errors were encountered: