In the tutorials, I’m asking the learner to write some code to incorporate in a mainly already written App, so I’ve no control over what they write, but I do want to provide some feedback on where it’s gone wrong
Getting Code in the right order
You can’t really dictate the order Apps Script loads your scripts in, so it can be difficult to avoid accessing classes and namespaces before they are defined. Here’s how I do it.
This is a special problem for Immediately invoked function expressions (IIFE) , or ‘iffys’ used to make namespaces. These are executed when the scripts are loaded, so you have absolutely no control over these.
Say you have 4 seperate scripts files like this, you run the risk of trying to access things before they are defined
When you run ‘main’, you’ll get this
Let’s not do that then – but we do want to keep those iffys, as they are handy to keep the global namespace free of accidental noise.
You can solve this by returning property getters, which will postpone the attempt to access anything until they are actually invoked by your main script.
Here’s script 2 and 4, rewritten with property getters.
… and now it works
Centralizing all the accessed namespaces and classes gives you flexibility on ‘post-processing’ of these classes and iffys – I’ll give and example in a moment but first let’s create an Exports object in a new script and define each of these scripts in it.
Now we are accessing each of the classes and iffys via a central Exports object. This means we can fiddle with their definition without needing to change any other code. Let’s say that the Fr and En iffys now came from libraries (a common requirement when developing or testing libraries). All we’d need to do is modify the Exports object like this, and all references in all your scripts would immediately switch to the new definition.
Validating property access
Let’s enhance the scripts a little.
Now we get this
A common problem is misspelling a property name, so this
That ‘undefined’ is a real problem. We didn’t notice it was an error, so now all kinds of things might go wrong later in the script, and it’ll be hard to track down the root cause.
and use that guard function to police access to the objects we are Exporting. First though we’ll need to add an instation function in place of ‘new’ when creating a class. The final 5 scripts now look this this.
Let’s see what happens when we try to access a non existent property again.
Perfect – now detect and say goodbye to those missed typos whenever you make them!
Checking function arguments
In the tutorials I’m working on at the moment, there’s sometimes a need for the learner to supply a function, for example to compare values, where the values are properties plucked from an object. Here’s a simplified example in the context of our scripts so far.
Which gives this result
But if the property name is wrong, it will silently appear to do the sort, but give the wrong answer. Much better if we can have a reusable way to check the validity of the property argument. Yes – we can use the guard function again.
Here’s a guarded version
This works as before, but this time if we accidentally pass a typo as the property name, this happens.
These approaches have saved me endless debugging time, especially with the added complication of testing incremental code in tutorials. I highly recommend you give it a go.