In vue2.0 the event $dispatch and $broadcast is deprecated.
And I found that $dispatch is similar with $emit.
What's the differences between them? Is it safe directly replacing $dispatch into $emit when migrating.
No, You will not be able to replace $disptach with $emit everywhere. You can replace it, wherever you are using it for communication from child to parent, but for other cases, you may have to take some other approach.
From the documentation ( similar comments from Evan you in Upgrade Tips):
One of the most common uses for these methods is to communicate between a parent and its direct children. In these cases, you can actually listen to an $emit from a child with v-on. This allows you to keep the convenience of events with added explicitness.
However, when communicating between distant descendants/ancestors, $emit won’t help you. Instead, the simplest possible upgrade would be to use a centralized event hub.
From the documentation of $dispatch
Dispatch an event, first triggering it on the instance itself, and then propagates upward along the parent chain. The propagation stops when it triggers a parent event listener, unless that listener returns true.
on the other hand $emit:
Trigger an event on the current instance. Any additional arguments will be passed into the listener’s callback function.
So you can see, if you are passing communication to multiple layer of parent elements via $dispatch, you have to handle that code differently with $emit
Related
According to the Vue 3.0 guide:
Methods called from a template should not have any side effects, such
as changing data or triggering asynchronous processes. If you find
yourself tempted to do that you should probably use a lifecycle hook
instead.
I'm curious why this is? I feel like it's very likely you'll want to change data on an event listener that references your own method rather than a lifecycle hook.
I think what they mean is you should not call a method with side effects during the render, like this:
<div :title="changeSomeData()">Hello</div>
One such problem with this is calling changeSomeData() during the render can mutate reactive data which will trigger another re-render of the component, potentially infinitely. It's not good code.
It isn't always clear to the programmer when the component will be re-rendered and thus when changeSomeData() will be called. This makes it difficult to trace the cause of some data mutation.
An event handler method is not executed during the render, instead it is only registered as an event handler and will be called later in response to that particular event. This is OK.
They means the methods used for rendering purposes like :
<p>
{{showSomeCalcul()}}
</p>
because the methods are used as handler for events :
<button #clikc="send" >Send</button>
I've seen this blog post claim that using properties to pass callbacks is an anti-pattern in Vue.js
But it doesn't make sense to me. The problems mentioned:
By passing functions down as props, you are linking both parent child components together with two-way data binding
These events are mechanically doing the exact same thing as a callback prop, so this doesn't add up.
As the application grows larger in size and other developers come on board, they will look at the child component code and have to figure out which callback function prop it is and where it is from.
You can replace the word callback function prop with event and you get the same problem.
Using functions instead of string names would avoid the kebab-case issue. Also, function-props would allow typescript to verify the function signatures are compatible. I think events should be removed and replaced entirely with callback props. The only downside I see for removing the events tech is a namespacing issue for events like click that you might want as properties.
What are the design reasons for including events as a system instead of having a few magic properties? Are callback properties an anti-pattern or is it just a matter of taste?
Still on the basics of AngularJS, i understand the concepts, however, just looking at custom events,
$emit
and
$broadcast
for nested controller..
According to the docs, $emit bubbles the event, ie. passes it up the chain, for nested controllers,
My question, is, how is this different to just simply calling a function from the parent controller (prototypical inheritance). Or have i miss understood something?
The thing is, you can't always be certain that your direct parent, is the one you want to call. It's easy to break your code with that kind of anti-pattern.
And you must agree that
$scope.$parent.$parent.$parent.doSomething();
Is pretty ugly.
Instead you can $emit an event upwards, now it doesn't matter how far up the chain your parent controller is, as long as it is listening and reacting.
This gives you nice loose coupling between controllers, and just acts like a message pump.
The same goes for $broadcast, just downwards instead, and here I would argue that it is even more important.
Take the example of a child controller with many parents or a parent controller with many children. Should the developer need to maintain a list of children within the parent to invoke a function on each of them. $emit and $broadcast are utilities to allow a loose-coupling messaging along the lines of an Observer pattern. If all parents in the hierarchy need to know that a child controller has done some task or needs some task dome on its behalf then is can just generate an event and interested parties can listen.
Data can also be passed removing the need for controllers to share data on the inherited scope.
$emit helps you to pass event to the parent controllers.
You can't use $controller('ParentController', {scope: scope}) in all your child controllers to inherit the properties. To make the code clean and loosely coupled, $emit will help you to achieve that.
Assume you have three levels of hierarchy and you want the child controller to update the value of a particular parent controller. If you are going to do that via prototype chain, you need to inherit that particular controller using $controller('ParentController', {scope: scope}) but $emit will avoid that. You need not know which parent controller. instead just emit the event.
In the appropriate parent controller where you want to read the data, use
$scope.$on("eventname", function(event, data) {
// update value here
});
In the dojo Javascript library, dojo/on and dojo/aspect are used as functions that listen to events.
However I don't see how they differ from one another. Can someone explain when you would use on and when you would use aspect?
dojo/on is used for listening to events. dojo/aspect is used to intercept calls to javascript functions.
With aspect, you can intercept a function call and do something before the function call, after, or both. With events, you are being notified that something occurred.
Technically, if the target object is not a domNode, dojo/on ends up calling aspect.after(...)
In <=1.6, there was not a distinction and dojo.connect was used. Functions were used to notify that an event occurred and there are still remnants of that in the code base. An example is using on with the click event on a dijit/Button.
dojo/Evented http://dojotoolkit.org/reference-guide/1.9/dojo/Evented.html
In javascript DOM this refers to the element clicked which seems more logical than in .NET where this refers to the parent. Why this choice?
The button is also a class. If it was truly OOP it would consider button as first class citizen also. So It's not a question of paradigm here it's rather a question of implementation. My hypothesis is that was probably easier for MS to do so because the physical module exists for parent not for child.
But for us it is a pity since you have to cope with this sender which seems as it is foreign to the button whereas it is himself !
They are different systems and different paradigms.
In .NET, your handlers are passed a "sender" argument which contains the object. The handlers reside in the form object or user control, so "this" refer to that class (if you do a double-click type of adding a handler). If you manually created the handler, then it can be part of any object (not necessarily the form object), and "this" will map to different things. .NET events are also not bubbled or captured.
In DOM, your handlers are not passed a "sender" argument. However, "this" refers to the object. In DOM, events can bubble or captured.
There is no reason why the designer of JavaScript cannot provide a "sender" argument though, and map "this" back to the object holding the handler. In my opinion, these were just historical choices being made when the world was much simpler.
In C# the handlers are methods of the Form object and thus this also references this object.
However, I think you can use one of the handler's arguments to get the element related to the event.