New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AMD Consistency #211

Closed
jeffrose opened this Issue Dec 14, 2012 · 8 comments

Comments

Projects
None yet
4 participants
@jeffrose

jeffrose commented Dec 14, 2012

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

This comment has been minimized.

Show comment
Hide comment
@daffl

daffl Dec 18, 2012

Contributor

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.

Contributor

daffl commented Dec 18, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jeffrose

jeffrose Jan 25, 2013

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.

jeffrose commented Jan 25, 2013

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

This comment has been minimized.

Show comment
Hide comment
@daffl

daffl Mar 7, 2013

Contributor

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.

Contributor

daffl commented Mar 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Mar 7, 2013

Contributor

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

Contributor

justinbmeyer commented Mar 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Mar 7, 2013

Contributor

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

Contributor

justinbmeyer commented Mar 7, 2013

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

@jeffrose

This comment has been minimized.

Show comment
Hide comment
@jeffrose

jeffrose Mar 13, 2013

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.

jeffrose commented Mar 13, 2013

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

This comment has been minimized.

Show comment
Hide comment
@roelmonnens

roelmonnens Apr 23, 2013

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!

roelmonnens commented Apr 23, 2013

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

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Sep 20, 2013

Contributor

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.

Contributor

justinbmeyer commented Sep 20, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment