Instead of making the above SpreadsheetApp and DocumentApp calls, I would just call IntegratedApp.getThingWidth() and then define what that meant within the IntegratedApp wrapper object to match the application using it. I ended up calling my wrapper object IntegratedApp, and all it really did was provide a common interface for the rest of my code to use without caring about which app it was for. On the other hand, if you had started with a wrapper object that abstracted away which specific G Suite app the add-on was for and an i18n object to hold all user-facing strings, then porting or translating your add-on would be much easier, faster, and less error-prone. Original UI in Docs/Sheets/Slides (left) redesigned UI in Docs/Sheets/Slides (right) Or if you update the UI for one of multiple add-ons that are basically the same, you will have to move those changes over very carefully to make sure you don’t break anything in the other add-ons-which you probably weren’t thinking about very hard when making the updated UI. If you’ve hardcoded every API call to SpreadsheetApp.getThing().getOtherThing().getWidth(), then you’ll have to replace it with DocumentApp.getDifferentThing().getWidth() all throughout your codebase. If you’ve hardcoded every string relating to spreadsheets, you’ll have to hunt them all down to hand them over to your translator and then manually put them back in. Or even if it will never be ported to another G Suite app, you may want to release translations of it in Spanish, French, German, and Chinese. Unless your Google Apps Script add-on’s purpose is extremely specific to Sheets (for example), you will eventually want to port it to Docs. #2: Hardcoding app-specific strings and API calls So make sure you set this up at the very beginning. In fact, if you set up git hooks that upload your changes automatically, it will be no different than a typical feature branch workflow (don’t forget to squash). It’s a lot like using file-by-file copy-paste, except it makes the computer do all the boring and repetitive parts that are vulnerable to human error. Luckily, you can avoid this entire mess-and keep using your favorite IDE-by using the Google Drive REST API to import and export your code instead. That complexity means you should be using professional-grade source control and good engineering practices instead of hacking away and hoping for the best while trying to remember which files have, and have not, been copy-pasted recently. Otherwise, you could tough it out for 30 more minutes and be done with it. Well, I’ll tell you why: the fact that you’re asking yourself this means that you’re dealing with a nontrivial degree of complexity. “Why not just do my work in and then copy-paste it to the script editor afterward?” you’ll ask yourself. It’s certainly enough to get small projects working, but once you are dealing with more than a handful of files, you will eventually reach your breaking point, and that’s when the second temptation will kick in. The built-in script editor offers minimal source control options, bare-bones search functionality, and a text editor that will get the job done but lacks quality-of-life features like automatic closing parenthesis insertion and simultaneous multiple line indentation. However, like most temptations, it comes with a heavy cost later on. You can just click “Tools > Script editor” and then jump in and start coding immediately. That’s what makes the built-in script editor so tempting: you don’t have to set anything up or read any documentation. It’s always a chore doing the prep work necessary to be effective in a new environment when all you really want to do is jump in with both feet and start experimenting with APIs, and starting a new Google Apps Script add-on is no exception. Let’s get started: #1: Coding your Google Apps Script add-on in the built-in script editor I realize that there are traditionally seven deadly sins, but I couldn’t think of a seventh that was sufficiently sinful, so we’ll have to go with six. In particular, I’ve focused on things you might consider doing to save time or effort that will end up costing you dearly. As someone who has been down that road before, I’d like to share some of the mistakes, missteps, and blunders I’ve either fallen victim to or narrowly avoided, what I’ve learned from them, and how you can chart a course through the Google Apps Script add-on development process that bypasses them completely-without having to program in Vigil. So you want to build an add-on for Google Docs, Sheets, or Slides, but you’re worried about ending up on the highway to development hell? You’ve come to the right place, then.
0 Comments
Leave a Reply. |