// Basic approach. Does not try to register in | |
// a CommonJS environment since jQuery is not likely | |
// to run in those environments. See next file | |
// if you want to opt in to CommonJS too. | |
(function(factory) { | |
if (typeof define === 'function' && define.amd) { | |
// AMD. Register as an anonymous module. | |
define(['jquery'], factory); | |
} else { | |
// Browser globals | |
factory(jQuery); | |
} | |
}(function($) { | |
$.fn.myPlugin = function () {}; | |
})); |
// Includes registering in a CommonJS environment, | |
// but it is unlikely jQuery will run in a CommonJS | |
// environment. See other file if you do not want | |
// optional CommonJS registration. | |
(function(factory) { | |
if (typeof exports === 'object') { | |
// Node/CommonJS | |
factory(require('jquery')); | |
} else if (typeof define === 'function' && define.amd) { | |
// AMD. Register as an anonymous module. | |
define(['jquery'], factory); | |
} else { | |
// Browser globals | |
factory(jQuery); | |
} | |
}(function($) { | |
$.fn.myPlugin = function () {}; | |
})); |
This comment has been minimized.
This comment has been minimized.
er... also! thanks a bunch! |
This comment has been minimized.
This comment has been minimized.
Ah, thanks there was a ) missing, at the end of the file. I updated the gist. |
This comment has been minimized.
This comment has been minimized.
What is the point of using Would it not be simpler to remove the root argument and not scope the jQuery reference? |
This comment has been minimized.
This comment has been minimized.
@Zoramite: in 'use strict' mode if you just use |
This comment has been minimized.
This comment has been minimized.
@jrburke: it makes sense that you are referencing the global by using the Or, if you want to keep the |
This comment has been minimized.
This comment has been minimized.
@Zoramite, good question. This template comes from a branch of Backbone where I added optional AMD registration, and as part of the Backbone code, they also allowed using jQuery alternatives like Zepto and Ender. So that else block looks something like the following -- actually a bit more complicated, but for jQuery it is basically this:
If just However, if you did not want to support those alternatives to jQuery, then you could get by with just Another reason to use just Great questions, and good to have the discussion of these variations. When I move this code to the umdjs effort, these variations are definitely worth mentioning, and I would probably start with your suggestion to just uses |
This comment has been minimized.
This comment has been minimized.
@jrburke, thanks for the details! I still feel like a JavaScript noob. I didn't even know Zepto and ender existed. :( For simplicity, I would go with the most concise version that doesn't pass root as the default and have an alternate example that shows the root argument with the jQuery alternates and/or how you would add a custom version of jQuery, etc. I'm guessing that 95% of the people that use this as a boilerplate probably wouldn't know/care about the extra things that you could do and just want an easy way to make it compliant with the AMD registrations. And the 5% that do care would look at the alternate example and probably know enough to add in their own definitions as part of the wrapper/additional arguments. |
This comment has been minimized.
This comment has been minimized.
Since stateful plugins require more code complexity, passing the plugin as an argument to the top closure becomes difficult to read. I've created a fork that defines the plugin's https://gist.github.com/1372424 Any thoughts, or issues you think this might have? |
This comment has been minimized.
This comment has been minimized.
@ryanfitzer, That looks similar to my original idea. I'm still not sure which one I like better. It seems the code having it all in one closure with local variable for the plugin's factory etc is easier to read. But the example from this gist seems a little more concise which I like. As for the |
This comment has been minimized.
This comment has been minimized.
I was trying to try this syntax out today and I ran into a bit of an issue. I'm not sure if it is an issue with how we are using the factory or with the RequireJS library itself. I changed my gist to reflect the syntax used here and to show the problem I am seeing: https://gist.github.com/1371054/a8413aca42314b32e2c1949536c41dc430db95f4 In In Is this expected behavior and I am just missing something? |
This comment has been minimized.
This comment has been minimized.
@Zoramite it fails because index2 is asking for the 'scripts/test2' module but that file defines a named module called 'test'. If you use the paths config to map 'test': 'scripts/test2' then ask for require'test' it should work. I updated the gist to not use root as I agree, it is simpler. I also changed it to register an anonymous module. If you did that in your gist, then you would not need the paths config for 'test'. @ryanfitzer: that is definitely a way to go. It requires two levels of indent to start your factory logic, where the above is just one level of indent. The feedback I have gotten so far is that people generally prefer to have less indentation for module boilerplate. However, I can definitely see it as a style preference. I previously did a "put the adapters at the bottom" approach in this file. However, at least when I initially tried that for my backbone branch, the feedback I got was that the tertiary to pass in define seemed unusual, and that version relies on the AMD loader to use Function.prototype.toString() to find the require('') dependencies. And for backbone, since it wanted to get root/the browser global to find a previous Backbone, it ended up needing another level of indentation. |
This comment has been minimized.
This comment has been minimized.
Agreed that it is more concise. Mine is different (but related) in that it addresses the needs of more complex plugins. Ones that require larger APIs and can maintain separate states for each collection they're called on in a page.
It's become quite popular, but I've adopted it due to its readability. Like an opening paren, but more so, it signifies that the function will be immediately executed. Ending any function with
I first saw it used in Qwery.js. Looking at Qwery again though, I see they have reorganized it into the same pattern as above. Looks a lot more readable than I'd expected. It visually separates the exporting business from the plugin business much better than mine. I've updated my gist to the above pattern. I guess I just needed to see an example with a lot more code to be persuaded :) |
This comment has been minimized.
This comment has been minimized.
@jrburke I have seen the light :) |
This comment has been minimized.
This comment has been minimized.
@jrburke, I tried to change the names of the modules to match the filename and that didn't change anything. I didn't try to add it to the paths. When I made it into an anonymous module it worked as expected. Seems kind of strange that having it as a named module would cause the dependency to fail, even when it matches the name of the file. |
This comment has been minimized.
This comment has been minimized.
I just added a version that does not do optional CommonJS registration, since jQuery is unlikely to run in those environments, but there is also a version with optional CommonJS registration. @Zoramite, I changed test2.js to be a named module with name 'scripts/test2' and then in index2.htm require 'scripts/test2' and then your previous gist works for me. |
This comment has been minimized.
This comment has been minimized.
@jrburke, I guess that makes sense. It it using the full path as the module name. |
This comment has been minimized.
I think you missed a ')' there on line 14?