The utility of elgg_require_js() in 1.9
By Steve Clay
I'm not schooled in the best practices of AMD modules, but it seems confusing that we encourage modules to define functions/constructors/objects:
define(..., function (require) {
return { ...methods... };
});...but elgg_require_js() then won't kick off any process. E.g. if you want loading a module to also do something, then the module must be like:
define(..., function (require) {
var export = { ... };
export.init(); // execute
return export;
});So it seems to me elgg_require_js() is not that helpful. Better to just:
// inline in page.
require('...', function (module) {
module.init();
});
It seems more useful if elgg_require_js() would also execute something depending on the type of module. Module is function? Call it directly. Module is object with init() property? Call it.
As is elgg_require_js() seems to encourage creating modules that auto-init, which doesn't seem very re-usable.
Feedback and Planning
Discussions about the past, present, and future of Elgg and this community site.
- moneya@sociabie
moneya - 0 likes
- Evan Winslow@ewinslow
Evan Winslow - 0 likes
- Steve Clay@steve_clay
Steve Clay - 0 likes
- Evan Winslow@ewinslow
Evan Winslow - 0 likes
You must log in to post replies.As is elgg_require_js() seems to encourage creating modules that auto-init, which doesn't seem very re-usable.
.............................................................................................................................................
i agree
Yes, it only really makes sense to require modules that do something. It's up to you to pull out the reusable stuff into other modules.
Benefit over inline script is that we can make it not inline when we decide to ban inline script with CSP.
In general I think we need a framework that takes care of the life cycle issues and we just register callbacks and classes with it. elgg_require_js would become less useful then, too.
Just trying to think of something useful but safe enough to slip into 1.9...
Strawman: elgg_require_js() accepts a 2nd param, $init (function name). This adds inline script to bottom of BODY:
require(['module'], function (module) { module.init(); });
We provide no guarantee of the order of these calls.
Meh. Easier to just output the script yourself, no? No reason to write a php wrapper for that IMO.
Let's think more about the patterns people are using this stuff for and how we might simplify things.