dojo / core

:rocket: Dojo 2 - language helpers and utilities.

The @dojo/core repository has been deprecated and merged into @dojo/framework

You can read more about this change on our blog. We will continue providing patches for core and other Dojo 2 repositories, and a CLI migration tool is available to aid in migrating projects from v2 to v3.

---

Dojo 2 core

This package provides a set of language helpers, utility functions, and classes for writing TypeScript applications. It includes APIs for feature detection, asynchronous operations, basic event handling, and making HTTP requests.

Usage

To use @dojo/core, install the package along with its required peer dependencies:

npm install @dojo/core

# peer dependencies
npm install @dojo/has
npm install @dojo/shim

Features

• Feature Detection
• Language Utilities
  • lang
  • load
  • string
• UrlSearchParams
• Event Handling
• HTTP Requests
• Promises and Asynchronous Operations
  • Promise
  • Task

Feature Detection

Using the latest Web technologies isn't always as straightforward as developers would like due to differing support across platforms. @dojo/core/has provides a simple feature detection API that makes it easy to detect which platforms support which features.

Language Utilities

The core package provides modules offering language utilities. Some of these are heavily based on methods in the ES2015 proposal; others are additional APIs for commonly-performed tasks.

lang

The @dojo/core/lang module contains various utility functions for tasks such as copying objects and creating late-bound or partially applied functions.

load

The @dojo/core/load module can be used to dynamically load modules or other arbitrary resources via plugins.

string

The @dojo/core/stringExtras module contains various string functions that are not available as part of the ES2015 String APIs.

UrlSearchParams

The @dojo/core/UrlSearchParams class can be used to parse and generate URL query strings.

Event handling

The @dojo/core/on module contains methods to handle events across types of listeners. It also includes methods to handle different event use cases including only firing once and pauseable events.

HTTP requests

The @dojo/core/request module contains methods to simplify making HTTP requests. It can handle making requests in both node and the browser through the same methods.

Promises and Asynchronous Operations

Promise

The @dojo/core/Promise class is an implementation of the ES2015 Promise API that also includes static state inspection and a finally method for cleanup actions.

@dojo/core/async contains a number of classes and utility modules to simplify working with asynchronous operations.

Task

The @dojo/core/async/Task class is an extension of @dojo/core/Promise that provides cancelation support.

Code Style

This repository uses prettier for code styling rules and formatting. A pre-commit hook is installed automatically and configured to run prettier against all staged files as per the configuration in the project's package.json.

An additional npm script to run prettier (with write set to true) against all src and test project files is available by running:

npm run prettier

Installation

To start working with this package, clone the repository and run npm install.

In order to build the project run grunt dev or grunt dist.

Testing

Test cases MUST be written using Intern using the Object test interface and Assert assertion interface.

90% branch coverage MUST be provided for all code submitted to this repository, as reported by istanbul’s combined coverage results for all supported platforms.

To test locally in node run:

grunt test

To test against browsers with a local selenium server run:

grunt test:local

To test against BrowserStack or Sauce Labs run:

grunt test:browserstack

or

grunt test:saucelabs

Licensing information

© 2004–2018 JS Foundation & contributors. New BSD license.

Some string functions (codePointAt, fromCodePoint, and repeat) adopted from polyfills by Mathias Bynens, under the MIT license.

See LICENSE for details.

core's Issues

Data not passed in POST request using Node

It looks like core/request/node is not passing the data values correctly when doing a POST request.
Here is a sample to demonstrate.

var request = require('request'); // npm install request
var dojoRequest = require('dojo-core/request').default;
var nodeRequest = require('dojo-core/request/node').default;

// OAuth data
var DATA = {
      'f': 'json',
      'client_id': 'zppZ53G093yZV7tG',
      'client_secret': '123456789', // invalid client secret
      'grant_type': 'client_credentials',
      'expiration': '1440'
    };

// using request
function getToken(callback){
  request.post({
    url: 'https://www.arcgis.com/sharing/rest/oauth2/token/',
    json:true,
    form: DATA
  }, function(error, response, body){
    callback(body);
  });
}

// using dojo-core/request
function getDojoToken(callback){
  dojoRequest.post('https://www.arcgis.com/sharing/rest/oauth2/token/',{
    responseType: 'json',
    data: DATA
  }).then(function(results) {
    console.log('dojo request results', results.data);
  });
}

