You need to install a Google Apps Script, all instructions in there. Once set up, you can reuse the tables in multiple documents.
The doc builds upon the great work of @Paul_Danyliuk, @Filmos and @Joe_Innes, using a lot of hidden experimental formulas and hacks. So it may break at any moment. That’s why the Data is isolated from the Engine. In any case, use it at your own risk.
Initially I started with an Integromat webhook but reached a dead end since for some reason in order to update a table you need to manually select the table. Zapier suffers from the same restrictions.
I wanted something portable that could be used in multiple documents. So the solution was to use the API, and GAS was the path of least resistance. It has a Coda API library, and SSO means is one less service to manage.
Here I was doing a round trip with the Coda API to get the href then breaking that up to get the row, doc, table, and column ids automatically. Thanks for sharing those formulas!
When will Coda provide this undeniably beneficial ability as an integrated feature that does not spawn new web tabs so that we can create seamless (and sanctioned) integrations between documents and web services?
We are exploring ways of allowing users to create their own Packs, but for now our team is still refining how Coda integrates with 3rd-party services. We’ve received so many Pack requests over the last few months and trying to prioritize the ones that will benefit the community the most!
Yep, success is often a big bag of worms. This is why Coda should consider the idea of allowing the community to build the packs for you. Instead of trying to decide what to build next, make it possible for the wisdom of the community to build what they need and allow market forces to decide what packs are best and what should thrive.
Afterthought: Imagine you kept your API a secret and tried to build every imaginable integration for the community. Silly thinking, right? Packs should be treated no different - they represent yet another pathway to extensibility - and the pathways that customers are likely to follow are near-infinite.
I can assure you, it’s not as difficult as you might think. There are many samples and most of the time all you have to do is copy and paste. You should give it a try.
APIs need different types of authorization to get access. Pack making is a robust solution not a hack. It’s something that can’t be done using coda programming language.
I get that. The term “hack”, BTW is a compliment in many circles.
But I also understand that there are about 3200 different ways to complete “tasks”. The variants are massive and while it is possible to create a user-chummy way of addressing all 3200 approaches, the product itself would be onerous, cumbersome, and it would have north of 10,000 features. To put this into perspective, as of 2012, Microsoft Word had 9,832 features. It was noticably not better than when it had 5,000 features. I suspect it’s well North of 10,000 features now, but very few of them are actually known, let alone used.
Packs make it possible to meet narrow groups of users who need specific requirements and all without burdening other users with added costs, added complexities, added latency and performance issues, and a very long list of challenges when testing for regression issues.
Coda can remain the same; the platform it was designed to be while making it possible to meet every variant requirement imaginable. Word cannot, but it can do that one thing that 1/10th of one percent of its user base wants as long as you can compel Microsoft to add that feature.
I think the term “hack” used in a negative context should be reserved to things like the Goldbergian shit-shows I’ve seen in Microsoft Word with Visual Basic.
I never considered “hack” to be a negative term and took no offense.
What I don’t like, is having to make my own “hacks” to effectively use software I pay for… Maybe that’s why it came across that way.
I understand your point and it’s certainly valid. In this case though, I don’t think adding a “pull JSON from link” column as an option would make Coda any more complicated for the average user, just like the existence of the ParseJSON() formula does not affect those who don’t use it. It’s just there if someone who needs it searches for it, and stays out of the way for everyone else.
