Jump to content

Normalizing events and event creation


gcs

Recommended Posts

Most JavaScript frameworks I've looked at that deal with input events (like jQuery) normalize events by checking for the presence of various properties when the event is received. It seems though it should be possible to determine in advance what properties to use by using event creation, e.g. (exception logging omitted for brevity):
var mouseButtonPropertyToUse = "button";var event = null;if (typeof MouseEvent === "function") {  event = new MouseEvent("");} else {  try {    event = document.createEvent("MouseEvent");  } catch (exception) {    try {      event = document.createEvent("MouseEvents");    } catch (exception) {    }  }}if (event && "buttons" in event) {  mouseButtonPropertyToUse = "buttons";}
This seems like it would work, but I haven't seen it done this way in practice so I'm wondering if there are potential problems I'm overlooking.
Is this a viable approach for event normalization?
Link to comment
Share on other sites

That seems like it should work in general. One downside might be that you would need to create several different kind of events and keep track of everything when the script first runs. I guess that could be a pro or a con depending on how your application is set up. If that code only runs once and then things are done through ajax without the page refreshing then it's probably fine. If you're loading pages frequently though then you would need to run the code on every load and it might be inefficient. The approach with normalizing the event as it is received means that you don't need to do any work that isn't necessary, although you might duplicate your efforts. A compromise might be to do normalization as events are received but keep a cache of existing settings so that you don't have to normalize the same event type twice.

Link to comment
Share on other sites

One downside might be that you would need to create several different kind of events and keep track of everything when the script first runs. I guess that could be a pro or a con depending on how your application is set up.

Doing it all in one place would be a 'pro' for me, architecturally at least. Performance isn't much of a concern because whether the work is done up-front or on a per-event basis, it's not likely to be a bottleneck. The reason doing it up front is appealing to me is that all other feature detection (canvas, audio, WebGL, Web Audio, and so on) is done up front, and it'd be nice if event properties could be done there also.

If that code only runs once and then things are done through ajax without the page refreshing then it's probably fine. If you're loading pages frequently though then you would need to run the code on every load and it might be inefficient.

In the given context there won't be multiple page loads (this is for a canvas-based game framework), so I don't think that will be an issue.

A compromise might be to do normalization as events are received but keep a cache of existing settings so that you don't have to normalize the same event type twice.

This is actually what I'm doing currently, but as noted above I'm interested in centralizing all feature detection in one place if it's practical to do so.
The main reason I'm curious about this is that I haven't seen it done this way elsewhere, even in frameworks that do all other feature detection up front, and I just wonder if there's a reason for that. In any case, any further thoughts or suggestions as to whether this method is viable (and why it doesn't appear to be used in practice) would be welcome.

 

Link to comment
Share on other sites

The reason doing it up front is appealing to me is that all other feature detection (canvas, audio, WebGL, Web Audio, and so on) is done up front, and it'd be nice if event properties could be done there also.

I understand the idea, but in practice it sounds very inefficient, it's a lot of extra work if you're talking about a general-purpose framework like jQuery. If someone clicks to load a Contact Us page with just a form on it, there's no reason to detect if the browser supports canvas, audio/video, WebGL, etc, nor is it necessary to normalize every browser event. That's where bloat comes from, and it's definitely detectable. If you're doing this for a specialized site as part of a larger application where the code doesn't need to run more than once, then it shouldn't be a problem.

The main reason I'm curious about this is that I haven't seen it done this way elsewhere, even in frameworks that do all other feature detection up front, and I just wonder if there's a reason for that.

Most frameworks are marketed as general-purpose frameworks, so it doesn't make sense to detect every feature and normalize every event on every page load when you're not going to use any of that. I see people import all of jQuery just so they can have a slightly shorter way to select an element by ID or query selector, even though jQuery is almost 35 times slower at retrieving an element by ID, and 425 times slower at retrieving elements by tag name. But, people like to type $('id') instead of document.getElementById('id') because it's cuter, or something. So the reason why most frameworks don't do all of that detection and normalization upfront is because, in the vast majority of use cases, those features aren't used anyway so there's simply no reason to do the work. It would make more sense to have any framework function that needs those features to first call an initialize function just for that feature which would do the detection or normalization at that point, but only once for each feature. The functions that do that can all go in the same place physically in the code if you want to "centralize" things, but there's no reason to run all of that code when the site isn't going to use those features anyway. The ideal case is to only run detection/normalization on-demand as needed, and to not run it more than once for the same thing. That's ideal in terms of efficiency, and requires some initialization and caching functions for your various features. That seems more elegant to me than a heavy-handed "do everything always" approach.
Link to comment
Share on other sites

Thanks. Yeah, it does make sense that you wouldn't want to do that work up front if you weren't sure it was going to be necessary. As I alluded to earlier though this is for a game framework, which is a case where you do generally know in advance exactly what features are needed.
That said, even the game frameworks I've looked at (which generally do a lot of feature detection up front) don't do event normalization up front, even though it's known in advance that it will be needed. Maybe it's just that event normalization 'on demand' is so common that people tend to do it that way by default, even when doing it up front would be a viable alternative.
In any case, thinks for your feedback on the issue. Obviously it's not a critical design issue in the given context, but it was just something I was curious about.
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...