ChatGPT is pretty much a universal API: one endpoint to get any data.
ChatGPT has recently taken the world by storm. Unless you have been living under a rock, then you have certainly seen a variety of content on this topic. One of its greatest advantages is its ease of use, and it is perfectly usable in Google Apps Script. With that in mind, here is one use case that we can implement: generating fake data.
Fake data is useful for testing purposes. At times, real data is too sensitive, and sometimes you do not have access to real data before production, but you need to begin working with something. Here is where fake data comes in.
We used to have a great library for fake data called Faker.js; however, Marak, the author, became so frustrated that he could not monetize the solution that he pushed an update that broke everything, which led to him being blocked on GitHub and NPM. As a result, the library is no longer maintained. ChatGPT, however, is not going anywhere.
Illustration by ahmiruddinhidayat111198 on freepik.com https://www.freepik.com/author/fahmiruddinhidayat111198
The
onEdit
trigger is likely the most used trigger in Google Apps Script. It runs automatically with an event object whenever you change a value in a spreadsheet — programmatic changes excluded — thus allowing you to execute a script based on context. When done properly, it can be extremely powerful. When done wrong, however, it can feel unreliable and messy.
In this article, we will learn to avoid three common pitfalls:
Not Exiting Early
Making a Single Function Do Everything
Expecting onEdit to Catch All Changes by Default
For this purpose, we will build a simple script to handle a task list in Google Sheets. It will do two things: add a checkbox next to new tasks and add a completion date when each task is checked as done.
When working in a team and/or with a client, you want to have multiple environments. At minimum, you probably want a dev environment (or multiple ones) in which you are working, and a test environment in which the client or your team can run acceptance tests before production. Of course, they must both be separate from the production environment. To push your code to the correct environment, you need to either update the
.clasp.json
file manually or keep multiple copies of your script with different
.clasp.json
files. Fortunately, things have just become significantly easier, as I recently built an app for this purpose called
clasp-env, which is available on NPM. See the source link for details.
No Google Apps Script SDK for your favorite API? No problem!
I’ve never seen a Google Apps Script SDK made available as part of an API, as, surprise surprise, it’s not the most popular choice for professional development. It’s time to start changing that, so we will learn to build our own!
[Editor note: Really impressive work from Dmitry providing a framework you can use to develop your own service for interacting with 3rd party APIs. The post includes lots of clear instructions and guidance to help you understand and learn about approaches for structuring your Google Apps Script code projects]
When it came out, the new Google Apps Script IDE was, of course, a big deal. It’s way better than the legacy one. It brought syntax highlighting, keyboard shortcuts, command palette and just a much better UI experience.
In fact the reason it’s so good is that it’s built on top of VS Code Monaco editor. But it’s definitely still far away from what a real VS Code installation can do. You can get all the functionality of the online IDE and much more more: autocomplete, custom themes, installation of modules, linting, snippets, etc.
Give your scripts privileges that your users don’t have … In 99% of all cases, authorizations in Google Apps Script are extremely straightforward. When a user executes their script, they run it as themselves with their respective authorization scopes. … However, what if you need to give more rights to your app beyond what your intended users will have? … This is where service accounts come in.
A useful post to find out more about service accounts and how to use them with Google Apps Script. The tutorial put together by Dmitry Kostyuk includes example code for using a service accounts with Firestore, BigQuery and the Admin Directory API.
Build your own functions in Google Sheets that do anything you need them to in a few lines of code.
This is a great tutorial if you are interested in finding out more about developing custom functions in Google Sheets. The post includes everything you need to get started from handling single cell and range inputs, to documenting your function so that users see inline help.
Google Apps Script is an amazing language that can automate a lot of your work. However, working with GAS also means that you have to learn to live with its built-in limitations and quotas. One such quota is the total script runtime. …I have experienced that the time required to complete tasks like copying or even simply listing files on a drive or in a directory can be quite long. Merging hundreds or thousands of documents can also take longer than both thresholds. Now let’s look into how we can build a solution
Another community contribution looking at handling script runtime and this one is also worth looking into for tips on structuring your code. The tutorial includes lots of useful information and an explanation of what is going on and might be a useful example to look if you are interested in moving your Apps Script coding abilities to the next level.
The basic principle behind tracking Google Sheet opens is the same as the one behind email tracking with a transparent pixel. In a Google Sheet, we will use the IMAGE()function, which will call a deployed Google Apps Script web app URL with some parameters in the query string. The web app will be able to do whatever you need among the following: record to a spreadsheet, create a message via a messenger, or simply send an email.
Unit testing is an extremely important practice. It helps developers avoid bugs easily and lets you know when something is broken immediately. … There are numerous libraries that exist for unit testing in JavaScript, including Jest and Mocha; however, they aren’t necessarily well-adapted to run under the Google Apps Script environment. … For that reason, I built my own library with Google Apps Script in mind.
We’ve featured a couple of community contributions around Google Apps Script Unit Testing and if this is a topic that interests you then the related posts section below will link to additional resources. This post from Dmitry Kostyuk is a great addition and the accompanying
UnitTestingApp
library that is shared in the post has some very useful Google Apps Script related features such as a dedicated method to check your data is a 2D array (particularly useful in the context of handling spreadsheet values). Follow the source link for more details…
A lot of users try and quickly learn GAS and use it to make their lives easier. It’s all great, however the code we sometimes tend to come across on StackOverflow and other sites lacks best practices, hence I thought it was time to start bringing them up and I will start today with design patterns.
As noted by the post author Dmitry Kostyuk the Google Apps Script V8 runtime opens up many new coding opportunities previously not available to Apps Script developers. Using the common use case, fetching data and writing it to a Google Sheet, Dmitry explains how the façade and proxy code patterns can be used to write efficient easy-to-read code.