// using dojo-core/request/node
function getNodeToken(){
  nodeRequest('https://www.arcgis.com/sharing/rest/oauth2/token/',{
    responseType: 'json',
    data: DATA
  }).then(function(results) {
    console.log('dojo node request results', String(results.data));
  });
}

getToken(function(response){
  console.log('native request', response); // works, errors Invalid client_secret as expected
});
getDojoToken(); // errors that client_id not provided, not correct
getNodeToken(); // errors that client_id not provided, not correct

The errors from core/request/node indicate the client_id wasn't provided although it was. If I update this with a valid client_secret I get a valid token using the request module, but still get the client_id error from the Dojo module.

I couldn't quite follow the core/request/node code to figure out where data would be sent.

Thanks!

Debounce/Throttle test cases too fragile

It seems that randomly we get failures to the throttle and debounce test cases. Usually Firefox but sometimes other platforms.

We should find a way to make them more robust.

AMD Plugin Interface

Shouldn't we put the AMD plugin interface as a specified interface either in core, or dojo/loader?

I noticed that in the core/has implementation, it isn't relying upon an interface, therefore potentially exposing an API that isn't consistent. One of the strengths of TypeScript is being able to collate these interfaces and expose them to others.

TypeScript 1.6

There will be some breaking changes in TypeScript 1.6, so opening this for issue for tracking.

Improve request tests

The request tests need to be improved in the following ways:

• Stop shimming XMLHttpRequest
• Implement an echo server:
  • Proxies to Intern's server for everything except /__echo/
  • When /__echo/ is requested, parse the query string, headers, and (for POST and PUT) the data and echo them back in a JSON response (something like { query: { ... }, headers: { ... }, data: { ... } })
  • If the responseType query parameter is included, send data back in the appropriate format (for instance, responseType=document should return HTML)
• Change the intern configuration to hit the echo server
• Write tests to improve coverage, including tests for different response types

Possible features for event modules (on, evented)

Dojo (versions 1 and 2) has three major ways to structure code or enhance functionality:

1. declare, which provides composition techniques (inheritance, mixins, etc)
2. on, evented and topic, which provide event systems
3. aspect, which provides AOP facilities

I've been using YUI3's (imo excellent) EventTarget module extensively for years and am trying to see how the code I've written could be implemented in dojo. After playing with dojo's on and aspect and comparing the approaches to YUI's, I think some of YUI's features could be very useful to dojo as well. Therefore, I would like propose some significant enhancements to the event-style modules.

The most important features that I feel are missing in dojo's event modules are

• Event bubbling
• cancelable events
  • (optional) default functions, which are called if the event has not been canceled
  • (optional) prevented functions, which are called if the event has been canceled
  • on vs. after listeners: on listeners can cancel events, after are only called if the event has not been canceled

Sidenote: dojo's on runs event handlers after the original. To keep backwards compatibility and consistency with aspect, we could call the functions before and on instead of on and after.

Another really neat API from YUI3 is AttributeObservable, which emits (cancelable) events whenever an attribute is changed. This could be a nice addition to dojo's stateful module. (Attribute has features that stateful doesn't have, like default values, validators, writeOnce, which are also very useful.)

I have implemented these features (including tests) as an experiment in ES6 in this repo. I don't mean to propose a merge of this code into dojo, but to show how little code is required. The tests also show the use and usefulness of the APIs.

What do you think? Are these useful additions to the event APIs, or is this too much extra functionality? After all, the on vs. after listeners are in some ways an alternative to aspect. In other words, dojo already offers features to solve problems that on/after can be used for. (I would counter that AOP is a different paradigm, and its existence is no strong reason not to offer an alternative.)

Should I write an example that shows how a problem can be solved with aspect versus on/after to motivate this proposal?

IE10 and .getElementsByTagName

We keep getting failures of the following test for IE10. IE11 appears to be fine:

