AMA Custom Blocks Contest Edition #4 - Ask You Anything (AYA)

[Michelle_Valent]

We’re advancing into the last week of the custom blocks contest (Submission deadline: July 6). This will be our last AMA in this series - with a twist! We’re turning it around to you: Ask You Anything (AYA).

We’d be interested to hear from you about one rose, one bud, and one thorn of your custom blocks beta experience so far. To be more specific:

Rose: Something that delighted you about the platform
Bud: Something new that the custom blocks platform unlocked for you, whether it’s a new workflow or new value in Airtable
Thorn: What is your top feature request or challenge that you ran into?

The thread is open for the next week and the 3 most insightful posts will win a $40 Amazon giftcard. Feel free to keep it under a sentence each. A member of the Airtable platform engineering team will select the winner at the end of day on Thursday (7pm PT).

[Yuriy_Klyuch]

Rose + Bud:
Up until the contest I didn’t used airtable much, I had a look at it only briefly. Now I looked more closely and I can say that Blocks really do seem like a feature seriously improving Airtable potential usage. I’m looking at possibility to build custom CMS/dashboards for small companies/startups who doesn’t have budget for fully custom apps. So, realtime interactions/updates, full power of React, ready-made widgets - those are quite valuable features of Blocks SDK.

Thorns:
in a very few words. In no particular order. I’m sure most of those points already were discussed, so nothing fancy here, but anyway:

• need more tools to help development - ability to edit globalconfig inside “block debug console”. Should react dev tools work in dev block? (I wasn’t been able to use it)

• need more samples for “low level” - with watch/unwatch, useWatchable

• need life cycles of blocks - “install”, “uninstall”, “first-run”, “started”, “new version of block”

• would be good to have store of paid-once/subscription-based blocks where payments taken care of by airtable dev-team. So developer would be free from hassle of payment operations

• need many more widgets in UI. Or some easy way to use existing 3rd-party widget library. (I tried setup prime-react but failed due to being novice in this area)

• would be good to had tutorial for devs who come from Google Apps Script grounds (like me)

• how to publish/deploy block to only selected people (custom CMS for organization)?

• think about different system of permissions for blocks - so, “commenter” user could save some data in block settings

• about “unstable API” - not quite clear how to handle it. How often will it change? Will I, developer, know about changes before it happens or my block just suddenly will stop working?

[Kamille_Parks]

Kirill_Madorin:

Developer’s Slack or Discord to share ideas

@Openside’s BuiltOnAir community Slack has a dev topic:
https://app.slack.com/client/TER3S8LDV/CH1PQF59P

[openside]

If you’d like to join, you can do so here: https://builtonair.com/join

[Mixable]

Rose : Something that delighted you about the platform

• Documentation and code examples are wonderful. More example code the better, especially with the range of reference example Blocks.

Bud : Something new that the custom blocks platform unlocked for you

• It has allowed me to revisit some of our internal workflows to streamline it to just a single Airtable base versus jumping around between Google Sheets to Google Docs to Email. I’ve gotten a workflow that used to take 20 minutes of app jumping down to just a 5 second click > update > deliver.

Thorn: What is your top feature request or challenge that you ran into?

• I haven’t got to the publish step yet, but I’m almost to the mindset where I would love to be able to run a Block fullscreen and not have to rely on a view of the supporting tables that are the foundation of the experience. So a feature request here would be ability to just launch a Block directly, full screen.
• I see comments and feedback specific to isolating the behind-the-scenes configuration and settings so that end users can’t see then, and I definitely see the need of that coming up.

Overall, this hackathon and support on this forum has been a wonderful developer experience.

[kuovonne]

Rose

Custom blocks completes Airtable’s expansion from a no-code platform to a full-featured rapid application development platform. Airtable now has tools designed for non-coders, emerging coders, experienced coders, and everyone in between. Formulas, Scripting Block, Custom Blocks, and the Standard REST API provide a set of stepping stones for people to develop both useful tools and their coding skills.

