This is remarkable. And brilliant.
Thank you.
My mind is a little blown. Slightly confused. And possibly a little zapped.
I have so many questions. But first to play a little.
In a good way I trust. 
I remember when the first web app “runner” was unveiled in the mid-90’s; it was a bit mind-blowing to think that you could send a chunk of HTML and/or Javascript to a server and it would execute it. Today, this connotation is a bit more advanced, but the general idea is still the same.
I’m no expert in these architectural matters, but our Coda account instances are likely running in a container, so this is simply an extension of that basic idea; that code can run inside a container and I believe Coda’s Embed() framework is well-enough sandboxed to make this a sustainable concept.
Itsy() is one of those Packs that should be openly available to all Makers to do as they please to enhance and explore new possibilities. The source code is amazingly simple; just another validation that the Codans really understand agile architectures. Knock yourselves out - create something worth reading about.
6 Likes
Great! A lot of possibilities open up with Itsy.
I’m trying to embed this code, but it doesn’t let me:
<div class="tradingview-widget-container"> <div id="technical-analysis-chart-demo"></div><div class="tradingview-widget-copyright"><a href="https://in.tradingview.com/symbols/AAPL/" rel="noopener" target="_blank"><span class="blue-text">AAPL Chart</span></a> by TradingView</div><script type="text/javascript" src="https://s3.tradingview.com/tv.js"></script> <script type="text/javascript">new TradingView.widget({"container_id": "technical-analysis-chart-demo", "width": "100%", "height": "100%", "autosize": true, "symbol": "AAPL", "interval": "D", "timezone": "exchange", "theme": "light", "style": "1", "toolbar_bg": "#f1f3f6", "withdateranges": true, "hide_side_toolbar": false, "allow_symbol_change": true, "save_image": false, "studies": [ "ROC@tv-basicstudies", "StochasticRSI@tv-basicstudies", "MASimple@tv-basicstudies"], "show_popup_button": true, "popup_width": "1000", "popup_height": "650", "locale": "in"}); </script></div>
Is it possible for such a widget to be emdedded in Coda using Itsy?
I believe so. This is what it looks like when I use ItsyPlus() to render it.
This is my formula:
itsyPlus('<div class="tradingview-widget-container"> <div id="technical-analysis-chart-demo"></div><div class="tradingview-widget-copyright"><a href="https://in.tradingview.com/symbols/AAPL/" rel="noopener" target="_blank"><span class="blue-text">AAPL Chart</span></a> by TradingView</div><script type="text/javascript" src="https://s3.tradingview.com/tv.js"></script> <script type="text/javascript">new TradingView.widget({"container_id": "technical-analysis-chart-demo", "width": "100%", "height": "100%", "autosize": true, "symbol": "AAPL", "interval": "D", "timezone": "exchange", "theme": "light", "style": "1", "toolbar_bg": "#f1f3f6", "withdateranges": true, "hide_side_toolbar": false, "allow_symbol_change": true, "save_image": false, "studies": [ "ROC@tv-basicstudies", "StochasticRSI@tv-basicstudies", "MASimple@tv-basicstudies"], "show_popup_button": true, "popup_width": "1000", "popup_height": "650", "locale": "in"}); </script></div>')
Templating this little app is also possible, but this requires the use of Itsy() in table cells with Embed() to force the app size within the cell.
Embed(itsy(thisRow.[Chart Template], Minute(Now())), 640, 380, true)
4 Likes
Hey, @Bill_French, @Xyzor_Max, and @Paul_Danyliuk, about security…
Now that Coda has “Personal mode” for control values, I think that concern is gone 
Also, couldn’t it be solved before by adding login and a JWT cookie encrypted using some Coda user private property that gets passed to the web app? (I just thought of it, not sure if there’s a roadblock somewhere)
Personal values are still stored in a doc they only “hide” from the UI but not from the doc data. Think of those simply as a table on a hidden page.
There’s nothing preventing you from just grabbing another user’s data (e.g. their cookie) and using it as yours. There is really nothing that you could pass to an embed that another user couldn’t. There’s no in-memory controls to e.g. type in the password. You can, of course, have security within the web app itself (i.e. a separate sign in flow with a backend doing authentication)
The concern may be gone, but Coda has sealed off the ability of a Pack to use its local storage from hosting anything within or for the benefit of the document.
That’s very disappointing! I was under the impression that “personal” meant “accesible by my user only”! That personal option is great opportunity for data leaks 
Ohhh I see the confusion. When I mentioned cookies, I was referring to cookies created by the web app. But I realize now that makes no sense! lol I was pretty tired when I wrote that. That’s why it was confusing to you guess. The app inside the iframe has full control over the cookies and if the session cookie exists, you are logged in. No need to get Coda involved.
That’s VERY frustrating! And it also means that any new trick will also receive a counter measure and stop working.
Looks like I met, fell in love, and want to break up in less than a week!
I just sent a suggestion to at least remove the warning for “approved email domains”. That would be something to me
Here it is:
Correct - unless it is created completely external to Coda while in concert with existing Pack and/or embed security contexts.
I have been researching this for much of 2023, and there is a glimmer of hope given some of the new technologies I’ve been studying like Astro and Replit.
There is hope…
I have Itsy Two running in a prototype now.
More on this in the coming weeks.
2 Likes
Oh… was going to send this yesterday but forgot. Looks like we had similar ideas with different design choices hahaha
I’ll leave this endeavor to you from now on and wait for Itsy 2. But don’t hesitate to send me DM if you need or want any help though!
Indeed. But, as Makers, it’s often the case that conclusions are alike when we focus on the user requirements.
As a Coda Maker, I am often presented with a cul-de-sac, a limitation that prevents me from reaching across the bench for that one tool I’ve learned can overcome challenges - open web standards.
Typically, this is HTML, but often, it’s a mix - CSS, JavaScript, images, etc. The point is, Coda is a web-based platform, so we are naturally inclined to expect web stuff should be a no-brainer. For a variety of reasons, it’s not.
Your HTML approach is precisely how simple it should be to add custom code to a Coda document. To do that, of course, requires a rendering server whether it’s a simple block like you shared, or a complete app that uses script and other web standards. We can’t rule out integrations with other platforms either.
Using your HTML block as another test, Itsy II (the second story), seems to work as you hoped, albeit with a slight code wrapper augmentation.
And to demonstrate some additional agility, the code I created for this component, of course, can be used in Coda AI to determine if it might be improved. It’s just a column with a code block. It simplified it a bit…
But there’s more - what if I wanted the rendered component to be used in a document canvas?
I have some wrapping going on too, I just moved it to the pack. That’s what the “mode” is for, to pick which wrapper you want. So if you use a formula and have a column with only the html text, you can choose “wrap” instead of “as is”. There are better options I could use there, but I started only focused on javascript.
I fully expected coda to allow me to create a block (in any way I wanted) in the pack and return it for the UI to render.
Yeahhh that’s very nice!
I’m VERY curious to see how you are rendering this. I would guess embed with a url to an express-like “server” with an echo-like behavior.
I’ve been wandering if it was possible to trigger a pack to run when accessing a coda URL, or if I could have a URL to a specific part of the current document that is generated by a pack. Maybe you went that way…
Well, my DM is open if you want to prevent my premature death by anxiety hahahahaha
Yep. The only way to do it well.
This is in a long line of complaints I’ve had; Packs should have endpoints for hosting data. If I want to make a code document serve up parts of the content (or data) to other systems, you have to build it all. The new stuff I’m working on may support that in a relatively simplistic solution - still a lot of work on that front.
I hope to share something useful tomorrow if all goes well. More likely Tuesday or Wednesday.
You still have that ugly warning on the embed then? Or did you find a way around that?
I would suggest you don’t add that! Coda may bring the entire pack down because of it. They do not let packs communicate with the REST API because they explicitly do not want packs to be able to send document data out.
Cool! But what you’ve shared already painted a good picture. Unless you are not triggering the embed warning. Theeen I’m curious again
All embeds need validation by the user; no way to subvert that, and this is good. That ugly warning may come in handy and without it, hackers could quietly do some stuff you might not expect. But once “allowed”, the components continue to work.
These embed components all run just fine as soon as they are “allowed” to.
These components were all built in Coda itself; a workbench that allows us (at my company) to build widgets that address UX and UI stuff that is best handled by open web standards. Plus, we have a number of web components that we use with our highway analytics services, so we’ve been doing this for almost a year.
This is the workbench.
Who told you that? And who’s REST API are you referring to?
Packs have been sending data to endpoints since 2021. How would you create and dispatch an email if you couldn’t send data out via a Pack? How could you sync a table with another SaaS system with such a restriction?
While Coda is not keen on providing an endpoint for data serving and consumption, you are free to position your data elsewhere in any platform of your choosing and establish end points for access. It’s our data and we’re free to do whatever we want with it.
1 Like
Yeah, this would be nice, but there’s a show stopper in your expectations. You are ostensibly expecting Coda to host your code right along side their code. And that’s the rub. I fully understand why they don’t allow this.
Not at all! Have you seen how Figma does it? Just look at widgets in Figjam or even Figma
Yes. Very familiar with that architecture. It’s very different from the approach I’m using because the embeds are completely unrestricted. Figma’s plugins are sandboxed and sanitized which means there are many limitations to what you can build. However, one advantage is they aren’t afraid to host the plugins for you. It’s a reasonable tradeoff and one that I recommended Coda consider even before Pack Studio was launched.
If you had said…
I fully expected coda to allow me to create a block (that was sanitized and restricted) in the pack and return it for the UI to render.
I would give that two enthusiastic thumbs up.
I’m also very familiar with this thread and I think you are misinterpreting it.
This is a conversation about the idea that any given Pack should be able to connect to its own API as a default domain in addition to another external domain. It seems reasonable that a Pack should be able to connect to the Coda API without a special declaration.
Coda’s reluctance to offer this dispensation by default does not mean …
First and foremost, Packs connect fine to Coda’s API. I use them a lot. Ergo, they DO let Packs communicate with the Coda API. What they don’t want to make easy is for a pack that conjoins the Coda API with a third party external API and direct access to a document. I can certainly understand why some Makers want to do this, but there are some security complexities that are also understandable. If your assertion were true, they would be uneasy about ANY use of the Coda API on a proxy server where other domains are acting to conjoin data. Coda is fine with this - they aren’t fine with it happening on the same servers where the core platform is running. The reasons are not so obvious, but I believe them when they say “there are issues with that”.
1 Like