I want to store some of the variables between components in global window object, so I do window.showFilters = !window.showFilters
In the components, I am trying to use watcher on window object like
watch: {
"window.showFilters": {
handler: () => {
console.log(window.showFilters);
},
deep: true
}
},
However, this doesn't work so I have to use Vuex which I would like to use only for business data rather just code variables.
Is there are a right way to watch for variables in the window object?
If you do not want to use the Vuex store (which is the recommended way - and you can simply separate your business and application state in 2 different Vuex modules) then you are advised to store such variables in the root Vue instance (the one in your main.js)
The problem with global variables (a.k.a window properties) is that they are not reactive. You could try to use this.$set(window, 'showFilters', true) but this is ugly and might not work.
But even putting your variables inside the root Vue instance you still need to inform your components about the changed value - and you can do this by emitting events only (a watcher can only watch for changes inside the same component - not between components)
I resolved like this:
mounted(){
setInterval(()=>app.myownwatcher(), 100)
},
methods: {
myownwatcher(){
// do something with window.showFilters
}
}
It does not the best way but work :/ When my app run, I create a interval who update my model
Related
I don't need to pass data between a parent component to a child one or the opposite, I need something like php/c static variables.
I want my sfc (single file component) to have some data that is shared among all instances in in the page.
As far as I understand that's why in sfc we define data as a function
export default {
data(){
return {
// props here
};
}
}
while in page scripts we can define it as an object
const app = new Vue({
data: {
// props here
},
}
That's because since we can have multiple instances of a sfc in the page defining its data as a function make each instance to execute in and get its own data, while with page script we can have a singe instance.
I need to define some of my sfc data to be shared between component instances, while other data to be per-instance.
Is there a way to do this?
That depends on the data to be defined, its complexity, and purpose.
If these are 2 or 3 readonly variables, they can be set as global properties using Vue.prototype (Vue 2) or app.config.globalProperties (Vue 3). I'm not sure, because in your example you use Vue 2 syntax.
If the data should be reactive, you can set up a simple state management as explained in the Vue documentation: Simple state management.
If the data is more complex than that, the next step will be Vuex.
Following #Igor answer I looked after the simple state management and found the ref() method that creates reactive primitive values.
In my specific use case I needed to share among all the sfc instances just an array, so in my sfc I had:
const reactive_array = ref([]);
export default {
data() {
return {
shared_array: reactive_array,
};
},
};
I have a component that has complex rendering logic.
I try to carry out this logic to helper classes, for simplifying.
To do this, in the data section (for reactivity), I create class references as follows:
export default {
data: () => ({
state: new InitialState(this),
query: new QueryController(this)
})
}
As I understand it, at this point the context of this is not yet defined.
So, I have two questions.
1) Is there a way to pass the this component context in the data section (without lifecycle hooks)?
2) Is the approach with references to external classes of vuejs philosophy contrary?
Component instance is already available when data function runs, this is one of reasons why it has been forced to be a function.
Due to how lexical this works with arrow functions, it's incorrect to use them to access dynamic this. It should be:
data() {
return {
state: new InitialState(this),
query: new QueryController(this)
};
})
The problem with InitialState(this) is that the entire component instance is passed instead of relevant data, this breaks the principle of least privilege.
Despite Vue isn't focused on OOP, there's nothing wrong with using classes. One of possible pitfalls is that classes may not play well with Vue reactivity because it puts restrictions on the implementation. Another pitfall is that classes cannot be serialized to JSON and back without additional measures, this introduces limitations to how application state can be handled.
As I understand it, at this point the context of this is not yet defined.
Only because of the way you've written the code. The component instance does exist and is available. It is sometimes used to access the values of props for determining the initial values of data properties.
For example, here is an example from the documentation:
https://v2.vuejs.org/v2/guide/components-props.html#One-Way-Data-Flow
export default {
props: ['initialCounter'],
data: function () {
return {
counter: this.initialCounter
}
}
}
The reason why your code doesn't work is because you are using an arrow function. If you change it to the following then this will be available:
export default {
data () {
return {
state: new InitialState(this),
query: new QueryController(this)
}
}
}
See also the note here:
https://v2.vuejs.org/v2/api/#data
Note that if you use an arrow function with the data property, this won’t be the component’s instance, but you can still access the instance as the function’s first argument
As to your other question about whether using classes like this is contrary to Vue...
I don't think the use of classes like this is encouraged but they can be made to work so long as you understand the limitations. If you have a clear understanding of how Vue reactivity works, especially the rewriting of properties, then it is possible to write classes like this and for them to work fine. The key is to ensure that any properties you want to be reactive are exposed as properties of the object so Vue can rewrite them.
If you don't need reactivity on these objects then don't put them in data. You'd be better off just creating properties within the created hook instead so the reactivity system doesn't waste time trying to add reactivity to them. So long as they are properties of the instance they will still be accessible in your templates, there's nothing special about using data from that perspective.
I think computed is a better way to do what you want
export default {
computed:{
state(){
return new InitialState(this);
},
query(){
return new QueryController(this);
}
}
}
I have several custom js objects, where I encapsulated needle logic.
So, these objects don't have relation with vuex at all, something like that:
export default class Property {
constructor(object) {
// some logic
}
addChild(property) {
// some logic
}
}
Also, I have button in my vue component, which firing vue method:
methods: {
addItem() {
this.property.addChild();
},
},
And there is problem:
this.property - it is object from vuex store.
So, when I call method in such way, I get vue error:
Error: [vuex] Do not mutate vuex store state outside mutation handlers.
Yeah, I understand, what Vue wants.
But for me it is more clear to encapsulate some complex logic in needle objects. Also, I want to use vuex for global app state.
So, please, could you share experience how to deal with vuex and custom object methods?
If you want to use vuex you simply have to use mutation to alter it's states.
So, in the the Property object's addChild function,
where you would alter state, I assume you would do it like
Store.state.xxx = 'new'
Instead of doing that, you call mutation like
Store.commit('alterState')
There's not too much difference in terms of complexity, right?
First of all, it sounds like this situation is perfect of use eventBus but I am just experimenting. What I feel this will element the process of emitting and capturing event.
Say that in my main.js I have declared:
Vue.prototype.$someHeight = 200
in some of my component I tried to change it to:
this.$someHeight = 300
But when I use it in my vue, it still says:
{{ $someHeight }} // output: 200, and I was expecting 300
So, how to override it? Is this a good practice?
Every vue component is an instance of Vue. When you define a variable (such as $someHeight) on Vue's prototype, all new components created will get their own copy of such variable.
Which means every Vue component will have its own copy of $someHeight with value of 200. Now even if you set its value to 300, all other components will have the old value of 200.
It is not a good practice. You should only define functions on prototype: Vue doc
Now you can either use Vuex for this or create a global vue instance and use it to store your global variables. Vuex recommended of-course!
I am searching for the best approach to change Vue variable value outside of component. I'm using Vue webpack as well.
I have created a project using vue webpack.
Inside its default App.vue file, I have a variable. For example, let's take showModal and its default value is false.
Then I built it in a single javascript file.
<button>Register</button> {{-- event button --}}
<div id="guest"></div> {{-- Here I'm rendering my template --}}
<script src="{{ asset('js/vue-js/guest.js') }}"></script> {{-- builded Javascript file --}}
And the problem is that I want to change my showModal variable to true, but the event button it is not on my component template.
What is the best approach to accomplish this?
If you want to access a vue component outside of vue you could register it to the window object and access it then from anywhere.
window.myVueComponent = new Vue({
router,
store,
render: h => h(App)
}).$mount('#app')
Now you can access it from anywhere else with
window.myVueComponent.myValue = 123
But this "style" is called global namespace pollution for reasons.
;)
I think it is better to extend your vue app so that the button is also within the vue-handled components.
Firstly, best approach wise it's prevalent to think about the relationships between your existing components and their relationships. So for instance if the information your trying to pass will be used in a direct sibling or further down the chain you could choose props.
If your dealing with two components that share no direct relationship other than there current state you will need to extrapolate to either using the repository pattern or Vuex (flux like state management library) where we can then pass a reference to state or into properties in the repository pattern.
FooRepository.js
export default class FooRepository {
SomeRef
ManyRef = []
addRef(name) {
this.someRef = name;
}
addRefs(names){
this.ManyRef.push(names);
}
}
The above can be instantiated in your App Layer and shared between your components using an instance property https://v2.vuejs.org/v2/cookbook/adding-instance-properties.html
Dependent on your apps size it might be time to include Vuex where we can save a reference directly into our state and use it in a simmilar manner as the repo pattern. Though as it's an officially supported package the setup and use is much simpler:
const store = new Vuex.Store({
state: {
ref: null
},
mutations: {
saveRef (state, compRef) {
state.ref = compRef
}
}
})
This is a very basic store that shows how we could save a reference into it, we can then access this reference in our components once we've registered the store inside main. This can be done using this.$store.state.ref. These two approaches are considered the best approach over simple simple props and or something like the event emitter for components that share no direct relationship.
Create a new Vue instance just for emitting, call it global event manager.
global.event = new Vue()
when you want to emit an event ( like modal )
global.event.$emit('close-modal', (optional msg))
when you want to close modal :
// In your component
created(){
var App = this;
global.event.$on('close-modal', (optional msg)=>{
this.showModal = false;
})
}
Similarly do it for opening the modal. If you are using the vue CDN (normal js file of vue), instead of global.event use window.event while creating and only event while using. In browser if a variable which is undeclared is used then it refers to the window object.