|Page 1 of 1||[ 6 posts ]|
Why is this important? Isn't setTimeout(0, fn) good enough? The bad thing about setTimeout is that when you pass a low value, it ignores you. There is a minimum number of milliseconds that it will use. There are other negative effects when using very short duration timers. Here's the spec and some articles:
https://dvcs.w3.org/hg/webperf/raw-file ... rview.html
http://ie.microsoft.com/testdrive/Perfo ... fault.html
http://www.nczonline.net/blog/2011/09/1 ... immediate/
Node.js has a similar feature called process.nextTick. It describes it as 'much more efficient'.
http://nodejs.org/api/process.html#proc ... k_callback
Y.soon is the public interface I made. It accepts a single argument, the callback function. It returns an object with a cancel method just like Y.later. The polyfill in gallery-soon contains six different implementations of Y.soon. It is pretty quick: http://jsperf.com/y-soon-vs-settimeout
One design decision I made that I'm sure will be questioned: I don't use Y.bind, accept a context object, or arguments. I found that in my own code, I was usually using closure variables and had no need for a bound context. I decided that the overhead it costs wasn't worth it. Developers can easily Y.bind callbacks themselves when necessary.
Eventually I abandoned my work on promises in favor of qr-codes. Recently, Luke Smith has implemented deferreds and promises and has submitted a pull request to YUI. I suggested Y.soon for use within his promises implementation; that is in fact the exact reason I originally made it. His pull request contains a check for the existence of Y.soon and falls back to setTimeout. The question has been brought up as to whether gallery-soon should be promoted to YUI core. There are several very good arguments both in favor of and against.
I'll offer my opinion and if there is a sense of agreement here, I'll work on a pull request.
I don't think gallery-soon as it is should be pulled into core. Others have already pointed out that it's a huge hack and there are concerns for unit testing and cross browser maintainability. I am aware of several potential risks in the code that could break things or cause security vulnerabilities. I don't think these risks are high (they might not even exist) but they haven't been thoroughly investigated. I've personally been using gallery-soon in a number of projects without any issue, and I'll encourage everyone to use it, but that alone doesn't mean it meets the code quality expectations of a YUI release. This doesn't mean it will never happen; someone would need to take the time to explore the large number of edge cases, write tests, documentation, etc.
I do think Y.soon should be pulled into core. I propose the following:
A new YUI core module called 'soon'. It would have two implementations of Y.soon interface and use conditional loading to pull the correct one. In Node.js it would be a YUI friendly wrapper around process.nextTick. In all browsers, it would be a shortcut for Y.later(0, null, fn); This would be a helpful API normalization over these environments. Once browsers start implementing it, a YUI friendly wrapper around setImmediate should be added as well. Those two or three implementations should be easy enough to write tests for and maintain. There is little to no hacking involved.
I would like to separate the gallery module into a number of smaller modules. Once 'soon' is a core module, developers could just use it or decide for themselves if they would like to replace it with 'gallery-soon-postmessage' or 'gallery-soon-readystatechange' and set up their own conditional loading strategy. It will also make it easier for other developers to invent their own crazy implementations.
Steven, sounds like a great idea...
Here's a couple of things I'm thinking:
1. I like the idea of a `Y.soon()` interface which simply wraps `process.nextTick()`, `setImmediate()`, and `setTimeout()`. I think this would be a very useful (and simple) function to add to YUI core.
2. I don't think this needs to be a separate module, it can simply be a function provided by the `yui` module.
3. I don't think it should delegate to `Y.later()`, there's too much stuff going on in `Y.later()` that isn't needed for this. Although I do like the idea of returning an object with a `cancel()` method (but that's just a simple closure around the returned result from calling the underlying impl fn.)
4. I like the idea of keeping `gallery-soon` which augments `Y.soon()` to provide other impls.
Thanks! I spent a while debating with myself but eventually agreed with all of your points.
I'll get started on this in the coming weeks as my schedule allows.
So thinking about this more, I think there's another aspect that should be considered.
There can be cases where we want code to execute async, but before the next DOM repaint. Using `setTimeout()`, we'll be forced to wait for the next repaint. Therefore I think we might want to consider using one of the hacks for non-IE browsers (assuming that `setImmediate()` will call the callback before the next repaint.)
I can't say when it executes, but according to MDN:
This method is used to break-up long running operations and run a callback function immediately after the browser has completed other operations such as events and display updates.
|Page 1 of 1||[ 6 posts ]|
|You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum