I made a pack for managing notifications of Google Calendar events. After connecting a Google account, the pack enables setting notifications for events using the SetNotifications Action, and retrieving the notifications for an event using the Notifications and IsDefaultNoifications Formulas. You can also delete or restore the notifications to the calendar default with the ClearNotifications Action.
Notifications are set by specifying the method used for delivering the notification, as well as the number of minutes before the start of the event when the reminder should trigger.
Let me know if you would like a copy of the single-file source code for creating your own copy of the pack in the web-editor. Otherwise, you can clone the repository and follow the guide here: Pack Studio: Beta to create a pack and upload the code. Here’s a link to the repository on GitHub:
In any case, you will need client credentials to authenticate with the Google APIs. You can create your own by following the steps on this page Using OAuth 2.0 for Web Server Applications  | Google Identity  | Google Developers . You will need to create a project in the Google Cloud console. Include the calendar.events and calendar.calendarlist.readonly scopes in the credentials you create. Then, copy the ID and secret from the Google Cloud console and set the pack’s credentials by following this guide: Authentication - Coda Pack SDK .
Last note, just want to thank the Coda team for building the Pack Editor experience. I am thoroughly impressed by the quality of the SDK. It is very powerful and straightforward to use, and the documentation (and typing) made the onboarding enjoyable.
What’s next?
I’m not super happy with the way the SetNotificationsAction currently works. I will investigate whether this is an issue with my usage of the SDK, or a limitation of the Coda platform. From there I may modify the API for this Action accordingly.
Congrats on building your first Pack @loucadufault ! As someone who uses Google Calendar notifications often that seems like a useful feature.
Unfortunately folks aren’t able to use that Pack URL just yet, as during the Beta we haven’t enabled installing Packs from the Gallery (except for the users who created them). I would be interested in seeing your source code though once that available! And let me know if you have any other feedback about the development experience.
I transformed the single source file from the web-editor into multiple files. Let me know if you want a link to the “flatter” single-file source code, it might be easier to go through.
I’m not super happy with the way the SetNotifications Action currently works. I will investigate whether this is an issue with my usage of the SDK, or a limitation of the Coda platform.
It has to do with how the varargs are interpreted by the GUI for creating and defining the parameters for an action formula.
Specifically, the SetNotifications action accepts a required event parameter, followed by an optional calendar param, and then any number of varargs as pairs of method, minutes. However, the GUI can only display the fields for the event and calendar button, after which the plus button to insert new fields disappears:
Opening the formula editor for the action shows that the underlying formula is “satisfied” with only the two present parameters, which I guess is why it does not continue to allow adding new fields:
Thanks for the detailed response! I hadn’t realized that we aren’t showing vararg parameters in the builder dialog, but I have been able to reproduce it myself. I’ve opened a bug with the team to see if we can fix that.
An alternative in the mean time could be to have a single string parameter that uses a custom format. For example “email: 30, popup: 5”. It would require users to learn about the format, but it may be easier than popping open the formula editor.
Yea that’s a good workaround. Maybe a List could work, like List('email', 5, 'popup', 30). In any case since for the moment usage is restricted to power users it should be fine to require opening the formula editor.
Unfortunately formula parameters can’t contain mixed types. So you could select the parameter type coda.ParameterType.StringArray and just know that they’ll all the numbers will be converted to strings.
Actually if there is one thing I would change about the sdk API, it’s to make the arguments of the execute callback be keyworded. I find that it becomes error-prone to keep track of the exact order of parameter names in the list (the first parameter to the execute function) and match them to their order of definition. Having an object instead would be cool, as you would not have to worry about order. And similarly you could destructure the object in the function signature to extract the parameters by name. This would however enforce that the function parameter names be the same as when they were defined, but that does not feel too strict of a convention. It might also enable better type-checking.
