All in vue and mutation in vuex are regular functions.
But actions and getters in vuex are not.
Why is that?
You can see them either as method declarations or expressions (arrow functions). Usually I see getters as arrow functions to take advantage of the implicit return.
Example:
getItem: state => state.item
But this could potentially be written as:
getItem(state) {
return state.item
}
In my experience, simple methods that only that need a return are a good candidate for an arrow function. So it could be thought of as a shorthand to achieve the same result.
Related
Is there a way in Vue2 to do this:
....,
computed {
...mapState('myModule', {
myVal: (state, vm) => state.someVar.filter((_) => { return vm.someVar })
})
},
....
The actual function I'm working on is filtering the state.someVar in a more complex scenerio, so this is simplified. The point being that this is undefined.
Anyone know how to reference the vue in such a function?
The 2nd argument to the mapState function is supposed to be a state mapper (array or object)
If you are using an object (as you are), you can only set the properties of the object to the keys in your "myModule" state object. You cannot set them as functions
e.g {customName: moduleStateKey}
As for passing component instance, you can only do that in an action or mutation. However, that would make your store impure. It would be better to pass someVar to state via a mutation fired from the component, then use a getter for the filter logic and use the someVar passed to state there
Vue.js official docs about plugins describes global methods and properties and Vue instance methods.
// 1. add global method or property
Vue.myGlobalMethod = function () {
// some logic ...
}
// 4. add an instance method
Vue.prototype.$myMethod = function (methodOptions) {
// some logic ...
}
But it isn't clear which of this approach is better fit to define global functionality? Can someone explain difference or indicate some resource about different use cases of this two approaches?
An instance method will have an instance (this) to be called from an operate on. A global-on-Vue function would have Vue itself as its this, which probably means you wouldn't want to use this in it.
So: instance method if it should operate on an instance, global function if it is some sort of utility that doesn't operate on a Vue instance.
I'm not new to Vue.js, but I'm going through the docs again, trying to pick up on anything I missed the first time. I came across this statement in basic example section of using computed properties:
You can data-bind to computed properties in templates just like a normal property. Vue is aware that vm.reversedMessage depends on vm.message, so it will update any bindings that depend on vm.reversedMessage when vm.message changes. And the best part is that we’ve created this dependency relationship declaratively: the computed getter function has no side effects, which makes it easier to test and understand.
The part about we’ve created this dependency relationship declaratively: the computed getter function has no side effects, isn't clear to me. I do understand that a side effect is some action happening that is not directly related to the pure intentions of the function, but I'm not clear how it's being used in this statement.
Could someone explain further what the opposite could be? What are the potential side effects that could be happening?
The term side effect here refers to any data mutations performed in the computed property getter. For example:
export default {
data() {
return {
firstName: 'john',
lastName: 'doe',
array: [1,2,3]
}
},
computed: {
fullName() {
this.firstName = 'jane'; // SIDE EFFECT - mutates a data property
return `${this.firstName} ${this.lastName}`
},
reversedArray() {
return this.array.reverse(); // SIDE EFFECT - mutates a data property
}
}
}
Notice how fullName mutates firstName, and reversedArray mutates array. If using ESLint (e.g., from Vue CLI generated project), you'd see a warning:
[eslint] Unexpected side effect in "fullName" computed property. (vue/no-side-effects-in-computed-properties)
[eslint] Unexpected side effect in "reversedArray" computed property. (vue/no-side-effects-in-computed-properties)
demo
I have a component which has two functions in it. One function returns an array of objects while the other receives it as a parameter. Both the functions being in the same component.
Example Code:
export default class Test extends Component {
func1 () {
return arrayofobj
}
param = this.func1();
func2 (param) {
param.id
}
}
So, my question is. How can we pass and access the array of objects to "func2" i.e. param.id
Also, I do not want to use state or props in this case.
You do not really understand what a class and component are. Try to learn about it here: https://facebook.github.io/react/docs/react-component.html
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Classes
Below documentation shows the usage of Observable with and without the "new" keyword.
http//dojotoolkit.org/reference-guide/1.9/dojo/store/Observable.html
// create the initial Observable store
store = new Observable(new Memory({data: someData}));
http//dojotoolkit.org/documentation/tutorials/1.6/realtime_stores/
Note: despite its capital "O" and dedicated module, dojo.store.
Observable is not a constructor; it is simply a function which
takes a store, wraps it with observe functionality, then returns it.
Therefore, the new keyword should not be used with dojo.store.Observable.
http://dojotoolkit.org/documentation/tutorials/1.7/realtime_stores/
// wrap the store with Observable to make it possible to monitor:
marketStore = Observable(marketStore);
What is the correct usage?
If both are correct? when should a particular usage be preferred over the other.
Frank.
It doesn't really matter. What happens behind the screens is very similar. When you call the Observable as a function like:
var store = Observable(new Memory({ data: [] }));
Then it will use return value of the Observable() method (which is the observable store).
When you're using the new keyword, you're creating a new instance of Observable, in JavaScript that means that the Observable() function itself will be seen as the constructor of the new instance.
However, when you're providing a return value from inside the constructor, that object (when being a complex object) is used as the instance in stead. So in this case it returns the observable store, so that will be used as the instance. A good article to read what happens if something is being returned from a constructor function can be found here.
The naming of it (starting with a capital letter) makes you think it's an instance of Observable, but it isn't. The ultimate proof to that is the following:
new Observable(new Memory({ data: [] })) instanceof Observable // Returns false
The following returns false and in case of a real instance it would return true.
Summarized, both ways will return an observable store. There is no difference in it, even performance wise both are very similar.
So it doesn't really matter what you use, the only thing I can tell you is that it behaves like a normal function and not as a constructor.