I am trying to get better understanding of what the "context" object is in Vuex.
The context object is referred to numerous times in the Vuex documentation. For example, in https://vuex.vuejs.org/en/actions.html, we have:
Action handlers receive a context object which exposes the same set of
methods/properties on the store instance, so you can call
context.commit to commit a mutation...
I understand how to use it, and also that we can use destructuring if we only want to use the "commit" from the context object, but was hoping for a little more depth, just so I can better understand what is going on.
As a start, I found a couple ~8.5 year old posts on the "context object" as a pattern:
what is context object design pattern? and
Can you explain the Context design pattern?
However, specifically to Vuex, I'd love a better understanding of:
What is the context object / what is its purpose?
What are all the properties/methods that it is making available to use in Vuex?
Thank you!
From the documentation you pointed out you can read:
We will see why this context object is not the store instance itself when we introduce Modules later.
The main idea of the context object is to abstract the scope of the current Module. If you simply access store.state, it will always be the root state.
The context object of actions and its properties/methods are described here in the source code and also referenced in the API documentation
Here is the list:
{
state, // same as store.state, or local state if in modules
rootState, // same as store.state, only in modules
commit, // same as store.commit
dispatch, // same as store.dispatch
getters, // same as store.getters, or local getters if in modules
rootGetters // same as store.getters, only in modules
}
As a start, I found a couple ~8.5 year old posts on the "context object" as a pattern ...
I think you're reading into it too much.
I don't think the Vuex docs is referring to some specific kind of "context object" that is known and defined elsewhere, they just mean that the object that is passed to action handlers (and in other situations as described in the docs) is a custom object which they refer to as a "context" object by their own definition.
The reason why they provide this object is because it contains properties that are specific to the module for that particular action handler.
according to the source code of vuex, context is just a literal object with some properties from local, and other properties from store.
Related
I have set up a rather large Vuex project with multiple modules.
https://vuex.vuejs.org/en/modules.html
To grab the example of a getter a getter from a search module could be addressed like so:
computed: {
filters() {
return this.$store.state.search.filters;
}
}
Because I need to access the state of the module by referencing the search property in my property chain do I still need to namespace my module?
The documentation states the following:
By default, actions, mutations and getters inside modules are still
registered under the global namespace - this allows multiple modules
to react to the same mutation/action type.
https://vuex.vuejs.org/en/modules.html#namespacing
But if the module is under its own property in the store isn't the only conflict that could happen between modules themselves, which can easily be prevented by a simple naming convention of the files?
What am I missing here?
But if the module is under its own property in the store isn't the only conflict that could happen between modules themselves, which can easily be prevented by a simple naming convention of the files?
No, you misunderstand. The state itself is properly namespaced, but mutations, actions and getters are still collected on a global level so you can e.g. dispatch one Action and several actions from different modules react to it.
That's the default behavior, but the good news is, that there's an option to namespace mutations, actions and getters: "namespaced: true".
it's documented here: https://vuex.vuejs.org/en/modules.html#
Scroll down to the "Namespacing" section.
As I am trying to play with evolutionary algorithms and building visualization tools of the process, I'd like to use VueJs with P5Js.
I have this code: (SO) Playing with Evolutionary Algorithms on Codepen.io
The problem is that Vue instance's data population does not update properly.
Here what I tried to do:
Pass the global objet Game as Vue instance's data. Then population get updated properly, but the data is so big that everything get laggy;
Populate Game.population array when declared, but it does not work: P5JS throw me an error createVector() is not defined;
Populate Game.population array in Vue instance's beforeCreate() method. It does not work neither. Giving me an other error;
Proxy Game.population by an other object Data declared globally or in Vue instance's beforeCreate() method, for curating interesting cells data (I don't need the pos attribute) and so avoiding createVector() error. It is a dead end;
Thinking about hoisting, I wondered if VueJS was initialized before P5JS run. It is the case. But I can't figure how to change that.
What is the issue here? How should I refactor my script so Vue instance's data and Game.population can be linked?
This solution isn't as pretty as throwing your Game object into the Vue instance, but it works.
Forked here: https://codepen.io/andymerskin/pen/LyoEmW
Here's what I changed:
Added a computed getter/setter for population, giving you a clean way to render the array's length in the template, and the ability to assign it in your Game loop using app.population = Game.population in your Game.doPopulatePacks routine.
Changed data.property in the Vue instance to _property to keep the naming conventions paired up for use inside the computed property. It does come with the caveat that it's no longer proxied to avoid conflicts with Vue's internal properties, since we're leaning on the computed property in the template.
(Currently, there isn't a clear convention for defining private properties in a Vue instance, even though underscores _ are the preference in JS more broadly.)
And with that, you'll see in the forked demo that your game's population stays up to date in the UI.
I'm trying to clear something up that I'm not getting from the dojo docs.
When I create a dojo provide I assume this is like creating a namespace with objects. For example.
myApp = { container: {} }
Written in dojo provide would be:
dojo.provide('myApp.container');
Now I have read somewhere where this is a global. Not sure I get that as its a namespace or are people true in saying this.
Another issue I'm having is if I use a declare to create a class do I need to use provide to create that namespace for me. for example
myClass.js file
dojo.provide('myApp.myClass');
dojo.declare("myApp.myClass", null, {
constructor: function(){
console.log("myApp.myClass created");
}
});
Now if there is truth to provide causing global variables then would this not be a global class now.
When I do a console.log from my app.js file which is my main.js file its not showing as a global but in fact as namespace myApp.myClass.
So can someone clear this up as its a little strange if there is truth in it.
Firstly, to clarify the term "global", technically myApp is a global - it is a variable on the browser's window object. While yes, ultimately the object/class your module defines is contained within that global object (and thus "namespaced" under it), that top level namespace itself manifests as a global variable; it is accessible to any script in the page/app.
Now, onto the declare question. Assuming this code is going into its own module to be loaded via dojo.require, yes, you still need the dojo.provide. While one purpose of dojo.provide is to ensure the variable you will be populating (e.g. myApp.MyClass) and any parent namespaces exist up-front, its other purpose is basically to act like an ACK to dojo.require's SYN - i.e., "yes, you asked for myApp.MyClass, and that's who I am." I'm pretty sure you would find that in the absence of that dojo.provide, dojo.require("myApp.MyClass") would fail, thinking it never found the module it was looking for.
Hope that answers your questions.
For example, i see myself doing things like this latley, when i create an object, if it has a logical path of tasks then
public Class Link
{
public Link(String value)
{
callMethodA(value)
}
public void callMethodA(String data)
{
CallMethodB(doSomethingWithValue)
}
...
...
}
Here you can see, as soon as you instantiate the object, yours tasks get completed automatically.
The other way i can see of doing it is by creating an object, that doesnt link via the constructor, then calling methods individually.
Which was is right and why?
Thanks
Either way we can implement.
Recommended way is to do tasks like initialization stuffs within the constructor and rest of the things can be implemented by way of calling the method with its reference object.
for such scenario one should go for Factory pattern
for example:
Calendar.getInstance();
Constructor should do ALL that requires to make an object complete. That is, if without calling method callMethodA , if the object is incomplete then callMethodA must be called from constructor itself. If the callMethodA is optional API then the user of class Link can call the method when he wants.
I prefer second method. Constructor's job is to initialize the class members. Any modification to change the state of the object needs to be done seperately by member functions.
As long as the objects that are created do not have nothing in common the current way of creating them is fine. Factory Method or Abstract Factory pattern makes sense when there's similarity between created objects. They'll help you isolate the parts that are always the same and moving parts that define differences between objects.
It depends on business logic involved. Both ways are practical. If you want to simply initiate instance specific data, then better to do it in constructor method itself which is more logical and simple. It will save calling other methods explicitly unnecessarily. If instanciating your data is based on certain buisiness condition, then it is good to have main functionality in separate method and then conditionally call it from constructor. This is easy to manage in such scenario.
A constructor is meant to bring the object in the correct initial state. So use it for that purpose. As a general rule of thumb, only use a constructor to set properties. Basic calculations are also ok.
I would not recommend calling very time consuming methods, or methods that are likely to throw exceptions (like calling a webservice or access a file).
When you need to do very special things to bring the object in its initial state, make the constructor private and use a static method to create the object.
The most basic task in an object oriented environment is executing a method on an object. To do this, you have to have a reference to the object on which you are invoking the method. Is the proper way to establish this reference to pass the object as a parameter to the constructor (or initializer method) of the calling object?
If object foo calls into object bar, is it correct to say (in pseudo-code):
bar = new barClass()
foo = new fooClass(bar)
What happens if you need to pass messages back and forth? Do you need a method for registering the target object?
foo = new fooClass()
bar = new barClass()
foo.register(bar)
bar.register(foo)
Is there a pattern that addresses this?
Dependency injection frameworks like Spring and Guice provide a solution to cyclical dependencies in Java by using proxies which can resolve the receiver of a message the first time it is required. This isn't a generally applicable OO pattern, however.
Generally dependency injection is the way to go. If you're just talking about two objects communicating then pass an instance of one in as a paramter to the other, as in your first example. Passing in the constructor ensure the reference is always valid. Otherwise you'd have to test to ensure register had been called. Also you'd need to make sure calling register more than once wouldn't have adverse effects.
What if you want a controlling object, to which other objects register for events. It would then be suitable to use a Register method ( which may add to a delegate).
See Observer Pattern
Well, depending on the level of messaging, you could implement a messaging service. Objects listen for messages, or register as a MessageListener on some MessageProvider.
You end up with cyclical dependencies if two objects have references to each other, which I would consider bad in most cases.
One of your object types could be a factory for the other. When Foo poops out a new Bar, the connection has already been made:
foo = new Foo();
bar = Foo.Poop();
function Foo::Poop()
{
bar = new Bar(this);
myChildren.Add(bar);
return bar;
}
bar.SayHiToParent();
foo.SayHiToChildren();
I think that it highly depends on what the exact relation is between the two objects.