My app is using Paper.js as a framework for drawing elements, and I am currently coding some tests.
I need to trigger tool events manually, but I'm getting a 'emit is not a function' error.
I'm doing it like this:
tool.emit('mousedown', {
point: new Point(5, 5)
});
What's wrong with my code? According to Paper.js documentation:
emit(type, event) Emit an event on the tool.
Parameters: type:
String('mousedown'|'mouseup'|'mousedrag'|'mousemove'|'keydown'|'keyup')
— the event type event: Object — an object literal containing
properties describing the event Returns: Boolean — true if the event
had listeners, false otherwise
If I debug my code, tool is a Tool object, but emit doesn't exist.
It seems like emit is not the correct function to trigger event on Tool objects. Paper.js doesn't document fire function (at least in newer versions).
My code needs to be like this to work:
tool.fire('mousedown', {
point: new Point(5, 5)
});
Related
I have an SVG object which uses d3-zoom for zoom and pan functionality. It works flawlessly but the problem showed up when I started to work on integration tests using Cypress.js.
I tried using standard mouse events on the svg element, to simulate drag behavior:
cy.get('svg')
.trigger('mousedown', { which: 1, force: true })
.trigger('mousemove', { position: 'left' })
.trigger('mouseup', { position: 'left', force: true });
The example above is taken from the Cypress drag and drop recipe, and it produces the following error in the nodrag.js file:
cannot read property document of undefined
Below you can see where the error occurs (view is undefined):
__webpack_exports__["default"] = (function(view) {
var root = view.document.documentElement,
...
I spent a lot of hours trying to trigger the event in another way, but without a success - like trying the snippet above with the svg container.
Please keep in mind that I cannot access any d3.js package from the Cypress test because it's imported as an NPM package in a React application.
Thank you in advance for you help!
I could only arrive at a partial answer before I had to move on, but perhaps this can help you, or someone else, find the ultimate solution.
To remedy the error, a view property must be provided for mousedown. Providing window, like this, allowed the D3 methods to fire properly:
cy.get('svg')
.trigger('mousedown', { which: 1, force: true, view: window }) // <-- here
.trigger('mousemove', { position: 'left', view: window }) // <-- here
.trigger('mouseup', { position: 'left', force: true });
However, no dragging or movement occurred during the test run, and other questions emerged from there. Starting with... Is this the right context to send along with the event? It seemed so, since window seems to be the only context that has the property chain that D3 anticipates:
view.document.documentElement
Or is that an anti-pattern... a code smell?
Running down those subsequent questions led to a few observations that seemed to have significance.
The first concerns how D3 handles mouse and drag events. D3 has numerous event listeners and callbacks that override standard events and their respective handlers.
The second, is that iframes are in play with the Cypress test runner.
Could it be that Cypress's programmatically triggered events are firing properly in the Cypress iframe, but due to D3's aggressive event handling, the translation of those events into the application iframe are getting lost? Especially considering that manually dragging a circle in the testing viewport worked fine.
Which, again, leads back to:
Are the programmatically triggered events not being called in the correct context?
Are those events somehow being swallowed by or colliding with D3's event handlers?
I selected the Zoomable Force Directed Graph as my D3 subject, inside of a simple Ember application, for researching this question. It perfectly reproduced the error mentioned, so it definitely seems to be a D3 + Cypress challenge, and unrelated to the front-end framework.
I hope this effort is helpful.
Continued...
After some further reading – Cypress's Trade-offs, and particularly, their open pull request Support for Native Browser Events – it seems likely that the event handling overrides within D3 are not yet fully reconcilable within Cypress. Simpler implementations, like those detailed in the drag and drop example, do not present the event handling challenges introduced by a 3rd party library like D3. However, this support does appear to be under development within the Cypress team.
Try this:
cy.window().then(win => {
cy.get('svg')
.trigger('mousedown', {
which: 1,
force: true,
view: win,
})
.trigger('mousemove', {
clientX: 300,
clientY: 500,
force: true,
})
.trigger('mouseup', {
force: true,
view: win,
});
});
Referencing Jennifer Shehane's answer in this GitHub issue, the answer to the cannot read property document of undefined part is to plug the window object into view in the trigger options. The issue mentioned in jacefarm's answer, where no movement occurred, seems to be resolved by specifying clientX/clientY rather than using positions relative to the selected element.
I used a little bit different from your code so you can try
cy.get('svg')
.trigger('mousedown', { which: 1 })
.trigger('dragstart', {})
.trigger('drag', {});
FWIW I had this same issue and using this library allowed me to interact with the D3 elements: https://github.com/dmtrKovalenko/cypress-real-events
This is regarding javascript programming pattern. while working with the gulp, I came across 2 different type of function calling pattern and this is really confusing so someone clarifies Is both functions are doing the same job?
gulp.watch(path.join(conf.paths.src, '/app/**/*.js'),
function(event) {
if(event.type === 'changed') {
callAMethod();
} else {
callBMethod();
}
});
in above method, we can write if else condition
but in this pattern
gulp.watch(path.join(conf.paths.src, '/app/**/*.js'))
.on('change', callAMethod);
If yes then please suggest some links Where I can read about it and which is the better way to handle the errors? also, where do we write else part in the later method style?
They are both different.
The first one is a callback to the gulp.watch method and it gets all the events that the watcher produces
The second one does not provide a callback, instead it subscribes to one event (change) produced.
The watch method returns a Gaze object and to handle errors, subscribe to the error event:
watcher.on('error', function(error) {
// Handle error here
});
Gulp4 which is still in alpha stage uses chokidar. To watch for errors, it's exactly the same as the above:
watcher.on('error', error => log(`Watcher error: ${error}`))
These functions are different.
Gulp uses a utility named glob-watcher for handling file changes and the first one is a callback called by glob-watcher.
The second one is a raw event from Event Emitter (NodeJS Emitter or Chokidar) instance.
Some events from EventEmmiter propagate to glob-watcher callback - for example, "change", so it may look the same on the first look.
For handling errors, I recommend having a look at gulp-plumber plugin.
I am trying to use a MutationObserver inside my addon. Therefore I inject a content-script which then sets the observer. This somehow seems to work, also the detected mutations seem not be be serializable to JSON.
But actually I want to use this library for monitoring mutations. Explicitly this one is officially mentioned by Mozilla regarding mutation monitoring in addons. But this doesn't work at all.
So anybody got a working example for a working mutation-observer (better mutation-summary - see link) inside a content-script?
My code looks like this:
var observer = new MutationObserver(function (mutations) {
self.port.emit("domModified", mutations); //I gets received as 'Array [{}]'
mutations.forEach(function (mutation) {
console.log(mutation.type); //printing mutation results in {}, printing mutation.type results in an actual string
console.log(mutation.target);
console.log(mutation.addedNodes.length);
});
});
observer.observe(unsafeWindow.document.body, {
attributes: true,
subtree: true,
characterData: true,
childList: true
});
This somehow seems to work, also the detected mutations seem not be be serializable to JSON.
Mutations are not serializable, especially because they contains nodes. If you need to pass something from the content script, to the main add-on code, you need to be sure they're JSONable values.
So anybody got a working example for a working mutation-observer (better mutation-summary - see link) inside a content-script?
I never used the library you mentioned, but I used mutation observers quite a lot; and they're working quite fine. You can see an example here: https://github.com/ZER0/tweet-to-read It basically adds a button to every tweet in the stream that contains an external URL; and I needed the mutation observer to add the buttons also in future tweets. You can have a look to the implementation here: https://github.com/ZER0/tweet-to-read/blob/master/data/observable.js
Hope it helps.
I want to implement a custom event that can be "broadcast", rather than sent to specific targets. Only those elements that have registered themselves as listeners for such events will receive them.
What I have in mind would look as follows.
First, in various places of the code, there would be statements of the form
some_subscriber.on_signal( 'some_signal', some_handler );
I'm using the term signal as shorthand for "broadcast event". In the expression above, some_subscriber registers itself as a listener of one type (called 'some_signal') of such signals, by providing a handler for it.
Elsewhere in the code, there would be statements of the form
publisher.signal_types[ 'some_signal' ].broadcast( event_data );
When statements like these get executed, a new event is generated and "broadcast". By this I mean that the code that calls the broadcast method has no direct information about the listeners for the signal it is issuing.
I have implemented a sketch of this idea in this jsFiddle, mostly in order to illustrate what I described in words above1. (It's certainly not production-grade, and I'm not particularly confident that it could be made so.)
The key elements of this implementation are the following. First, publisher objects do not keep track of their subscribers, as can be seen in the implementation of a factory method for such a publisher, shown below:
function make_publisher ( signal_types ) {
// ...
var _
, signal = {}
, ping = function ( type ) {
signal[ type ].broadcast( ... );
}
;
signal_types.forEach( function ( type ) {
signal[ type ] = $.register_signal_type( type );
} );
return { signal_types: signal_types, ping: ping };
}
This publisher object exposes only two items: the types of signals it broadcasts (in signal_types), and a ping method. When its ping method is invoked, the publisher responds by broadcasting a signal:
signal[ type ].broadcast( ... )
The ultimate recipients of this broadcast are nowhere to be seen in this code.
Second, elsewhere in the code, subscribers register themselves as listeners of these broadcast signals, like so
$( some_selector ).on_signal( signal_type, some_handler );
Note: It is basically impossible to illustrate the rationale for this scheme using an example that is both small and realistic. The reason for this is that the strength of this scheme is that it supports very loose coupling between the publisher code and subscriber code, and this is a feature that is never necessary in a small example. On the contrary, in a small example, code that implements such loose coupling invariably comes across as unnecessarily complex. It is therefore important to keep in mind that this apparent excess complexity is an artifact of the context. Loose coupling is very useful in larger projects. In particular, loose coupling via a publisher/subscriber-type pattern is one of the essential features of MVC.
My question is: is there a better (or at least more standard) way to achieve this effect of "broadcasting" custom events?
(I'm interested in both jQuery-based answers as well as "pure JS" ones.)
1An earlier, ill-fated version of this post was met with almost universal incomprehension, and (of course) the all-too-typical down-voting. With one exception, all the comments I got challenged the very premises of the post, and one directly questioned my grasp of the basics of event-driven programming, etc. I'm hoping that by presenting a working example of what I mean at least it won't come across as utterly inconceivable as it did when I described it in words alone. Luckily, the one helpful comment I did get on that earlier post informed me of the function jQuery.Callbacks. This was indeed a useful tip; the sketch implementation mentioned in the post is based on jQuery.Callbacks.
All right.
So I think what you can do is use the native dispatchEvent and addEventListener methods and use document as the only element for both publishing and subscribing to those events. Something like:
var myCustomEvent = new Event('someEvent');
document.dispatchEvent(myCustomEvent);
...
document.addEventListener('someEvent', doSomething, false);
And to make cross-browser, you could:
var myCustomEvent = new Event('someEvent');
document.dispatchEvent(myCustomEvent);
...
if (document.addEventListener) {
document.addEventListener('someEvent', doSomething, false);
} else {
document.attachEvent('someEvent', doSomething);
}
You can read more on the subject here and here. Hope this helps.
My question is: is there a better (or at least more standard) way to
achieve this effect of "broadcasting" custom events?
No, there is not a more standard way of doing publish/subscribe in Javascript. It is not directly built into the language or the browser and there are no platform standards for it that I'm aware of.
You have several options (most of which you seem aware of) to put your own system together.
You could pick a specific object such as the document object or the window object or a new object you create and use jQuery's .on() and .trigger() with that object as a central clearing house to cobble together a publish/subscribe-like model. You could even hide the existence of that object from your actual use by just coding it into a few utility functions if you want.
Or, as you seem to already know, you could use the jQuery.Callbacks functionality. There's even publish/subscribe sample code in the jQuery doc.
Or, you can find a third party library that offers a somewhat traditional publish/subscribe model.
Or, you can build your own from scratch which really just involves keeping a list of callback functions that are associated with a specific event so when that event is triggered, you can call each callback function.
If you came here looking for the jQuery way of doing this, here you go:
Add the event broadcast/dispatch code:
Syntax:
$(<element-name>).trigger(<event-name>);.
Example:
$.ajax({
...
complete: function () {
// signal to registered listeners that event has occured
$(document).trigger("build_complete");
...
}
});
Register a listener for the event:
Syntax:
$(<element-name>).on(<event-name>, function() {...});
Example:
$(document).on("build_complete", function () {
NextTask.Init();
});
Note:
Doing it this way: $(document).build_complete(function() {...}); leads to an error: Uncaught TypeError: $(...).build_complete is not a function.
I know this has been marked as answered back in 2015 -- but a solution that is also elegant and simple could be to use Redux
I'm developing this small website : Website ; and I'm using HammerJS as a touch support library.
It seems to be responding to the events, and it recognizes the event.type property, but when I'm trying to get the event.direction or other related properties to the drag event nothing is output in the console ( I'm logging the results in the console ).
This is how I listen for the drag event "
Application.ApplicationController.prototype.Drag = function(selector, delay, callback) {
return $(selector).on('drag', _.debounce(function(event){
event.preventDefault();
return (typeof callback === 'function' && callback !== undefined) ? callback.apply( event, [ event ] ) : 'Argument : Invalid [ Function Required ]';
}, delay));
};
I'm calling it something like :
this.Drag(selector, delay, function(event) {
console.log(event.type, event.direction);
});
Could someone tell me what am I doing wrong in there or if I'm missing something ?
EDIT : I have just replaced the jQuery library : jquery.specialevents.hammer.js ; with the old jquery.hammer.js ; and it seems like now it's responding to all events and I get all the properties I should. Still I would like to know why isn't the one I tried to work with working ?
EDIT : I have found the underlying cause of my issue, my code depends on some libraries which I'm loading asynchronous with the Yepnope script loader, so somewhere along the way instead of loading all the libraries ( including the jquery plugin for hammer.js ), some of them are lost :) I have fixed that issue and now the events have the properties that they're supposed to.
Still I would like to know why isn't the one I tried to work with working ?
Understanding the difference between jquery.specialevent.hammer.js and jquery.hammer.js should help understand the problem. Damien, the creator of jquery.specialevent.hammer.js, explains why.
However Eight Media decided to create their own namespace in jQuery to
activate the events.
$("#element").hammer({ /* options */ }).on("tap", function(ev) {
console.log(ev);
});
So in the end they are not using the default
jQuery eventing system. That means my existing source code which used
jQuery mobile events has to be change. That’s why I decided to
implement the use of Hammer.JS with the jQuery special eventing API.
$("#element").on("tap", { /* options */ }, function(ev) {
console.log(ev);
});
I put jquery.specialevent.hammer.js onto my
Github where you can also find a demo. Maybe Eight Media accepts my
pull request and it will be part of Hammer.JS.
event.gesture.direction should get you what you are looking for.