I would like to avoid using event bus to being informed when a value in state placed. is there any event when a mutation called? I think it exists since it's event showing in Vue dev tools.
Related
Im actually learning Vue3.
It seems generally very clear to me.
But one thing is not clear at all.
The differecens between watch and beforeUpdate.
There are differences between this two?
And if yes, when is preferred use one rather than another?
Yes there are many differences. Watch observes only changes in the reactive data passed as the first argument, so it only operates after the monitored properties have changed. As for beforeUpdate , it is a life cycle that is called before the DOM is changed due to reactive data changes in the component, So it observes any reactive data in the component.
i think watch will triggerd after changing the data but beforeUpgrade is a hook and will look at the DOM for runnig something
With beforeUpdate you can listen to any change in the component. It will be called if any of the reactive elements change that is used in rendering the component.
With watch you can listen to specific reactive elements, even if they are not used in rendering the component.
I have a custom Vue component that does not render to HTML.
When the component is first mounted, I am able to loop through this.$listeners and optimize the underlying non-HTML event implementation accordingly (e.g. not to emit mousemove type events unless something is listening).
To complete this process I'd like to know when listeners are programatically added later through $on().
Is there any non-polling way to be notified of this? My current workaround is to listen for and emit everything but that is a poor solution.
Note that in some instances I want to be able to use the events in question, and others not. For example:
<custom-component #eventThatWouldFireOften="doSomething" #anotherEvent="doMoreStuff"/>
and another usage might be simply.
<custom-component ref="custom"/>
...
mounted() {
this.$refs.custom.$on('anotherEvent', ...)
}
So in the first case the result would be:
CustomComponent tells the underlying API it wants to listen for eventThatWouldFireOften and anotherEvent
CustomComponent receives eventThatWouldFireOften and anotherEvent events from the underlying API and re-emits them as Vue events that can be listened to using v-on or # syntax.
..and the second case the result would be:
CustomComponent tells underlying API it doesn't want to listen for anything just yet
When the parent of CustomComponent is mounted it programatically listens for anotherEvent. That needs to be communicated down to the base API (what I'm trying to solve).
I am learning the Angular 5+ and recently comes to the subject/subscription part, I see many tutorial would like to use the subscription in the certain way:
Declare the subscription in component
Subscribe it in ngOnInit via a service's subject or ngrx/store
Unsubscribe it in ngOnDestroy
However, I am not sure if we have to subscribe/unsubscribe every subscription in the component in ngOnInit and ngOnDestroy. For example, if my subscription will get updated through a button click event, which plan should I subscribe it in my component?
Only ngOnInit
Only button click event
Both ngOnInit and button click event
Why would we always subscribe a subscription in ngOnInit? The ngOnInit would be like a Page_Load in page life cycle, so it would only be called once at the very first time, if so whenever the subscription gets updated, will the ngOnInit be fired over and over again? If so, will my component be loaded over and over again which would cause a performance issue if in large application?
You usually put Observables to subscribe to inside a Service and make them available via getters and setters.
When subscribing to an Observable it behaves in a certain way like an EventListener. Whenever the object inside the Observable gets changed, an Event gets fired and your code inside the subscription gets executed. Additionally, you get provided the updated object.
Even if you init the subscription inside ngOnInit this won't cause your entire Component to reload when an update arrives. Only those parts that get updated by your code inside the subscription.
You don‘t have to put a subscription inside ngOnInit(). It depends on what you want to achieve in the component. But most of the time you want to load and display data directly when you access the component and update the UI when this data changes. That's why it is good practice to put the subscription in ngOnInit().
So Im made an $emit to an event bus in other conponent, where the component run a function 'save' from $on.
Is there a way to send a callback to emit showing that the 'save' function is made succesfully?
Im a bit new to vue. Thanx for all help
You may need to emit a second event using the EventBus to show that the save function was successful. Or, as #samayo mentioned, you could use state (Vuex). Read more about managing state with Vuex here.
I'm discovering VueJS and I don't understand exactly the differences between updated and watchers.
Updated hook
It is a lifecycle hook. According to the official documentation, it is triggered whenever data changes. So whenever a prop or a data is updated (the value, not only the pointer), updated is called.
Watchers
In the documentation, watchers are compared to computed properties. But in which cases would it be best to use updated instead of watchers ?
It seems that in both cases, DOM is not updated when the callback is called (nextTick() is required if we want to manipulate the changes in the DOM). The only difference I see is that watchers are only triggered when one precise property (or data) is updated where updated is always called.
I can't figure out what are the pros of updating whenever a data changes (updating) if we can be more accurate (watchers).
Here are my thoughts.
Thanks :)
The lifecycle hooks around update respond to changes in the DOM. Watchers respond to changes in the data. DOM changes are generally in response to data changes, but they might not be data owned by the component in question. One example where updated could be used is noticing that slot content has updated.
I think a better analogous lifecycle hook to the watchers may be the beforeUpdate hook. The updated hook is called after the virtual DOM has re-rendered, whereas beforeUpdate is called before the virtual DOM has re-rendered. You can see a visual representation of this on the diagram you linked to.
in which cases would it be best to use updated instead of watchers ? (...) I can't figure out what are the pros of updating whenever a data changes (updated) if we can be more accurate (watch).
The documentation says that you should prefer a watcher or computed property instead of updated if it is possible to achieve your goal that way. My understanding is that the updated hook was included to allow users to watch for any changes to the virtual DOM (see below).
Here's the explanation from the Vue 2.0 release notes on watch vs. updated:
User watchers created via vm.$watch are now fired before the associated component re-renders. This gives the user a chance to further update other state before the component re-render, thus avoiding unnecessary updates. For example, you can watch a component prop and update the component's own data when the prop changes.
To do something with the DOM after component updates, just use the updated lifecycle hook.