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?

 

6 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.