Using JavaScript Libraries in DNN

In December 2013, version 7.2 of the DNN Platform was released, which included a new type of extension, the JavaScript Library. At Engage, we've found this to be very useful to us in many scenarios, and we've been investing in creating a solid body of libraries, but I don't think that many other developers or theme designers are aware of it and how they can make use of it.

JavaScript Library packages are deceptively simple. At one level, they just package a single JavaScript file. However, the existence of this package provides a number of straightforward benefits:

DNN allows multiple versions of a JavaScript Library package to be installed, so different extensions can request different versions.
However, if different extensions on the same page request different versions, the highest version wins, which reduces script conflicts.
The library defines metadata about the JavaScript library, such as where in the document it is included (e.g. html5shiv is automatically included in the page's <head>, but most other libraries can wait until the end of the </form>, speeding up initial rendering time)
Additionally, a CDN URL can be included with a JavaScript package, allowing a host administrator to flip a switch and benefit from globally distributed versions of the script (this also provides the benefit of domain sharding). Along with this, a JavaScript expression to test is also included, so that DNN can fallback to the local version of the script if the CDN is inaccessible.

So, how do I get these wonderful benefits in my DNN website? The first step is to check out the Usage section of the wiki article on JavaScript Libraries, and see what it looks like to use JavaScript Libraries in your own extensions. Once you're ready to use them, you'll need to have them available to you. Engage has created a handful of packages for libraries that we're using (see them on the Forge), but I'm sure that this doesn't contain every library that you might use on your site or in your extensions. If you grab a copy of our JavaScript Libraries repository on GitHub, there is a PowerShell script in there to generate a package based on information from Bower. Reach out to me on Twitter if you're interested in contributing more packages.

The real benefit of JavaScript libraries starts to come when they're used by more and more components in a website. Let me or other folks working on DNN or in the MVP group know what you need to make better use of features like this that DNN provides, so we can create the best platform for your web applications. If you're interested in helping out, the README in Engage's GitHub repository has a Roadmap section with some ideas.

Comments

The library system still doesn't handle multi file dependencies does it? Most of the libraries I would want to use this feature with have a css file.

Also many libraries contain a core library and additional optional files. Having to create a separate libraries for each of theses seems kludgey if this is not handled.

Jonathan Sheely Friday, January 23, 2015 5:39 PM (link)

I definitely agree that it will be better when these libraries can easily package CSS alongside the JavaScript file; however, I think that even if you're including the CSS yourself, you still get benefits from the JavaScript being in a library, even if you're not getting _additional_ benefits with the CSS.

Are you referring to something like Bootstrap, which has a single JS file that contains a number of different plugins. You could include a single plugin, or the single file that includes them all. In this scenario, I'd think that there would be a JavaScript Library for each individual plugin, and then, perhaps, a library that represents all of those together (see https://github.com/EngageSoftware/DNN-JavaScript-Libraries/releases/tag/jQuery.cycle_2.1.5 for an example; the JavaScript Library code could handle this better, but it works). Is your issue just that it's difficult to create a package for each plugin? Or something different?

Thanks for the feedback, I appreciate getting more folks thinking about these.

Brian Dukes Friday, January 23, 2015 5:49 PM (link)

I was thinking more like AngularJs that has the core library angular.js but then has version dependent addins like angular-sanitize or angular-route

im not sure it makes sense to create a package for for each individual file vs one package that could include them all. (assuming you cant already do that)

Jonathan Sheely Friday, January 23, 2015 6:10 PM (link)

I have been trying to use this feature also, and was discouraged by the lack of support for css and granular script files.

Bruce de Beer Saturday, January 24, 2015 12:01 PM (link)

@jsheely So, is this just a packaging issue, or do you envision that your interactions with the API would be different? We can definitely create a single zip that includes many JS Libraries (and I don't know why I didn't think to do that with my jQuery.cycle2 example); it would just be a manifest with many package elements. Does that sound like what you're looking for?

@Bruce & @jsheely, can you give me an idea of how you'd like to see CSS files included? Would we add a CSS library extension type, or would we associate a CSS file with a JavaScript library? Would it be included on the page automatically, or would you explicitly request it?

Brian Dukes Monday, January 26, 2015 11:23 AM (link)

In an ideal world I would like to see an API like this. Then the resource package just needs to allow for this type of API.

1. Loads the entire package. If there are 10 resources added into the manifest it will load all 10 (css,javascript)
ResourceManager.Load("AngularJS");

2. Load a specific version. Again will still load all files associated with this version of the package.
ResourceManager.Load("AngularJS","1.3");

3. Load specific files from the resource package. Instead of loading everything you get just what you want.
ResourceManager.Load("AngularJS","1.3","angular");
ResourceManager.Load("AngularJS","1.3","angular-sanitize");

I could see some additional flexibility in the overloads to perhaps only load all CSS files or all Javascript files. I'm not married to that overload variable order / typing but I think it expresses my thoughts.

Jonathan Sheely Monday, January 26, 2015 11:41 AM (link)

It would be kind of nice if you could just enter a GitHub url and that contains a maintained list of common libraries which you can just install into DNN. Kind of like NuGet does for Visual Studio.
These would make adding all those common libraries a breeze.

@jsheely I do like the ideas on how to load the libraries with multiple files/css/packages

Mark McAvoy Monday, January 26, 2015 12:30 PM (link)

@Mark doesn't the Forge provide this for DNN?

@jsheely If I were to create an angular package that didn't its own JS file, but had dependencies on "angular-core" and "angular-sanitize", I could then call JavaScript.RequestRegistration("angular"), and get all of the resources related to that package. To me, that feels better than having to pass specific files from a package. Is that enough of what you're looking for, or am I missing it?

So we need the ability to define CSS libraries, and define dependencies between the different client resource library types. And then a unified API, in addition to the JavaScript API. Sound right?

Brian Dukes Tuesday, January 27, 2015 5:17 PM (link)

@Brian
Thanks for bringing these issues to the surface. We've had a lot of issues with this because of the sheer complexity when trying to create ready-to-use Apps. For example, packaging the scripts together w/the App made sure the App worked - IF no other modules or the skin happened to do something to the page before our App got to do something.

The problem is - it only works if everybody uses this. Otherwise it fails. I'm thinking of assembling DNN-Best practices, this sounds like a must-have!

Daniel Mettler Friday, January 30, 2015 5:21 AM (link)

Products

Solutions

Resources

Partners

Community

About

New Community Website

Using JavaScript Libraries in DNN

Comments

Comment Form

NewsArchives

ESW Operations, LLC