The code-curious can comfortably dip their toes into the coding ocean by experimenting with formulas. If writing formulas feels empowering, they can move on to using and adapting scripts without having to setup a development environment. The next step is writing their own scripts. Once a new coder is comfortable writing scripts, building an app with Custom Blocks is the natural next step.

Bud

When I first picked Airtable as an online database tool, I did so in spite of the fact that Airtable was marketed as a no-code platform and there were very few ways to customize the front end. Now, Custom Blocks provides a method for creating a completely customized front end. While power users will always want to see the underlying data structures, a customized front end with customized business logic can make day-to-day operations much easier. It is even possible to write a custom block that provides all the interaction that low-level users of a base need.

Thorn

Issues relating to distribution of custom blocks and collaborator permissions remain a very big thorn. With custom blocks, there will be more users running code that they themselves did not author. That means that we need protections for the intellectual property of both the code users and the code authors.

Currently, only a collaborator with creator permissions can install a custom block. If a user wants to install a custom block that he did not write, the user must either give the developer full access to the entire base (and all of the intellectual property the base contains), or the developer must give the user access to his source code. Neither is ideal. While opensource code has its place, the ability to keep source code private when desired is also important.

[Ronen_Babayoff]

Rose: Love the fact it’s based on react, great clean api with nice generalizations (i.e. watchable, loadable), easy to setup and to get going, love the …ifExists functions - really simplifies code. Great open source examples, they really helped a lot.

Bud: As a consultant and ISV, really opens opportunities to start packaging my solutions and providing them at scale. In general, similar to shopify and other ecosystems, the blocks api is going to give a huge boost to Airtable’s ecosystem, and increase the amount of workflows and problem solved the platform is going to support, via 3rd party blocks in the ecosystem.

Thorn(s):

1. Always on server side code that’s part of the block - quite a few of my use cases require server side code - and right now it’s implemented using code external to airtable that uses the regular api (which also prevents me from reusing code written in blocks, since the apis are different). A solution where I don’t have to deal with server side devops and it’s just part of the block’s server side code can really simplify creating apps on top of airtable. As part of it, webhooks notifying of changes to the data model can really open up a lot of opportunities todo amazing stuff on top of the platform (yes, you can poll but it’s not the same - code is more complex and responses to data model events are not real-time). See shopify for a great complete webhooks implementation on their entire data model.

2. Use my own bundler and bundling config for blocks - i.e webpack, rollup or even browserify but with my own config. Right now not being able to do that:

2.1. Was probably the most time consuming thorn in my blocks development experience.

2.2. Increases my bundled block size significantly, and increases block loading time significantly.

2.3. Prevents me from splitting my code using async imports.

2.4. As the number of blocks I need to maintain increases and that share code - to date, I still haven’t figured out how to optimally share code between blocks and being able to improve my libraries as part of working on my blocks. Examples from the airtable team on how they do it internally would be highly appreciated.

All in all, really really excited about custom blocks and the opportunities it opens up not only for me but for all airtable aficionados :slightly_smiling_face: .

Best,
Ronen Babayoff
Superblocks.at

[Warp_Smith]

I will be brief.

Rose: I am impressed by the documentation [concise wording, animated gifs], the modular aspect of the UI, and the availability of open source blocks.

Bud: ANYTHING that makes programming easier is good!

Thorn: There should be an integrated CLI for node and python, as well as a mobile version of Airtable.

If all goes well, I might be a Block Head.

[Jeremy_Oglesby]

Warp_Smith:

I might be a Block Head.

I like it. I’m definitely a Blockhead.

[Emma_Yeap]

Hi everyone! I’m Emma on the Airtable platform engineering team and we are thrilled to see so many thoughtful responses. The three highlights for me were: @Jeremy_Oglesby , @Kamille_Parks , and @Yuriy_Klyuch 's responses! We’ll be following up with them via email after the holiday weekend with their gift card rewards. Good luck to all in the final stretch of the blocks contest.

[kuovonne]

Mixable:

I would love to be able to run a Block fullscreen

You can force a block into fullscreen mode. Check out the documentation on the Viewport and the ViewPortConstraint for details.