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. 💃🕺
Hey there, friends! 👋 Our Emojibar — yes, that’s what we’re calling it now — is coming along nicely! In the previous post, we learned how to bundle the project with Vite and vite-plugin-singlefile, and it’s now time to add some real functionality!
To complete our Emojibar, we’ll use two NPM modules:
Unicode-Emoji-JSON: We need a complete list of emojis, and this simple module provides them in JSON format. Perfect!
ToastifyJS: When users click on an emoji, it’ll be copied into their buffer. Just so they have some feedback, we’ll show them a confirmation toast. This library is great for this purpose.
We’ll also add search and navigation functionality, meaning that we’ll have the entire backbone of the application ready by the end of this post.
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?
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.
According to Wikipedia, the Game of Life “is a cellular automaton devised by the British mathematician John Horton Conway in 1970.”
It begins on a two-dimensional grid of square cells. Each cell can be either alive or dead. Every cell interacts with its eight immediate neighbors. A live cell only remains alive if it has two or three living neighbors. If it has fewer than two living neighbors, it dies as if by underpopulation. Conversely, if it has more than three, it dies as if by overpopulation. A dead cell remains dead unless it has exactly three living neighbors; otherwise, it becomes a live cell, as if by reproduction.
There is no immediate practical use for the Game of Life in a spreadsheet; however, it is a fun algorithmic challenge. Moreover, Google Sheets natively provides us with the perfect data structure: a two-dimensional array. This is all the more reason to work on those array skills!
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]
