Skip to main content

Guidance on "top-level" `return` in scripting blocks

  • April 6, 2020
  • 7 replies
  • 95 views
M
Forum|alt.badge.img+4

Source code for scripting blocks seems to be interpreted as function code. For example, the following input executes successfully (writing the string "first" to the output container):

output.text('first');
return;
output.text('second');

Using return at the apparent top-level of a script can be useful for control flow in shorter scripts since it allows developers to exit early without throwing an error or wrapping their code in an immediately-invoked function expression.

On the other hand, the behavior is undocumented, and the scripting block’s editor flags it as a syntax error (“A ‘return’ statement can only be used within a function body.”). That makes it unclear whether developers should rely on it. It would be great if the developer documentation for the Scripting Block said something about whether authors can rely on this (and if so, the editor updated accordingly).

7 replies

kuovonne
Forum|alt.badge.img+29
  • kuovonne
  • Brainy
  • 6009 replies
  • April 7, 2020

If you are using this technique for debugging purposes, you can use the debugger statement & browser dev-tools described in this thread.

If you are talking about using this technique in production code, that is totally different matter. Although the scripting block editor does incorrectly flag valid code, it sounds like this is a case of the editor correctly flagging erroneous code that happens to run.

S
  • somehats
  • Participating Frequently
  • 37 replies
  • April 7, 2020

Hi Mike, you’re right that at the moment, scripts get executed as functions so technically you can use return to stop a script early. This might not always be the case though - we’re actively developing the scripting block, and might make changes to the runtime environment in the future. As a rule of thumb, if the in-block editor says that something isn’t supported, you should treat it that way – even if it happens to work right now.

(That said, we’re pretty serious on backwards-compatibility. We wouldn’t change something like this without a super clear and very proactively communicated migration path and plenty of notice :grinning_face_with_sweat: )

kuovonne
Forum|alt.badge.img+29
  • kuovonne
  • Brainy
  • 6009 replies
  • April 7, 2020

@somehats Thanks for developing scripting block! I enjoyed the medium article about developing it. I love how you are able to push out changes and improvements to scripting block (and the rest of Airtable) so quickly.

M
Forum|alt.badge.img+4
  • Mike_Pennisi
  • Author
  • Inspiring
  • 60 replies
  • April 7, 2020

Hi Mike, you’re right that at the moment, scripts get executed as functions so technically you can use return to stop a script early. This might not always be the case though - we’re actively developing the scripting block, and might make changes to the runtime environment in the future. As a rule of thumb, if the in-block editor says that something isn’t supported, you should treat it that way – even if it happens to work right now.

(That said, we’re pretty serious on backwards-compatibility. We wouldn’t change something like this without a super clear and very proactively communicated migration path and plenty of notice :grinning_face_with_sweat: )


Thanks, @somehats. Another (maybe more compelling) way the function wrapping is observable is through the Scripting Block’s support of “top level” await:

output.text(await Promise.resolve(4));

This also works, but unlike return, the editor does not report a syntax error.

However, the editor also accepts the following:

import foo from 'bar';

That code is syntactically invalid, and the script fails to run. The editor may be interpreting the input as module code.

kuovonne
Forum|alt.badge.img+29
  • kuovonne
  • Brainy
  • 6009 replies
  • April 12, 2020

Hi Mike, you’re right that at the moment, scripts get executed as functions so technically you can use return to stop a script early. This might not always be the case though - we’re actively developing the scripting block, and might make changes to the runtime environment in the future. As a rule of thumb, if the in-block editor says that something isn’t supported, you should treat it that way – even if it happens to work right now.

(That said, we’re pretty serious on backwards-compatibility. We wouldn’t change something like this without a super clear and very proactively communicated migration path and plenty of notice :grinning_face_with_sweat: )


The problem I have with this is that the editor flags all sorts of things with wavy red underlines, even features that are clearly supported and do work. I can dig into the error to get more information, but the prevalence of false wavy red underlines means that I rarely investigate the wavy red underlines unless the code doesn’t work.

Here is a very typical scenario:

I am creating a script that I want to use in multiple other bases, not just the base that I happen to be running the script in. As such, I write the script to allow for table and field configurations that do not exist in my base. For example, I might write a reference to a field type that does not exist in my current table, but will in other bases. The editor will claim that my if statement will always be false because that field type does not exist in my base.

D
Forum|alt.badge.img+8
  • DNA_PC
  • Participating Frequently
  • 11 replies
  • October 27, 2022

The problem I have with this is that the editor flags all sorts of things with wavy red underlines, even features that are clearly supported and do work. I can dig into the error to get more information, but the prevalence of false wavy red underlines means that I rarely investigate the wavy red underlines unless the code doesn’t work.

Here is a very typical scenario:

I am creating a script that I want to use in multiple other bases, not just the base that I happen to be running the script in. As such, I write the script to allow for table and field configurations that do not exist in my base. For example, I might write a reference to a field type that does not exist in my current table, but will in other bases. The editor will claim that my if statement will always be false because that field type does not exist in my base.


Having a way to stop the script without throwing would be useful.

Use case: Click on a button that requires to select a record, if no item is selected I want to exit gracefully.
Wanted to use “return”, but can’t. I’ll workaround by using “if” but that’s not as elegant (lots of indented code that could have not been.

I don’t want red errors in any script, it can only lead to confusion.

kuovonne
Forum|alt.badge.img+29
  • kuovonne
  • Brainy
  • 6009 replies
  • October 27, 2022

Having a way to stop the script without throwing would be useful.

Use case: Click on a button that requires to select a record, if no item is selected I want to exit gracefully.
Wanted to use “return”, but can’t. I’ll workaround by using “if” but that’s not as elegant (lots of indented code that could have not been.

I don’t want red errors in any script, it can only lead to confusion.


Welcome to the Airtable community!

Look into putting the majority of your code into a “main” function and use guard clauses.


Terms & ConditionsAccessibility statement