JavaScript libaries

You can load the javascript library from a trigger  and then include it in your published file, or attach as a web object and then load it from a trigger.

The character limit is a storyline limitation for variable.

How?

This should point you in the right direction https://www.youtube.com/watch?v=wlZWbpB2UR8

Here is a clear description on how to add external Javascript libraries and a sample of it.
https://community.articulate.com/discussions/articulate-storyline/how-to-add-jquery-or-anyother-external-javascript-library-to-storyline

Wondering why this gets reported immediately after posting.

https://community.articulate.com/discussions/articulate-storyline/how-to-add-jquery-or-anyother-external-javascript-library-to-storyline

Adding some extra text after the link... see if this works..

Hi Math,

It appears that your first post was flagged as part of our spam filtering; as you have thought, it's probably because of the hyperlink. Our team monitors flagged posts for false positives and releases them to the community as soon as possible. Your post is now live; feel free to delete the duplicate if you wish.

My apologies for the inconvenience, and you shouldn't run into this issue again.

At the risk of showing my ignorance (which is legendary), can I ask a question on this topic? If the JavaScript library you are wanting to load has an ESM module format version, isn't it simpler to load it via an 'import' statement in the JavaScript code trigger? e.g.

async function loadMods() {
await import("https://unpkg.com/pdf-lib/dist/pdf-lib.js");
}

I appreciate this function may itself have to be called from an async function. but this worked for me when loading the latest pdf-lib,js library into my notetaker demo I posted a few weeks ago.

By dynamically loading the library in this way there is no need to modify the index.html file at all. Which makes it a whole lot simpler if you are thinking of embedding the Storyline into RISE for example.

With my WebObject solution you neither have to change the index.html. All is loaded automatically. 

When you are certain online sources will stay and remain available...and donot run into Cors issues on the LMS, then your solution works fine. Benefit from the WebObject solution is, that it is always available, and will not be changed or updated if you donot want to.

I prefer the solution Math describes in six months time when you republish you don’t need to remember to edit a file or drop files into the exported scorm. It is foolproof and avoids embarrassment.

Sent from my iPhone

Hi Math, Phil

Thanks for the responses both you guys have way better JavaScript skills than me - but I'm still not sure why I wouldn't use the method I'm suggesting:

• You don't need to amend anything in the exported SCORM or drop any files anywhere in my solution either.
• I generally pick up the  JavaScript libraries I need dynamically from one of the main library repositories like pkg or NPM or GItHub. I don't think they will be going anywhere soon - a lot of code would fail worldwide if they did!
• If I'm worried that the library might change and amendments could affect my code, then I would include the version number in the url - otherwise I pick up the latest version of the library.

It just seems so much simpler - assuming that there is an ESM version of the library available - obviously not all libraries have converted from cjs to the new standard.

Both have pluses and minuses. Both work. Both have drawbacks. Mostly depends on the scenario and scripts you need. If those are always the same...and repeats course after course ( eg. using jQuery ) you can use either method.

Pluses WebObject method:

• Once setup, it is inherited in the Storyline project and you never need to think about it.
• Copying a default course setup like this...and all libraries are available.
• You can easily create custom libraries or scripts and add them.
• Good extendable.
• As Storyline still is 32bit, its fully compatible with SL

Drawbacks

• When you change something to a folder a WebObject points at, you have to remove the WO from Storlyline and add it again.

Pluses using online sources

• Less code needed to load the libraries

Drawbacks

• As its online, you need a live connection
• As its online, your loading times increase. Can have impact on mobile.
• You dont have control over the sources, for some institutions this is crucial
• As it depends on triggers/urls in SL, you need to ensure they work
• As Storyline is 32 bit not all packages/sources will work
• CORS security can block packages
• To make use of custom scripts you need to upload and maintain them

So i do think this depends on personal preference. But when you work with custom developed scripts ( i do ), the WebObject approach is far better.

Thanks Math - I get it now.

Thank you for all the input.

I think this information would be very useful if it were put on the best practices page.

As it's been said, the methods mentioned in this thread all have their pros and cons. But more than anything, this information would be extremely useful if it was placed in a more central place to access. 

It might also be a good idea for a screencast of how all these methods can be accomplished.

Once again, many thanks to you all for the input.