× internet explorer 10.0 on Windows 7 - unit tests - request/xhr - request options - responseType - xml (0.177s)
TypeError: Unable to get property 'getElementsByTagName' of undefined or null reference
  at Anonymous function  <_build/tests/unit/request/xhr.js:354:25>
  at Anonymous function  </home/travis/build/dojo/core/_build/src/async/Task.js:115:20>
  at Anonymous function  </home/travis/build/dojo/core/_build/src/Promise.js:140:32>
  at Anonymous function  </home/travis/build/dojo/core/_build/src/Promise.js:107:28>
  at executeTask  </home/travis/build/dojo/core/_build/src/queue.js:13:12>
  at Anonymous function  </home/travis/build/dojo/core/_build/src/queue.js:43:28>
  at executeTask  </home/travis/build/dojo/core/_build/src/queue.js:13:12>
  at Anonymous function  </home/travis/build/dojo/core/_build/src/queue.js:67:24>

WHATWG Streams

It looks like the WHATWG spec has had a fair amount of churn, based on this comment: "Although readable streams have been significantly evolved recently due to implementation progress providing feedback, writable streams have not yet caught up to all the discoveries in that space. As such, while the following spec will be the basis for a final API, it is expected to change in several important ways before being ready to ship. Please follow along on the writable streams issues label for details. "

I think we should probably review the changes to the spec since our implementation was last touched 5-7 months ago.

lang needs something that Just Works for simple value copying

I know we are already mulling over how to split up lang.copy to simplify its API and also the mental overhead regarding the combinations it supports. On top of that, one thing it doesn't seem to support is simply copying values, a la lang.mixin in Dojo 1.

Here's an interesting (though probably rather edgy) case I just ran into (trying to use it during development of dom/geometry, dojo/dom#8) that affects various browsers differently, presumably due to how they treat native ClientRect objects:

1. Get a native ClientRect object via someElement.getBoundingClientRect()
2. Attempt to coerce to a plain ol' object by running through copy

Results:

• On Chrome this happens to Just Work as expected - you get an object with the expected properties with numeric values.
• On Firefox (tested 38) and IE (tested 9 and 11), you end up with seemingly an empty object.

Tangentially, I would definitely vouch for not burying sources in a kwArgs object if we can help it, and accommodating one source without needing an array. Having to do that in this case seems rather obtuse. (I realize that other derivative APIs like create and duplicate wrap this complexity away.)

Android - request/xhr ArrayBuffer failure

It appears that updating intern has exposed a test failure on Android:

× android 4.4 on Linux - unit tests - request/xhr - request options - responseType - arrayBuffer (0.192s)
AssertionError: expected 'GIF89a\u0001\u0000\u0001\u0000�\u0000\u0000\u0000\u0000\u0000���!�\u0004\u0001\u0000\u0000\u0000\u0000,\u0000\u0000\u0000\u0000\u0001\u0000\u0001\u0000@\u0002\u0001D\u0000;' to be an instance of ArrayBuffer
  at Assertion.assertInstanceOf  <__intern/browser_modules/chai/chai.js:1084:10>
  at Assertion.ctx.(anonymous function) [as instanceOf]  <__intern/browser_modules/chai/chai.js:4192:25>
  at Function.assert.instanceOf  <__intern/browser_modules/chai/chai.js:2951:35>
  at <tests/unit/request/xhr.ts:418:12>
  at </home/travis/build/dojo/core/src/async/Task.ts:134:12>
  at </home/travis/build/dojo/core/src/Promise.ts:230:15>
  at Object.callback  </home/travis/build/dojo/core/src/Promise.ts:187:19>
  at MutationObserver.<anonymous>  </home/travis/build/dojo/core/src/queue.ts:186:10>

Implement `on.once` and `on.pausable`

We've had a few discussions back and forth on this topic (largely connected to the discussion around extension events), and I did some fumbling around myself.

Ultimately, we have decided to implement once and pausable APIs largely as they existed in Dojo 1.x (though they would be implemented as separate exports of the on module in this case).

• They will accept the same arguments as on
• once will return an object implementing Handle
• pausable will return an object implementing a PausableHandle which should extend Handle with pause() and resume()

Create scripts for release process

We need to figure out what the release process will look like. At this point, it looks like running grunt dist, running npm publish in that directory, and pushing the dist directory to the correct tag in a repository somewhere on Github (for bower). This means that we may need separate repos for the code we publish to bower (mayhem already does). Another alternative might be to create a branch for each bower release, set the version tag to that branch, and have a "src" tag for the source. This whole process needs to be investigated.

Why do we have our own interface EventEmitter in on.ts?

Given that we use node.d.ts elsewhere, should we simply be using its NodeJS.EventEmitter interface, or is there a reason for us exposing a minimal subset here (and relying on it elsewhere e.g. streams)?

on.emit cannot emit a window event

on.emit(window, 'resize', callback); would cause a exception while check the target.ownerDocument

kwArgs

Are we really wedded to kwArgs instead of something like options?

I know it is a small thing, but honestly I never like the name kwArgs, it just seems like some sort of clique sort of argument name, versus something that is a bit more clear of intent. Thoughts?

Issue with location of helpers...

It appears some of the changes made to Intern (specifically how it deals with dependencies) have caused issues with the location of some files and the CI is failing.

Error: Failed to load module leadfoot/helpers/pollUntil from /home/travis/build/dojo/core/leadfoot/helpers/pollUntil.js (parent: tests/functional/text/textPlugin)
  at reportModuleLoadError  <node_modules/dojo-loader/loader.ts:122:44>
  at loadCallback  <node_modules/dojo-loader/loader.ts:884:7>
  at executeModule  <node_modules/dojo-loader/loader.ts:632:52>
  at <node_modules/dojo-loader/loader.ts:620:10>
  at Array.map  <native>
  at executeModule  <node_modules/dojo-loader/loader.ts:614:43>
  at <node_modules/dojo-loader/loader.ts:620:10>
  at Array.map  <native>
  at executeModule  <node_modules/dojo-loader/loader.ts:614:43>
  at <node_modules/dojo-loader/loader.ts:620:10>

`lang.isObject` isn't reliable in ES6 environments

In ES6 environments, Symbol.toStringTag allows modifying the return from Object.prototype.toString.call(o):

var o = {};
o[Symbol.toStringTag] = 'Foo';
console.log(Object.prototype.toString.call(o)); // outputs [object Foo]

CancelErrors on Chrome/Android

There are several tests appear to fail predictably on CI for Chrome/Android:

× chrome on Windows 10 - unit tests - request - browser - .get (5.009s)
CancelError: Timeout reached on chrome on Windows 10 - unit tests - request - browser - .get
  at <__intern/lib/Test.js:162:20>
× chrome on Windows 10 - unit tests - request - browser - JSON filter (5.007s)
CancelError: Timeout reached on chrome on Windows 10 - unit tests - request - browser - JSON filter
  at <__intern/lib/Test.js:162:20>
× android 4.4 on Linux - unit tests - request - browser - .get (5.027s)
CancelError: Timeout reached on android 4.4 on Linux - unit tests - request - browser - .get
Error: Timeout reached on android 4.4 on Linux - unit tests - request - browser - .get
  at <__intern/lib/Test.js:162:20>
× android 4.4 on Linux - unit tests - request - browser - JSON filter (5.017s)
CancelError: Timeout reached on android 4.4 on Linux - unit tests - request - browser - JSON filter
Error: Timeout reached on android 4.4 on Linux - unit tests - request - browser - JSON filter
  at <__intern/lib/Test.js:162:20>

Typings Bundle does not include the whole library...

When I use:

grunt dist

I get dist/typings/dojo-core/dojo-core-2.0.0.d.ts output and it includes all the modules in the root of src, but not the modules in the sub directories src. For example, the file has:

import ObjectObserver from 'dojo-core/observers/ObjectObserver';

but does not have a corresponding declare module 'dojo-core/observers/ObjectObserver'.

While this comes back as a valid file within the repository, when copying dist to another repository, it generates several TypeScript errors about not being able to resolve the modules.

I don't know if this is a dts-generator issue, or something to do with the configuration of it within core.

`request` should append query/cache-bust strings to the end of the URL.

Currently passing in a query string/object or specifying cacheBust: true has no effect.

can you get global from 'global.ts'?

i got an undeifne in amd style

dojo-core/queue does not have default export

Therefore, when importing you cannot do:

import queueMicroTask from 'dojo-core/queue';

You can only:

import queue = require('dojo-core/queue');

core/aspect#on removal?

The on advice is not generally recognised in AOP. The sorts of advice that are recognised are:

• before
• after
• afterThrowing
• afterFinally
• around

Reference Spring and AspectJ.

For ordering of advice, in Spring, there is the concept of advice ordering with the advice specifying an order value and the advice is applied lowest to highest. AspectJ does this via a directive.

