Itsy: A Free Pack for Writing Web Apps that Run in Coda

Making Packs
1

IMPORTANT UPDATE: Itsy’s technical approach caused the Codans to recognize a potential security risk and has since remove the ability of the temporary blob storage from hosting content embedded in documents. As such, Itsy() no longer works as expected. However, I will leave this as an interesting legacy Pack with source for no other reason that to demonstrate how to save content into the temporary blob storage.

Read on if you want to see some cool stuff that will never work. Itsy() has bitsy the dust.

Itsy™ is a Coda Pack intended to help you render web apps as components in Coda. You craft the web code; Itsy renders it - plain and simple. No frills, just your HTML apps, widgets, snippets, and entire page documents if you like – all transformed in a manner that requires no servers and no special technical configuration.

image
image1650×422 92.5 KB

This is a “beta” release intended to get some exercise and play time from developers who might find this useful. It is far from perfect or complete, but it is certainly useful for some of my work.

SIGNIFICANT UPDATES:

Eliminate Embed?

I asked, is this even possible? Turns out, it is — because Coda supports the ability for a Pack formula to emulate the properties of the Embed() formula. This is an important improvement because it makes use of Itsy so much simpler.

The Itsy pack now includes ItsyPlus(), a version of the original Itsy() formula that simplifies the integration of web app code while adding a far easier sizing experience.

With ItsyPlus …

  • You don’t need to wrap it inside an Embed() formula; you simply call ItsyPlus with your your web code — i.e., itsyPlus(“your web code”).
  • You don’t need to specify width and height; it supports dynamic sizing of the web app. Just click and drag.
  • You can also embed web apps that depend on external media players like Lottie Files that support configurable parameters.

Expand Embedding Possibilities

Ideally, we want to be able to create better usability and dynamic rendering of embedded web apps. If you attempt to embed this Lottie file in Coda using the embed URL they provide, it works, but it is static.

In contrast, ItsyPlus makes it possible to modify the Lottie parameters in the formula, thus changing how it is rendered. Itsy’s architecture accepts and exposes the Lottie file’s configuration parameters and these can be modified manually or dynamically from your Coda data.

<script src="https://unpkg.com/@lottiefiles/lottie-player@latest/dist/lottie-player.js"></script>
<lottie-player src="https://assets5.lottiefiles.com/private_files/lf30_ps1145pz.json" background="transparent" speed="1" style="width: 300px; height: 300px;" loop controls autoplay></lottie-player>

This makes it fully dynamic -

image
image1970×878 138 KB

20 Likes
2

Well done @Bill_French, you have made a pack to do what I have been doing with my non-pack process - this makes it so much easier. Itsy is based on the same library that we use at Agile-Dynamics.

Its amazing what you can do with this within Coda; however it is a display-only embed - getting data back from the js code into coda is not possible.

I have been using this technique in coda documents for my students in the CoderDojo to teach javascript (as well as HTML and CSS) - its a kind of “Codepen” inside a Coda doc.

There are limits to the size of the code you can run - since it all gets packed into the URL (using Base64) - so the amount of code you can handle is limited. We set up our own server on github to try to expand the amount of code that can be run - but failed. The rules imposed by Coda on embedded <iframe>s prevents it - and limits the process to being a display-only tool.

But making it into a Pack is a huge step forward - very grateful to you @Bill_French, well done indeed.
Max

3 Likes
3

Thanks for the kind words of encouragement, Max. Your post along with some of @Paul_Danyliuk’s posts were key influencers as I probed for a simple and reliable way to script up simple HTML components and use them quickly with less effort. Itsy demonstrates just how lazy I am. :wink:

Right, and I read your post a few times wondering if there wasn’t a way to overcome that because Base64 strings can be quite powerful for many things. I haven’t really tested Itsy to see where the ceiling is for size but I believe it is quite robust.

Itsy also supports minified code blocks. I tested it with your calculator example and it worked fine. I think Itsy will soon have a minifier sister function as well, although, putting it in the Pack sort’a defeats the purpose of transmitting small(er) amounts of code.

I also have not done much testing with encoding issues such as embedded strings and other ways Makers could get sideways with Itsy. We need to see how this concept holds up for every-day users who need to leave Coda’s rails from time-to-time to slum a little with HTML.

Yes, in fact, I have used Itsy to do exactly that in a canvas. As you type the code, the app is updated in near-real-time.

image
image1844×1326 131 KB

3 Likes
4

This is so cool!

So Coda doesn’t block embeds uploaded to the temporary storage? Nice discovery!
How hadn’t I thought of that!

P.S. Oh wait, is there some library behind this too? I thought you just uploaded the html to the temporary storage and served that?

5

That’s exactly what I did. Coda temporary storage is apparently a web server.

Now, this doesn’t rule out the likelihood that Itsy will eventually have more functions that use libraries for certain types of transformations. Just tiptoeing into the water so far. I can see Markdown->HTML, and other types of dynamic blending of data through placeholders.

1 Like
6

ah… @Bill_French

i assumed you were using the itsy-bitsy server which takes the code in base64 and returns a page with your html, css & js (and you returned that as an embed).

we took the library that itsy-bitsy used and implemented on our github webserver.

but you have uncovered a deeper secret labyrinth in the coda servers…

NOW my mind is blown!

now i will lose sleep until i figure out how you did it!

max

2 Likes
7

Ok it will take me some time to fall asleep tonight thanks to @Bill_French, will definitely explore some ideas tomorrow :exploding_head:

1 Like
8

Ha ha! This is exactly how I felt when I realized how simple this approach was. It’s really Codans who deserve the credit for this Itsy bitsy excursion. I was working on a full text search Pack and discovered the temporary file system - one thing led to another, and I had what could be described as the only useful Pack that is nearly as small as the Hello World Pack.

2 Likes
9

Yes, I know. And the naming of this Pack as Itsy was purely coincidental. I looked at its purpose - small, mostly simple HTML blocks of functionality and then asked the thesaurus about small things - “itsy” came right up and without hesitation chose it to be the brand for the greatest smallest functional Pack ever built. LOL

image

In the interest of better sleep - I shared all 80 lines of Itsy’s code to you privately.

5 Likes
10

Playing around with the pack. My first 2c:

I wouldn’t make a separate itsyPlus() formula but rather update the original itsy() one with the new behavior. It’s not that far into pack’s existence to worry about breaking existing behavior with Embed wrapping.

On reporting the data back into the Coda doc — one solution that comes to mind is webhooks. You can set up your web app to send an XHR to the hosting doc and process the payload in automations.

2 Likes
11

Yep, there it is @Bill_French & @Agile_Dynamics.

Every time you press the = button on the calc, the result will be added to the table on the right:

This is actually too cool. This means one can make whatever form layouts, whatever intake fields etc and report the data into my Coda doc. No need for packs, no need for masochistic SVG tinkering, no need for Coda form trickery. This is so huge I secretly weep that I didn’t find it myself :sweat_smile:

P.S. Holy hell, that sweet feeling when all pieces of the puzzle finally click together :smile:

I always wanted custom widgets in Coda and I kinda knew I could just make my own web server but that didn’t feel clean enough. So the path there was:

  • I found the capability to render SVG in images, which was the first step to custom widgets

  • Then @Artem_F found the way to render HTML+CSS in those SVG, which allowed to ditch the low-level rects and leverage the powerful DOM + CSS rendering engine.

  • Then @Agile_Dynamics made the solution with a custom web server so that interactivity could be there

  • Then @Bill_French found a way to ditch the 3rd party server and rock off vanilla Coda.

  • And finally, the recently added webhooks feature in Coda allowed to connect these widgets back into Coda.

Now literally everything is possible.

4 Likes
12

Your 2 cents is always worth many times that; appreciate it. But during inflationary times, it’s at least worth 26.5 cents. :wink:

