Mastering Google Apps Script: Deploy Once, Run Everywhere đ
Whatâs The Issue? đ€
Building add-ons with Google Apps Script is akin to owning a magic wand for distributing your application. And if youâre like me, youâve probably created an army of internal add-ons for clients and personal use, especially those sweet editor add-ons. But hereâs the catch: every time you deploy your add-on, you need to specify the script ID and the deployment version for each context (Docs, Sheets, Slides, and Forms). Keeping up with 4 different files isnât just tedious; itâs like trying to juggle flaming swords while on a unicycle đ. But donât worry, thereâs a better way!
Taking JavaScript to the Next Level with TypeScript for your Google Apps Script Projects
A Warm Welcome Back to the Series đ
Hey there, and welcome back to our hands-on series on mastering Google Apps Script UIs! Now, if youâre serious about JavaScript, itâs high time we chat about TypeScript. TypeScript is a superset of JavaScript that brings static typing to the game. Itâs like JavaScript put on its best suit and turned into a more organized, reliable version of itself. đ
The reason a lot of developers are switching to TypeScript is because it can catch errors at compile-time, making debugging less of a headache (itâs like having a personal assistant who checks your work for mistakes so you donât look silly later). In this part, weâll let the Emojibar project rest (itâs earned it, after all!), and weâll switch over to a different repository I frequently use as a boilerplate for my projects. This boilerplate is a work in progress, so donât be surprised if it changes faster than you change your socks. đ
Streamlining Your Development Workflow with Multiple Deployment Environments đ
Kickoff: Marching Towards Deployment
Welcome back, dear coders! Our Emojibar is not just a fun prototype anymore â itâs a full-fledged tool ready to be unleashed into the wild. But before we let it run free, we need to get our house in order, or in our case, our environments. And no, Iâm not talking about recycling, though you should be doing that too!
Professional development calls for setting up different environments â itâs a bit like having different outfits for different occasions. At the very least, youâll want to have a development environment where you experiment and break things (yes, itâs encouraged!), a User Acceptance Testing (UAT) environment where your users can give your app a test drive, and a production environment, the red carpet where your app shines.
Hey there, code wranglers! đ€ Welcome back to our Google Apps Script (GAS) UI series. Today, weâre venturing into the wild world of Single Page Applications (SPAs). For the uninitiated, a SPA is a web application that interacts with the user dynamically, rewriting the current web page with new data from the web server, instead of the default method of the browser loading entire new pages.đ
No worries if âNavigoâ sounds like a hip new dance move. By now, you should be pretty comfy with installing dependencies from NPM. But if not, itâs like adding a shiny new tool to your utility belt. It just gives you the superpowers you need to build your web app.
Welcome Back to Mastering Google Apps Script UIs: Client-to-Server Communication Spotlight
Oh, howdy folks! Just like a boomerang, youâve found your way back to our marvelous series. If you thought the previous episodes were fire, wait till you see whatâs cooking today! đ„
Weâre diving headfirst into the world of client-to-server communication. Itâs like passing notes in class, but with a lot less paper and a lot more code. đâĄïžđ»
Hereâs the catch though â we canât install Google Apps Script locally to run things on our dev server. Yep, thatâs right. Itâs like trying to install a toaster in a bathtub; it just ainât happening. đđ«đ
But fear not, dear coder, for Iâve got a trick or two up my sleeve. Weâre gonna finesse our way around this with some snazzy hacks like promises, polyfills, and mocks. Oh my!
Well, well, well! Look whoâs back for another session of âWeaving Magic with Codeâ! đ Today, weâre diving head-first into the magical world of unit testing. You might be wondering: âWhy the fuss about unit testing?â đ€
Unit testing, my friends, is the silent hero of software development. Picture it as a mini-pit stop where your code gets a once-over before it hits the road. The automated tests ensure that our code does exactly what we expect it to. The benefits?
Makes us ponder deeply about our appâs architecture, like a philosopher musing about the meaning of life đ§
Forces us to clarify our expectations from functions and classes.
Ensures that as we revamp and update our code, we arenât unknowingly playing host to bugs, much like a surprise party you didnât want đ
Welcome back, code wranglers! Today, weâre diving into the world of developer dependencies that make developing projects more efficient than a coffee-fueled coder on a deadline. đ You can find the complete source code in the part-04 branch of the Github repository. Also, feel free to mess around with this demo spreadsheet and play with Emojibar. I’ll be updating it with every new blog post!
What Are Dev Dependencies?
Dev dependencies are like your carâs GPS: theyâre not necessary for the car to run, but they sure make getting to your destination a lot easier! đșïž Theyâre modules necessary for the development and testing processes of a project, but not for its production runtime environment. Theyâre not bundled with the source code and help automate tasks that would otherwise make you pull your hair out.
Letâs take our UI to the next level with Tailwind CSS!
Introduction
In the previous article, we learned how to bundle NPM modules with Vite. Today, weâre going to add some style with Tailwind CSS. If youâve been following my series, youâll breeze through this like a true professional. đ
Check out the part-03 branch in the Github repository for the full source code.
What Is Tailwind CSS
Tailwind CSS is a utility-first CSS framework that makes styling a breeze. Think of it like a wardrobe filled with every piece of clothing that youâll ever need, with everything neatly organized and ready to go. đđș
Last week, we talked about the best way to build front-ends for Google Apps Script. Today, letâs roll up our sleeves and dive in! đ
As I mentioned in my previous post, weâre going to create a super cool sidebar in Google Sheets thatâll help us select emojis with ease. đ Google Docs already has this functionality natively: simply head over to the âInsertâ menu, select âEmoji,â and voilĂ ! Youâll see a neat dialogue window with all emojis organized by category, as well as a handy search function:
However, we want more, so, weâll be building our own version. đ Unlike Docs, weâll have a full sidebar to work with, and clicking on an emoji wonât automatically insert it. Instead, itâll copy it into our buffer, so we can paste it wherever we need it. đ
That being said, letâs dive into using our most important tool: Vite. âĄ
Welcome to the Ultimate Google Ultimate Google Apps Script Front-End Development Guide!
If you are reading this post, then you likely have experience with Google Apps Script. Essentially, there are three types of front-ends that you can create with Apps Script:
Web apps
Modal/modeless dialogues
Sidebars
In this blog post series, we will only discuss HTML front-ends, as this is where you can create the most powerful and sophisticated user experiences. Unfortunately, the Card Service is outside the scope of this series, and it is not nearly as powerful as an HTML front-end. With that in mind, Google, how about allowing HTML front-ends for Workspace add-ons?
