Skip to content

Further AMD Support Improvements #155

@jeffrose

Description

@jeffrose

I am glad to see the improvements in AMD support introduced in 1.1.0. Looking through the code I still see a couple areas where it would be in CanJS's best entrance to leave certain decisions up to its users.

Avoid Version References

In order to avoid a maintenance headache, anyone working within an AMD environment has found a way to deal with version numbers. Most likely, they have a mapping of ids to actual versioned file names.

require.config( {
    "path": {
        "zepto": "zepto-1.0rc1"
    }
} );

CanJS should publish what versions are officially supported but avoid referencing the actual versions in the code. Leave it up to the developer to decide what version is provided. Otherwise users are dependent on the CanJS team to perform an update when a new version of a library is released. While CanJS 1.1.0 was written to use dojo 1.8.1, it will likely work just fine with 1.8.2.

Avoid Global Variable References

jQuery technically does not follow the AMD specification because even though it defines itself, it still puts variables in the global scope. This was a decision made for backwards compatibility. Those trying to adhere more strictly to the AMD specification have likely found ways of dealing with this, e.g. calling $.noConflict( true ). In such situations, making references to jQuery without requiring it will not work. For example in can/util/jquery, jquery is among the dependencies and assigned to $ but there are references to jQuery in the code.

define(['jquery', 'can/util/can', 'can/util/array/each'], function ($, can) {
    // _jQuery node list._
    $.extend(can, jQuery, {
        trigger: function (obj, event, args) {
...

Instead of referencing the global variable, make a local variable based on the dependency.

define(['jquery', 'can/util/can', 'can/util/array/each'], function (jQuery, can) {
    var $ = jQuery;
    // _jQuery node list._
    $.extend(can, jQuery, {
        trigger: function (obj, event, args) {
...

It would also help to avoid issues like jupiterjs/jquerymx#134.

Avoid Internal References

There are references to specific 3rd-party libraries in the CanJS code, some of which do not exist in zip file downloaded from the site, e.g. 'can/util/yui/yui-3.7.3', 'can/util/mootools/mootools-core-1.4.3', etc. Unless these files are somehow different from the ones provided by the library's site, just use a reasonable id, e.g. 'yui' and leave it up to the developer to map that id or their copy fo the library. If it's not clear what the id is referencing, just provide a comment or documentation.

I am definitely excited by the progress CanJS has made. Thanks for all the hard work!

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions