in Backbone.
http://backbonejs.org/#Events-on
I have a single event bus with no namespacing. I don't understand why you would need to use "all".
The example used in the notes is for a proxy but I don't understand why you would want to do this.
You can come up with different use cases, for example:
Logging all changes that happen on the object
Using it as Adapter from one framework to the other
Wrapping original object in proxy object, and triggering events through it
e t.c.
It's up to you, if you need to use it or not, it's just there, with no obligations.
I use this to let the user "something" is going on. As a programmer I am also aware that Backbone is firing events.
You can use a subtle animation that shows the page is firing events.
It is also a good way to give a top level view of how your application is working.
Related
I originally was reading this:
https://developer.mozilla.org/en-US/docs/Web/API/EventTarget
But, then I came upon this question here:
How to use JavaScript EventTarget?
However, when or why would a developer need to use EventTarget?
I'm still learning. I know the SO community doesn't like duplicate questions, but I feel this isn't since it's asking a different question than the one I cited above (it only discusses how to use it).
For the same reason you might use EventEmitter in node.js: you have some custom class/object which you would like to emit events.
Events are useful to allow your object to notify other parts of your code that something interesting has happened, without the object actually knowing anything about the code that uses it.
For example, a link on a page (implemented by the browser as an HTMLAnchorElement object) does not need to know what your code does in response to clicks; you simply register a click event handler (by calling EventTarget#addEventListener('click', …)) and when clicks happen, the browser internally calls EventTarget#dispatchEvent(new Event('click')) and your code handles the event.
Your own custom objects can use this pattern for a wide range of things. Perhaps you'd like to notify things that your object's data has changed -- either as a result of the user doing something or a fetch call returning.
This allows you to build code that is easily composable and testable: the emitter doesn't care who is listening or what that code does, and the consumers don't care about the implementation details of the event getting fired.
I've read some articles about the Observer design pattern in JavaScript, but I don't get it: it seems to me quite useless since JS has events. Am I missing something?
Reacting to events like click, resize etc is one thing but limited to the DOM events. However without going into details here, if you look at a library like RxJS (which uses the Observer pattern) you will be able to build powerful Reactive systems, where essentially anything could be treated like events, which in addition to the standard event system, they can be composed, mapped, etc
Since ReactJS uses event delegation, is there a way to access the internal node/events mapping?
It doesn't have to be pretty, wrapping one of the responsible functions (like the equivalent of jQuery's on()) and doing custom housekeeping would work fine and would actually be preferable to accessing that data through an object of some sort.
If I could get the selector, event and handler (optional) that'd be great, as I'm already doing this for jQuery.
The reason I'm asking is because I'm trying to optimize Arachni for ReactJS applications and having prior knowledge of which elements actually have event handlers (and what they are) would result in a much more efficient scan.
In addition, that data would be of great value when scanning web applications for non security reason's as well, you could gather some very interesting stats that way.
I'm currently studying the jQuery ajax methods and trying to take a little more in-depth look into them. I was playing with the global event handlers: ajaxStart, ajaxSend, etc. I understand how they work, but I can't think of any good use cases for them.
I've seen examples where they are used for loggers which seems feasible enough, but why make them methods and not stand alone functions that can be called like $.ajax(). It seems if I don't have any particular element to attach them to I just set it to the $(document) anyway.
Also, being able to use $(this) inside of the handlers does not seem like much of a benefit over just doing $("#log").
Have these been a life savor for anyone, are there any other use cases outside of a global logger?
The global event handlers are useful for showing indicators to the user as well. That way their experience is consistent (same indicators when saving/loading) and you don't have to write the same code over and over.
The ajaxError method is great for global ajax error handling. Instead of having an error callback on all of your ajax calls, you can use the global and have it log somewhere. You can access all the information from the original ajax call from ajaxError.
$(this) insead of $('div span.foo div[data-foo="foo"] > input.EVIL') or $('*')can be a life saver...
It depends on the exact scenario, but it ALWAYS better and a good practice...
And the case you want for the ajaxsetup: Pass the same options to a jQuery function over and over
Here is a guy that this option helped him out.
Is it possible to report all the observers of the 'ready' events. I have a page where something is happening twice, and i'm trying to chase it back to the source.
Unfortunately you can't do this after it's executed, as it's a special event handler, which that "duplicate" question doesn't really cover.
$(document).ready(func) (or $(func)) or stores the functions you want to call in readyList (internal array). Unfortunately for your situation, but good for performance/garbage collection, this list is nulled out after it runs, so you can't get the list you're looking for.
You can see how this happens in jQuery core here.
Your best bet would be console.log() in a few functions /files to see if you get any duplicates I'd say.