Therefore I don't think we should introduce on() advice. It maybe worth considering the other types of advice though.

Add API to dynamically load modules

Because ES6 module imports can only be used at the top-level of a module (they cannot be used inside of a block) and because Node's loader does not understand AMD loader plugins, it would be good to have an API for dynamically loading modules. The API should take a variable number of module IDs and return a promise that fulfills with an array of the module values. At this time, I think this should go into its own module and be called require. The implementation could be as simple as the following:

import Promise from './Promise';

declare var require: Function;

const _require: {
    (...moduleIds: string[]): Promise<any[]>;
} = (function () {
    if (typeof define === 'function' && define.amd) {
        return function (...moduleIds: string): Promise<any[]> {
            return new Promise(function (resolve, reject) {
                // TODO: hook up reject
                require(moduleIds, resolve);
            });
        };
    }
    else if (has('host-node')) {
        return function (...moduleIds: string): Promise<any[]> {
            return Promise.resolve(moduleIds.map(function (moduleId) {
                return require(moduleId);
            }));
        };
    }
    return function () {
        return Promise.reject(new Error('Unknown loader'));
    };
})();
export { _require as default };

Once we have this, the code at https://github.com/dojo/core/blob/master/src/request.ts#L69-L82 can be removed for a dojo-core/require call. In addition, the observers pulled in in observe.ts could be done this way as well as any of the providers in crypto and bundles in i18n.

Promise fulfilled delay failures

We are routinely getting something like the following. We need to figure out if the test is just being temperamental or if there is some problem we are regularly overrunning this timeout:

× firefox on Windows 10 - unit tests - async/timing - delay() - resolves a promise after the given timeout (0.465s)
AssertionError: expected 462 to be close to 250 +/- 25
  at AssertionError  <__intern/node_modules/chai/chai.js:4760:18>
  at [2]</module.exports/Assertion.prototype.assert  <__intern/node_modules/chai/chai.js:203:1>
  at [4]</module.exports/<  <__intern/node_modules/chai/chai.js:1727:1>
  at [9]</module.exports/ctx[name]  <__intern/node_modules/chai/chai.js:3475:18>
  at [5]</module.exports/assert.closeTo  <__intern/node_modules/chai/chai.js:2968:5>
  at ["delay()"]["resolves a promise after the given timeout"]/<  <_build/tests/unit/async/timing.js:21:21>

IE9 - queueMicroTask failure

It appears updating intern has exposed another test case failure:

× internet explorer 9.0 on Windows 7 - unit tests - queue functions - .queueMicroTask() (0.289s)
CancelError: Timeout reached on internet explorer 9.0 on Windows 7 - unit tests - queue functions - .queueMicroTask()
No stack or location

Offloading to native for array.ts

We should offload to native functionality for array when the native functions are available.

README Update

Please confirm the README is updated and accurate for this repository.

Modules being emitted in strict mode breaks global.ts

