AMD Consistency

[jeffrose]

This topic came up briefly in a previous AMD issue.

In AMD it's typical for a module to return a handle to the functionality it provides. It becomes a little less clear what to do when the module represents a plugin or there is a centralized namespace also receiving the functionality like with CanJS.

I think the important thing is to be consistent and CanJS is not quite so.

Observe plugins, i.e. can/observe/*, return a handle to Observe or Observe.List, which I think makes sense; however Control and Construct plugins, i.e. can/construct/* and can/control/*, return a handle to can instead. I think it would be more consistent if they returned Construct and Control respectively.

While can/util/deferred provides both can.Deferred and can.when, the when method is also added to the Deferred object, which means you could return just Deferred from the module.

All of the core modules, i.e. can/*, return appropriate handles, e.g. can/route returns route, except for can/view which returns can instead of view.

The can/view/ejs and can/view/mustache modules both return can. At the very least they should probably return view but there's probably an argument to be made that they should return EJS and Mustache respectively.

There may be other modules one could argue for a change in what is returned, but these were the ones that stood out to me.

In regards to EJS and Mustache, now that CanJS has more than integrated view engine, the can module dependencies should be updated. Currently it includes can/view/ejs. Either it should...

• Include only can/view and force the developer to pick an engine
• Include can/view/library similar to can/util/library, which defaults to EJS but would allow the developer to override it with a configuration mapping.

The latter seems more in line with what CanJS has already done.

[daffl]

I think these are good suggestions and will mark it for 1.2. The problem is, that when changing the module return value all the code referencing that module (AMD or Steal) needs to be changed. We also need a way of documenting the module return values.

Also, EJS and Mustache have to return then can Object because it is being used in pre-compiled scripts. I think we are going toward Mustache as the standard templating engine for 1.1. Mapping it like the CanJS library is a good idea.

[jeffrose]

While it's not about consistency, I actually noticed another dependency-related issue. can/observe/compute does not list can/observe as a dependency but makes use of can.Observe.

[daffl]

For 1.2 I also want to remove the global can object if and AMD module loader is available (you can currently disable it with window.GLOBALCAN = false; but it hasn't really been tested yet.

[justinbmeyer]

People can overwrite the can module to require other things.

I don't think we should remove the global can:

https://twitter.com/TalentedMrJones/status/309481689468506112

[justinbmeyer]

on can/compute, it should be made to work without can/observe, but be able to work with it if it's present.

[jeffrose]

jQuery was kept in the global scope not for the sake of typing convenience, but for 3rd-party plugins that don't support AMD and expect it to be in window.

http://bugs.jquery.com/ticket/10545

can does not necessarily have the same baggage.

[roelmonnens]

We have a very large website.
This website contains several different modules.
We also have a header with some little applications in it.
This header is loaded in every module.

Now for the little apps we use canjs 1.0.5. For a new module we are currently canjs 1.1.5 (the AMD-version).

The problem that we are having right now is that if I'm loading the topnav in the new module then the global can is being overridden with two versions of canjs.

No I was hoping that if I updated these little apps to an AMD version I could contain the version of canjs within the scope of that script. But if this isn't the case like mentioned above I have to rewrite these little apps so they can work without canjs because for future modules we want to use future code of canjs. But there isn't always the time to update the topnav to the new version and certainly is no time to update all old canjs-modules.

Because of this, I think it's better to remove can from the global scope.

edit:
window.GLOBALCAN = false;
Seems to be working!

[justinbmeyer]

I think GLOBALCAN is a good enough solution for now. If someone has problems with this, we can add can.noConflict() type thing that restores the original can.

I'm not sure why AMD would complain though ... as long as you are using the can passed to you, you should be fine.