JavaScript placement for large blocks of code

I have a JS trigger in a Storyline 360 project that contains 2 large arrays. I placed the code in a trigger instead of an external file because I hate having to add the external files into the published output each time I publish and am not actually sure how to add external files when publishing to Review. 

Aside from it being a pain to work with the code in the tiny trigger window, is there any other reason why I should consider placing the code in an external file?

 

13 Replies
Sharon Huston

My #1 reason for placing the code in an external file is that I can make changes to the code without re-publishing the .story file.  I recently had a project with about fifteen functions, and if I had been forced to re-publish every time I corrected my stupid programming mistakes I never would have finished the project.  (Soooo not a programmer!)

Nancy Woinoski

Hey Sharon, that is a good point. If I did that it would really change the way I work right now. I am such a visual person that every time I make a change, I  publish which is insane when you thing about it.

I wonder if there is any difference in the performance of the output if you use an external file?

Sharon Huston

Good question!

Storyline takes the code you place on triggers and places it in a file called user.js, which is stored in the story_content folder.  If you open it you'll see Storyline has made your triggers into a bunch of functions.  

It's obviously redundant when you think about it, because when you write external code you're probably calling functions via a trigger, like this:

       myFunction();

and then the bulk of the code is in the external file. 

Storyline wraps your function call in yet another function, so you get

       function Script2()
          {
               myFunction();
         }

There is also a switch statement that determines when to run the user.js functions.

Even if you pasted a bunch of code into the triggers, Storyline would still have to generate the user.js functions.  In my eyes, this means you wouldn't experience much (if any) difference.  If you're really curious you could always publish an identical project with internal and external code, then zip each and compare the total size.

Matthew Bibby
Sharon Huston

Oh, one more good reason to use external files -- I can (for example) write a function to generate a random number, then call it on five different slides without rewriting the code.

This is the biggest reason in my opinion, especially if you need to change that function at a later stage.

It is also worth noting that any JS included on a master slide will be added to the user.js once for each slide that uses the master, which is silly. Obviously, it doesn't have a huge impact on file size, but it is a bit weird.

On the note of making changes to the code without re-publishing the .story file - you can do that anyway by just changing things in the user.js file.

Math Notermans

As Matthew and Sharon point out...biggest plus of code in an external file versus in triggers is reusability over slides. So you create a function once and can use it in any slide anytime.

Depending on how you add that external file ( i use a Webobject to add JQuery, Gsap and my generic_functions.js ) you have to change the url pointing at the Weboject each time you publish.

Small correction: if you update or add a new file into your folder containing your Webobject you have to import the Webobject again and change the url. Else it keeps the older files and not updates anything.

So my workflow is now like this.. i create my scripts...either in triggers, fix things in the console or directly in the user.js. Whenever i think a function i created is solid enough to add to my generic_function.js file i add it inthere and recreate the Webobject so i can use it anytime by calling it. In fact i reuse and add that generic_functions.js in all my projects so i can reuse it always.

Math Notermans

Quickly out-of-my-head several of the functions i have inthere...

docLoaded( )
Gets triggered when a Storyline is loaded and checks the URL its loaded from to see whether its on a LMS or testing locally. If on a LMS it gets the username..if not i sets a Storyline variable to a dummy name

sendEmail( )
This function directly sends email to a specified adress with quite some available parameters.
So  not using the users mail, but using SMTP.

getElementsFromStoryline( )
This function gets ALL elements on your timeline in Arrays to loopover.
I have setup 2 arrays: textsArray and imagesArray. The script checks all elements on a page and adds them to the array, so i can animate all texts and / or images at will. Makes it also easy to create custom state-like animations with javascript.

getTranslateX( )
getTranslateY( )
Two functions i use a lot when animating with GSAP. These get the x and y position of any given SVG element ( all  Storyline elements are ) in screen and thus gives me the possibility to animate precise and perfectly.

changeText( )
A function that has parameters to change any onscreen text in Storyline to whatever text, colour and or size. FontFamily now is not changeable...would be great to figure out too.

For a multigame-setup im working on i do have a lot more..but have to test and doublecheck them before i add them to my generic_functions.js

In fact here you can see the status as is now for this multiuser game..

login to:

https://fontys.talentlms.com/

Username 1: JaapAap
Password: Welkom123!

Username 2: UserDemo
Password: Welkom123!

You can login simultenauously with 2 browser-instances ( only tested in Chrome sofar )… changing ( dragging/dropping ) tiles (octagons) in one instance…you will see direct update in the other.

Kind regards,
Math