Front-End Dependency Management in Manager?

[jpdevries]

The Problem

Individual MODX Extras load their own dependencies often without checking if they are even needed. For example, you may install a few plugins and wind up with jQuery being loaded multiple times.

The Solution?

For 3.0 I've been wondering if we could add some sort of Front-End Dependency Management. I've been thinking require.js and/or encouraging developments to use feature detection to determine if they should be loading their assets could be beneficial to add to the MODX 3 public API and docs.

I've never used require.js on projects because I haven't been able to justify the weight, but it seems like it could be worth if for something like a Manager interface with plugins that register assets.

I really like this trick of checking if jQuery is available and if so, skip loading it using require.js.

This can of course be done with plain old HTML though, but it isn't exactly as clean or "API friendly". For example, here is the PHP code we use in Redactor for MODX to only include Ace if it isn't already loaded.

$script = <<<HERE
<script>try {ace} catch(e) { document.write('<script src="https://cdnjs.cloudflare.com/ajax/libs/ace/1.1.9/ace.js"><\/script>') }</script>
HERE;
$this->modx->regClientStartupHTMLBlock($script);

which prints this HTML

<script>try {ace} catch(e) { document.write('<script src="https://cdnjs.cloudflare.com/ajax/libs/ace/1.1.9/ace.js"><\/script>') }</script>

Pretty clever, but pretty weird looking right? Even if we recommended this technique I'm not sure anybody would use it, which is why I wonder if the require.js approach might make more sense. Another benefit to require.js would of course be that by using AMD (Asynchronous Module Definition) the scripts for each module would be in their own namespace and wouldn't be at risk of causing any collisions in the global namespace.

Using require.js we could only load Ace if needed like this:

var localAce = 'scripts/ace/ace.js',
paths = {};

try {
  if(ace) paths.ace = localAce;
} catch(e) {}

// set up require
require.config({
    paths: paths 
});

// load stuff
require(['ace', ... ], function($, ...) {
  // run your ace init code
});

[eighthday]

Which extras inject js like jquery? sounds very unlike modx ! In fact the only only one I have come across is AjaxForm, which has params to disable.

[jpdevries]

Which extras inject js like jquery? sounds very unlike modx ! In fact the only only one I have come across is AjaxForm, which has params to disable.

Redactor for MODX, ContentBlocks, AssetsManager to name just a few.

One one hand, you could say it is unlike MODX to use anything other than ExtJS because that is what MODX uses but I think it is a pretty easy argument to make that ExtJS is incredibly unlike MODX (think creative freedom).

[Mark-H]

I think the key to this issue is probably mentioning it's about the manager, not the front end of the site? Op 23 nov. 2015 9:24 a.m. schreef "JP DeVries" notifications@github.com:

Which extras inject js like jquery? sounds very unlike modx ! In fact the only only one I have come across is AjaxForm, which has params to disable.

Redactor for MODX, ContentBlocks, AssetsManager to name just a few.

— Reply to this email directly or view it on GitHub https://github.com/modxcms/revolution/issues/12779#issuecomment-158875477 .

[eighthday]

OK, sorry I thought you meant in the frontend I.e the actual site, not the manager.

[jpdevries]

Ah, sorry for the confusion. I updated the title.

And yes, for an extra to do that would be unlike MODX ;) https://github.com/theboxer/markdown-editor/pull/13

[OptimusCrime]

Good idea, but very hard to accomplish. What about multiple versions of the jQuery library? How will that be handled?

[Mark-H]

Isn't that exactly what require js is for? :P

Definitely a 3.x thing but an area we could use improvement in for sure Op 23 nov. 2015 1:45 p.m. schreef "OptimusCrime" notifications@github.com:

Good idea, but very hard to accomplish. What about multiple versions of the jQuery library? How will that be handled?

— Reply to this email directly or view it on GitHub https://github.com/modxcms/revolution/issues/12779#issuecomment-158924684 .

[pixelfanatiker]

Well, I also had similar thinkings in the past. It would prevent that mentioned problems. But I would say, that a well developed componend has an option to disable or activate libraries that will be used in the frontend. Basically sounds it like an good idea, with a lot of barriers to take. I would prefer a opt-in solution - because I am the chief of my frontend, and not any component ;-)

[jpdevries]

Isn't that exactly what require js is for? :P

Pretty much, ya that and keeping things in their own namespace. In other words AMD. http://requirejs.org/docs/whyamd.html

But I would say, that a well developed componend has an option to disable or activate libraries that will be used in the frontend.

I agree. This is ambitious, but I think it would be interesting to create components that can run different "drivers" to be used within different frameworks. I started really digging into this concept when I finished the scripts for the Eureka Media Browser in VanillaJS because on one hand I patted myself on the back for making the whole thing in VanillaJS and not requiring dependencies. It keeps keep things efficient. However, if you wanted to use Eureka within a project that already uses something like React, it isn't as efficient because much of Eureak's 66KB of JavaScript would not be needed if it could leverage a framework or library, so then it becomes duplication and bloat. I imagine a "React driver" for Eureka would probably weigh around 15KB. More import that file size, imagine if you could switch between drivers and the user would have no idea if they were using the VanillaJS, React, or AngularJS driver because they all look, feel, and function the same.

[alroniks]

Absolutly agree with JP. We use requirejs and AMD in current project (https://github.com/oat-sa/tao-core/tree/master/views/js - it's OS project, so code is open). You just require needed modules to you code and don't care about versions and etc. It's very simple in the fact. Now manager use build script for themes, and it absolutoly normal build js also, collecting dependencies before build. Many developers use require and it works fine.

Ok. On site (that for users) you should have freedom, but in manager should be some strict rules. Extra developer want to be sure, that his code will work propper, if he will follow the rules.