Then in Namespaces in libraries and scripts, I showed how you could encapsulate code in its own namespace. Together, these two techniques make a powerful combination to help you avoid rewriting stuff and making global namespace errors. But you have to watch out for a few things.
The key to Sharing code between client and server is this server side code.
paired with this in your client Html template
<?!= requireGs (['usefulThings' , 'clientJs']); ?>
This will bring in any code in usefulThings.gs and clientJs.gs - normal Apps Script files that you can use server side if you want - into your client side script which will then be available for client side use by HTML service.
This version of requireGs allows the client to request any Apps Script file. It may be that you want to lock that down (for example if this project is also being used as a library you may not want to expose a function that can pick up any script file), or maybe you simply prefer to manage access to script source on the server side.
Here is an alternative version where you can manage the scripts authorized for client side execution from the server.
The client requests a set of scripts by referencing a manifest name. requireGsManifest() on the server knows which scripts make up that manifest.
In the client html -
So this can live perfectly happily within the App Script IDE as a .gs file
but this outside a function will cause an error - which is not a bad thing actually, since execution of things in global space often leads to unexpected behavior.
I also use a similar method to pick up pure js that I've decided to maintain in HTML files (as opposed to GS) files. Like requireGs, there's both a manifest and list version.
And my manifests look like this
As discussed in Namespaces in libraries and scripts, encapsulating logically separate pieces of code is a pretty good thing to do. It also helps to enable avoiding some of the pitfalls of embedding executable JS code in the GS IDE.
To recap, you can create a namespace like this - shown here with some variables function that you might otherwise have declared globally
However, using this pattern
so this is fine,
but this is not, since Apps Script would try to execute something using the document object which only exists client side.
You can get round this by equipping namespaces like this with an initialization function in which you embed any code that would otherwise execute
and then when you are ready to go,
Here's an example from one of my add-ins
My html content
I'm picking up all these script files from the Apps Script IDE, some of which I use both server and client side
and this is my main.js - the only Apps Script HTML.js file.
Google Apps Scripts snippets. Why not join our cummunity , follow the blog, twitter, G+ .
You want to learn Google Apps Script?
Learning Apps Script, (and transitioning from VBA) are covered comprehensively in my my book, Going Gas - from VBA to Apps script, available All formats are available now from O'Reilly,Amazon and all good bookshops. You can also read a preview on O'Reilly.
Services > Desktop Liberation - the definitive resource for Google Apps Script and Microsoft Office automation > Google Apps Scripts snippets >