Thanks! I was considering that but I wondered if there were some users who still want to wrap Itsy functionality in an Embed()? No?

Bingo! Just a matter of time before this would become apparent. I think there are easily 20 more like this that have not yet dawned on us.

Indeed - this was exactly what triggered the idea. I wanted it to be ultra-simple for anyone to use. Your SVG research was also instrumental in nudging my thinking about this problem.

And that said, it’s time to suggest to Codans that the temporary file system should be able to be less temporary for certain use cases, otherwise, we be hittin’ that pack to sustain long-running refreshed web components. :wink:

1 Like
13

There’s just one problem to explore: security.

E.g. in my example I included the API token right in the code that’s open for anyone to see. And there doesn’t seem to be a way around it. The token is set up to have write rights to the whole Coda doc, which leaves it vulnerable to bad actors. There’s no way to limit it.

Even if you somehow conceal the code in the pack, it’s still going to be served through that embed. Anyone can open developer tools and see it in plain text. The only way to not expose it is to never trigger the webhook directly but still have that separate proxy server.

BTW this didn’t have to be the webhook, it could be a direct Add Row REST API call. Could be whatever call really as long as the token is there.

P.S. This calls for a feature request: tokens that are restricted to only trigger a webhook with a certain ID.

3 Likes
14

Your example is freakin’ brilliant Paul! Simple, effective, and quite fast. Love it.

Two comments -

  1. You and a few other Coda explorers were as responsible for this to come to life as me.
  2. Is this discovery so huge that to commercialize it would be a mistake?

I’m serious about #1 - it literally took hundreds of experimental attempts and many hundreds of hours to continue to understand the pathway.

#2 I haven’t thought about much, but when Neanderthals discovered fire, they shared the discovery. Is this one of those ideas that we should all celebrate and work to improve?

2 Likes
15

I think there is away to secure apps like this. I need to noodle on it for a while. I believe the answer is a persistent file system - maybe Coda can help.

1 Like
16

What do you mean by #2 — make the pack paid?

I could totally imagine charging some $1 or $2 / mo for it. Then, speaking of myself, I could probably re-create it, knowing the mechanism.

I would also see a thriving ecosystem of custom made widgets that would run on the itsy pack.

E.g. I would totally redo my laggy POS interface or inline calculator in HTML and return the result into my doc.

17

Yes. It’s tough to decide because (a) the cat’s out of the bag, and (b) would commercializing it be in the best interest of anyone, me included?

You absolutely could build this - it’s like 9 lines of code. A clever 9 lines, but still, incredibly simple. LOL I refer to it as the only Pack that is as small as Hello World! and possibly as big as the whole world.

Even so, there are many thousands of users who need this but cannot easily fabricate it, yet it is something that all Makers should have free and open access to. In case you didn’t connect the dots, this is why I asked over in Slack …

image
image1560×666 147 KB

1 Like
18

Yes, this is likely a far bigger opportunity for commerce and likely very beneficial for non-technical users. I have wondered how you would package Itsy + web components. Do you simply distribute Itsy “flavors” with bundled docs and web app code?

19

well done all who contributed to this journey

and yes, it is like fire, to be shared with everyone for the good of all (imho).

security:

i believe the answer is for Coda to bring this INSIDE the product, make it a native feature of CFL and thus enclose it in a safe and secure enclosure.

i hope the wise ones at Coda are listening and will do the right thing here.

respect
max

2 Likes
20

Guys this is amazing!

I’m starting to wrap my head around all the possible use cases this could unlock. The dynamic dashboards features alone has tons of potential for business application since it’s much flexible for customized reports. (Thinking about Google Data Studio visualizations here).

Also kudos for the cooperation between you all! It’s amazing to see how this all was compounding on top of each other’s discoveries and knowledge.

Thank you @Bill_French for building this platform. I’m sure it’ll be the foundation of amazing things as makers start adopting it.

PD: Thanks @Agile_Dynamics for calling my attention to it. Awesome find!

3 Likes