redopop / dq Goto Github PK

It's currently named callback which is confusing. eachItem may be a better name.

dq();
q('method');

This is not an edge case. Very common for <script async> use.

To take advantage of browser caching, it's common for optimized RequireJS builds to distribute modules across multiple files (one for common components, and one that's more page-specific).

In such cases, it seems appropriate and DRY to register modules without dq'ing. Currently, the two are tightly coupled: the only time you can register modules is when you want to dequeue your entire list of calls.

An alternative: dq currently throws an error when it encounters modules that haven't loaded. Instead, it could implicitly understand that a second dq call will follow. This way, modules can be registered and executed asynchronously.

q('module.submodule.method')

The code for resolving these paths is borrowed from this gist, but there is no test in dq covering it.

Add a test to make sure q('moduleName.methodName') results in methodName being called with moduleName as its context.

Related to #2 — this use of dq currently fails.

Calling dq multiple times results in previously queued items being called again with the same params.

This could be handled more gracefully by emptying the queue for subsequent dq calls.

Current test runner is pure JS only. Add an AMD test runner to make sure dq is healthily maintained for that environment.