i'm using vue.js and vuetify.
elements made by parent element exist in my code.
i want to change parent element's class dynamically depending on it's child class, like jQuery has() method.
is vue.js has any way to do this?
jQuery has()
You can access a state if a child property of a child on different ways. (I assume the child class is set based on a certain state).
You could use vuex that keep a state over several components. You could emit a state back to you parent component. Or you could use the ref to access the child components properties.
<component ref="childcomponent"></markdown>
process: function(){
// items is defined object inside data() of the child component
var hasClass= this.$refs.childcomponent.item
}
Related
I have this component which has a v-model directive:
<my-component v-model="someData.someProp"></my-component>
Now, I'd like to be able to watch this piece of data inside the component and make changes based on this model changing via outside influences. So here's what I tried and it's not working:
watch : {
value (newVal, oldVal) {
// ...
}
}
It seems like it should work, or something comparable should be out there, but I just can't find it right now.
EDIT:
The most common answers I found and provided center on using the watcher to watch the data as if it's inside the parent component - but I'd like to watch it inside the child component without concern of what's going on in the parent.
I'm able to work around this by not using v-model and using simple named properties such as :my-data="someData.someProp" at which point I can successfully watch a myData variable inside the child component. I can also use #input to set the data back in the parent component if it's changed from within. But v-model is shorter and if there's a way to use that instead of a workaround that would be preferable.
From what I understand you are trying to pass a prop to your child component from your parent one and watch it in your child.
Assuming you have something like this in your parent:
<div>
<my-component v-model="someData.someProp"></my-component>
</div>
I understand you are getting undefined for that prop when you watch it, which is normal because you should pass it like this:
<my-component :myValue="someData.someProp"></my-component>
Then you should have access to the prop trought this.myValue.
If someData.someProp changes on the parent component it will automatically reflect on the child one.
Again this is what I could understand from your explanation and the amount of code you provided.
I know the correct pattern to pass data from/to a parent/child component in vue.js is to pass props from the parent to the child and emit events from the child to the parent. But is there anything wrong with this:
this.$refs['child-component'].setValue(val)
I'm told that one should use refs to access child components sparingly, and only when there is no other way.
What if I want to update the value of a field in an array in the child component that isn't bound to a prop, something like this:
this.$refs['child-component'].childArray[index] = val;
...where childArray is not a prop of child-component? Do I need to MAKE childArray a prop of child-component? But then it becomes the parent's responsibility to maintain childArray. What if it isn't the business of the parent component to maintain childArray?
Thanks.
Actually, it is not a business of the parent to mess with the child's internal data at all. You should not directly mutate internal data of a child - instead, consider calling a method or emitting an event (which should be handled by the child).
Currently you are creating a tight coupling between the parent and the child - now the parent is overloaded with knowledge about the child internals. Tomorrow, when you decide to change the implementation of the child (for whatever reason) - most probably you will also have to inspect all parents where this child is being used just to check that your changes did not break the assumptions of those parents.
I am currently working on a project that has a component structure like follows
Parent component that contains items
This component has a v-for over this.items.
That v-for has a
ChildComponent contains a form that modifies properties of this.item via v-model for each property.
I was expecting, since VueJS does not support 2 way databinding by default, that ParentComponent would not be aware about changes that I make in ChildComponent.
However, since my ChildComponent is a modal dialog, I can see the changes that I make in ChildComponent are reflected in ParentComponent.
As much as I like what I see, I don't understand it...
Could someone shed a light on this for me?
I was just wondering if this is even possible, lets assume I have this code here:
<div v-for="tile in container" v-bind:class="proper-class">
<tile :tile='tile' #update="update-class"></tile>
</div>
I want to change the css class of the parent div when a variable inside of the component changes.
I know we should use $emit but we have a v-for in here, so we're creating multiple components, the $emit callback will update proper-class BUT this will update the css class of ALL the parents and not just the parent of the component that issued the update event.
What could be a solution to this?
Thanks in advance.
You can use the sync modifier to create a two way binding between the parent and child. It's nothing more than syntactic sugar for the child component emitting an event back to the parent with the desired payload.
this.$emit('update:propName', payload)
Vue sync modifier
I have a simple component hierarchy, in which there is one parent component, which contains the following template <div><component :is="current"></component></div> and two child components, which are dynamically 'switched' out, via the value of current.
The logic for the 'switching' of components is being handled in the parent component. However, when I try to execute a method in the second child component (in response to an event emitted from the first child component, being listened to in the parent component, and altering the value of current in the parent component) through the mounted lifecycle hook, the expected result is not observed.
Essentially, I cannot find a decent way of invoking a child component's methods when that component is 'switched' in as the current component in the parent component.
I have realistically looked at using the $refs and $childrenproperties on the instance, but these do not seem to be of any assistance. I have also reasoned using the event system. I usually 'define' an event listener in the mounted lifecycle hook, however, I refer to the 'issue' of using the lifecycle hooks
What is the usual approach to this situation?
There are two options that immediately come to mind for child components invoking methods on being the "current" child component:
1) Using the mounted lifecycle hook. In order for this to work, you must be using v-if in order to conditionally display the child component, otherwise the child component will not trigger the mounted lifecycle hook. Otherwise, if you're using v-show or some other mechanism for conditionally displaying the child component, the mounted hook will only ever trigger once.
2) Using watched properties. In lieu of the above, you could do something like the following:
<child-component :target_prop="current"></child-component>
Vue.component('child-component', {
. . .,
props: ['target_prop'],
watch: {
target_prop: function() {
if(this.target_prop == your_expected_value) {
//execute the desired method for this component
}
}
}
});
This is, of course, just a proof-of-concept example and there are plenty of alternative ways to use the watched properties to your advantage.
I've also heard of using a "bus" to handle inter-component communication, but I don't believe it would be any better than the above two solutions (and is arguably worse).
Personally, I prefer the mounted lifecycle hook approach, though there's the caveat that any "settings" or data in your child components will be lost on switching between them (although you could also emit a settings object on destruction and store/restore those settings as needed, but that could get messy). You'll have to make the final judgment on which approach better suits your needs and which consequences you're more comfortable dealing with.