Set of always wish had utility functions #342
Conversation
// Exporting `enqueue` alias as `defer` may conflict with promises. | ||
exports.remit = defer; | ||
exports.Enqueued = function Enqueued() { | ||
console.warn('Function was renamed to `defer` please use it instead.') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we print stack trace on warnings, so it would be usefull to give more information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we print stack trace on warnings, so it would be usefull to give more information.
I think stack trace would add too much noise here. What about just 'Enqueue' function was renamed to 'defer' please use it instead.'
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure!
assert.ok(delayed, 'delayed the function'); | ||
done(); | ||
}, 150); | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is many chances that this test will have intermitent failures on slow hardware.
You may take a look at setTimeout unittests:
https://github.com/mozilla/addon-sdk/blob/master/packages/api-utils/tests/test-timer.js
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not true, order of timeout calls will be adequate of the timer ms regardless of soft / fast hardware. And that's only thing we test here.
I don't think it is relevant to use the metadata until the feature is landed. In term of code, it looks good, just some minor stuff to check. But I have some more general concerns:
Having said that it doesn't make sense to block this pull request as it fits into our review/code guideline, so I'm r+ it (with licence/ownership issue being addressed). But I'd like to engage a discussion during our weekly meeting about such choice. |
Oh and if you land it, can you stash the history before landing it. |
I'll remove it for now
Nope I have implement their APIs, also as matter of fact there are slight differences as well. On the other hand I did took their examples.
I personally have not had a need for that, but I'm open to that if you think it would make more sense.
I'm trying to improve code readability by reducing unnecessary noise from the code, and eliminating patterns used all over the place. I do agree that code may get little bit harder to debug, but on the other hand this makes it much less code to debug. Also composition has major testability advantage since if you're function |
So
|
@ochameau before landing this I'd like to know:
|
Set of always wish had utility functions r=@ochameau
So this change implements set of utility functions that are super useful every now and then, but I always either was implementing them in place or tried to avoid them all together. I have faced the same thing once again when working on new events #312 and finally I have decided to put these together. Also since it does not really relates to the events work I cherry-picked these changes into separate (this) branch.
So this adds some utility functions and also normalizes
Enqueued
into defer to match backbone. Still I keepEnqueued
with a deprecation warnings.