Re: AMA Custom Blocks Contest Edition #2 - Prototyping and Polishing with the Airtable Design Team

Michelle_Valent · ‎Jun 15, 2020

Are you looking for feedback on usability or design best practices for your Custom Block? As part of the ongoing Custom Blocks contest, we’re hosting a live Ask Me Anything (AMA) session in this thread on Wednesday (6/17) at 11am PT .

Jay Ransijn and Stephen Suen from our platform engineering team have designed and built countless blocks. They will be available to answer any design-related questions you have.

The top 3 upvoted questions (or solutions from the community!!) will win a $40 Amazon gift card. You can even start posting your questions now, and we’ll be answering questions live from 11am - 11:30am PT on Wednesday. See you there!

Stephen_Suen · ‎Jun 17, 2020

What do you find is the best way to store configuration info, or does it depend on the type of block?

You almost always want to store shared configuration in global config, since global config is scoped to a specific block installation. Writing config to a table might clutter the base with additional information that users don’t need to see most of the time, and runs the risk of accidental modification/deletion. It’s also important to consider the scenario where a base has multiple instances of the same block installed — in that situation, you’d have to create separate tables for each installation, which could quickly get out of hand. For user-specific configuration, you can also use local storage.

In terms of UI, it depends on the type of block you’re building. Generally speaking, the recommended pattern is to have a dedicated settings screen (accessed with the useSettingsButton hook) that can be visited whenever. For visualization blocks, consider displaying the settings in a sidebar so that users can tweak settings and see the changes in real-time without switching back and forth between two screens. For wizard blocks where the settings may not change too often, this settings screen might simply be the first screen rendered by the block.

kuovonne · ‎Jun 17, 2020

Could you expand a bit more on local storage? Is it unique to the specific user and block? Can it be accessed outside the block? Is it suitable for storing sensitive information such as API keys or passwords? Does it persist after the block is closed? Does it persist after Airtable is closed? Does it persist after the computer is restarted?

Jay_Ransijn · ‎Jun 17, 2020

Hey Kamille, thanks for your question. I will try to unpack your questions a bit:

Will developers have access to UI elements not used in blocks?

The UI kit we provide for the Blocks SDK is separate from our core product UI for several reasons. We build new components for the Blocks UI kit optimized for the Blocks SDK and developer experience. We prioritize new components based on the needs from the Blocks developer community, and our own needs as well.

For instance, if our custom block included a calendar or a date picker, will we have access to the same calendar used for Calendar Views and the same date picker used in date fields?

More specifically your question about the date picker, we have got some signal on the need for this component and it’s a component on our radar! For now I would recommend using something like http://react-day-picker.js.org/ (which our own core date picker is based on).

Will other UI decisions which are determined by CSS classes be available to the blocks UI elements?

How we deal with CSS and styling is different in our core product than in the Blocks SDK, so we will never be sharing or importing CSS from the core product. We do aim to add new component props or utilities to solve for common pain points!

For example, throughout Airtable’s interface, overflow text is hidden using the CSS class .truncate , could the Text/Heading block elements have a property to turn on or off the truncate class to match?

I will create a note for the team to look into truncating! Thanks for bringing this to our attention. In the mean time you could use a style prop on your component with the following properties:

style={{
   overflow: 'hidden',
   textOverflow: 'ellipsis',
   whiteSpace: 'nowrap',
}}

Janine_Co · ‎Jun 17, 2020

Hi Airtable Team, I’m following the tutorial for “Hello World” and seems to be getting an error after “block run.” However, I was able to successfully obtain the block url through terminal. Does anyone know how to resolve the error? Thank you in advance!

Kamille_Parks · ‎Jun 17, 2020

For that error, make sure you are only trying to run the custom block from the Base you originally set it up in, and on the same computer.

kuovonne · ‎Jun 17, 2020

What will happen to questions in this thread that aren’t answered before time runs out?

Matthew_Thomas · ‎Jun 17, 2020

I haven’t worked with local storage extensively, but I believe the answers would be yes, yes, and no.

An example use case I’m trying to think of is one where multiple users want to use the block, calling an external service with their own API keys (so as to keep requests and data manipulation tied to a specific user and not the “global” API key stored in a config). Local storage would solve this problem to make it per-individual, but being wiped on restart is less than ideal.

The cache might only be wiped manually though (clear browser data) instead of on computer restart, but I’m not sure. Definitely something I’ll be looking into!

Stephen_Suen · ‎Jun 17, 2020

Could you expand a bit more on local storage? Is it unique to the specific user and block? Can it be accessed outside the block? Is it suitable for storing sensitive information such as API keys or passwords? Does it persist after the block is closed? Does it persist after Airtable is closed? Does it persist after the computer is restarted?

You can read more information about the local storage API here: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage

In short, it’s unique to a specific browser for a specific block installation. It cannot be accessed outside the block. It is persisted between sessions unless the user explicitly clears their browser’s local storage. You could store sensitive information there, but it would be accessible by anyone who has physical access to that machine. Also note that anything in local storage won’t be shared between different users of the block (e.g. each user of the block would need to input their own API key).

Kamille_Parks · ‎Jun 17, 2020

Has airtable considered offering a way to color a Record using a custom logic that is separate from a View’s or Select Field’s coloring settings?

It would be nice to have a 4th, custom Record Color Mode (Airtable Blocks SDK) where we can just feed a record/list of records a hex value or a standard color.util value.

Stephen_Suen · ‎Jun 17, 2020

The cache might only be wiped manually though (clear browser data) instead of on computer restart.

This is correct, local storage is not wiped on restart.