As of TypeScript 1.8, all modules are emitted with the "use strict"; prologue (see: microsoft/TypeScript#5765). This causes global.ts to return undefined at runtime, versus the global scope.

Inline Source Maps

Currently Intern does not support inline source maps. I have issued a PR (theintern/intern#534), but right now when we get an error, our stack traces are not being mapped back.

I suggest we turn off the inline source maps for a while. We should also discuss if that is what we want in our distribution. I noticed the inline sources is also turned on at the moment. If we build them out eventually, I guess that is fine, but that is a lot of stuff being sent to a client that probably shouldn't.

Proposal: use strict

Shouldn't we be adopting 'use strict'; in all modules (except for global.ts)? It enables the environment to perform optimisations that are still quite significant. While IE9 does not support strict mode, all the other supported environments do.

Better use of Generics

Currently we have a lot of the API that doesn't leverage TypeScript generics effectively. Using generics with type inference will help users of the APIs in TypeScript to generate safer code. Areas where I think we should address generics:

• dojo/aspect
• dojo/lang

handleas option in request

this option seems to be no used in request(xhr), instead, i found the option responseType when i need a json parsing

xhr.ts Istanbul instrumentation

We are getting errors thrown when doing the tests. I think I narrowed it down to Esprima having a problem parsing the emitted xhr.ts file. Previous "fixes" to similar types of issues have been to update Istanbul, which contains more up to date Esprima parsers, but the version of Intern we have is using the latest GA version of Istanbul (0.4.1). I can't quite figure out what structure in xhr.ts is giving Esprima problems.

Extension events

We've had a couple of discussions back and forth on the topic of extension events. I'm opening this issue to document some of the considerations that have come up so far.

• Extension events in Dojo 1 can be kind of hard for devs to wrap their heads around (and hard for us to teach), since it involves providing a function as an event "type", and that function is in turn responsible for listening for any relevant events and firing the listener that is passed when appropriate

• The built-in extension events that exist in Dojo 1 aren't likely to be needed in Dojo 2:

  • The Pointer Events Polyfill is expected to be used in place of dojo/touch
  • All modern browsers support mouseenter and mouseleave
  • a11yclick ideally shouldn't need to exist (see dojo/dom#10)

• That said, there are still cases where essentially "composite" events can be useful; for example, to respond to an enter keypress or a click on a row in a grid:

  function clickOrEnter(node, listener) {
      return on(node, 'click,keyup', function (event) {
          if (event.keyCode === 13 || !('keyCode' in event)) {
              listener.call(this, event);
          }
      });
  }
  
  on(document.getElementById("test"), clickOrEnter, ...);

• Another idea that has been tossed around by one or two people is instituting a registry for custom string event type names.

• One concern that has been brought up in the past is whether something could be done or a pattern promoted to minimize the number of event listeners that are actually hooked up for extension events - i.e., have a document-level handle for each type, to avoid numerous handlers being registered each time an extension event is used

• Possibly a separate consideration, but we also need to support utilities like once and pausable somehow. While it would probably be possible to implement them via Dojo 1 style extension events, one could argue that that's muddying the waters of extension events' intended use (and personally, I'd rather see them implemented in a way that they can be used with aspect too).

I'm starting to throw around some examples in https://gist.github.com/kfranqueiro/b61a0d4d1939063842b2 just to illustrate different approaches.

Cannot have a void return in Promise.then

The promise implementation has an issue when dealing with the onRejected handler that returns a void. Currently, if you assert a type in the then handler, the typings then indicated that that also must be returned from the rejection handler, when in fact a void is a valid return from that. It is because union types cannot resolve to void. The way TypeScript handles this in es6.d.ts is by adding a void overload signature to the appropriate methods. We should do the same.

IE9 posting coverage...

For some reason we seem to be having issues with IE9 at the end of its test in CI. A quick google appears to be related to throwing an error when trying to introspect XMLHttpRequest at the wrong time. I am not sure if it is something in dojo/core or something in Intern that is causing the challenge.

Concerns regarding lang's internal isObject function

This function is used to determine when something should be copied/assigned recursively. It currently returns true for things that report typeof as object that are not Arrays or RegExps. But I would think there are other things (e.g. Date) that should also return false here.

@mwistrand suggested Object.prototype.toString.call(item) === '[object Object]' as a possible alternative that would avoid this slippery slope. Can anyone think of a reason that would be undesirable?

Type has.add better...

The typing of has.add could be improved.

We could have something more like:

export type HasTest = boolean | string | number | (() => boolean | string | number);
export function add(feature: string, value: HasTest, overwrite?: boolean): void { }

Also, was there reasoning in not passing in the global, document, element arguments to a test function?

Implement has loader plugin

dojo-core/has has been implemented, but the loader plugin APIs have not been implemented to allow it to be used for conditionally loading module dependencies.

Conditionally-loaded dependencies look like the following:

• dojo-core/has!feature?featureModule:noFeatureModule to load featureModule if feature is truthy, otherwise load noFeatureModule
• dojo-core/has!feature?featureModule to load featureModule if feature is truthy, otherwise load nothing
• dojo-core/has!feature?:noFeatureModule to load noFeatureModule if feature is falsy, otherwise load nothing

We aren't sure yet how much the loader plugin API may deviate from the current AMD plugin API, so implementing this needs to wait until that is settled. (Or it could initially be developed as a test for whatever new API is taking shape.)

Contextual Load Failures

We are repeatedly getting the following test failures:

CancelError: Timeout reached on internet explorer 11.0 on Windows 7 - unit tests - load - contextual load
CancelError: Timeout reached on internet explorer 10.0 on Windows 7 - unit tests - load - contextual load
CancelError: Timeout reached on chrome on Windows 10 - unit tests - load - contextual load

Publish to npm

We need to publish this package to NPM.

Shim Object.assign?

Instead of creating the core/lang::assign as it is now, wouldn't it be better to shim so it offloads to native assign (and keeps it functionally aligned?)... something like:

interface ObjectConstructor {
    assign(target: any, ...sources: any[]): any;
}

/* Adapted from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign#Polyfill */
let assign = Object.assign ? Object.assign : function(target: any, ...sources: any[]): any {
    'use strict';
    if (typeof target === 'undefined' || target === null) {
        throw new TypeError('Cannot convert first argument to object');
    }

    const to = Object(target);
    for (let i = 0; i < sources.length; i++) {
        let nextSource = sources[i];
        if (typeof nextSource === 'undefined' || nextSource === null) {
            continue;
        }
        nextSource = Object(nextSource);

        const keysArray = Object.keys(Object(nextSource));
        for (let nextIndex = 0; nextIndex < keysArray.length; nextIndex++) {
            const nextKey = keysArray[nextIndex];
            const desc = Object.getOwnPropertyDescriptor(nextSource, nextKey);
            if (typeof desc !== 'undefined' && desc.enumerable) {
                to[nextKey] = nextSource[nextKey];
            }
        }
    }
    return to;
};

Evented and on...

Evented.emit returns void but also at runtime returns the value from method.call, but on.emit returns boolean. They should be consistent.

Build dist and sourceMap/inlineSourceMap conflict

A minor thing, but when you do a grunt dist you get an error: TypeScript cannot use inlineSourceMap and sourceMap together. Ignoring sourceMap.

We should in theory unset that when passing to the compiler in the script.

Test and fix https://bugs.dojotoolkit.org/ticket/18637

Given that IINM a lot of the aspect code in Dojo 2 was brought straight over from Dojo 1, I suspect it has the same issue here. We should port over this fix if the problem exists.

I'd also ideally like to make the aspect code a lot easier to follow in Dojo 2, but that will likely be another future ticket.

IE and subclassing Errors

It appears that either our test is invalid for IE or you can't properly subclass Errors in IE. We keep getting the following on IE10 and IE11:

× internet explorer 11.0 on Windows 7 - unit tests - request/xhr - request options - "timeout" (0.004s)
AssertionError: expected 'Error' to equal 'RequestTimeoutError'

Missing tests for aspect.on

In dojo-core, aspect.after has been split to aspect.after and aspect.on (the latter serving the same purpose that aspect.after with receiveArguments set to true served in Dojo 1).

However, we're currently not testing aspect.on at all. I expect we probably only need a couple of basic tests to hit 100% coverage, since most of the ensuing code path is the same as aspect.after.

Bugs in timeout test and status code handling

The timeout test is currently failing because it is resolving with a status code before the timeout error is thrown, adding a delay to the request that is greater than the duration of the timeout should resolve this.

Additionally, xhr.ts is currently considering any status code less than 200 or greater than or equal to 400 as an error, it should be modified so that it only treats codes less than or equal to 0, or greater than or equal to 400 as errors.

Implement debounce, throttle, and throttleAfter

We should include these utility methods for handling rapidly-firing events. Each of these functions receives a callback function and returns a function.

• debounce calls the callback after the returned function is called any number of times, once it is no longer called for the set period of time.
• throttle calls the callback at most once each time the period elapses, regardless of how many times its returned function is called within that period.
• throttleAfter is like a mix between throttle and debounce - it waits until the period elapses to fire, instead of firing initially and then suppressing additional calls during that period. This is useful if you want to appear somewhat responsive to e.g. resize events (i.e. you don't want to debounce), but the final call is what matters.

All three of these are currently implemented in dgrid/util/misc (throttleAfter is called throttleDelayed there). However, these implementations rely on an explicit context parameter, which it should be possible to remove, more like the implementations in dojo or Mayhem which pick it up based on the context the produced function is called in.

(Ignore the dojo/on/ subdirectory in Dojo 1.10 - that has extension events with somewhat muddled implementations.)

These should be implemented in a separate module, though I'm struggling to come up with a good name for one at the moment. eventUtil or util/event maybe?