Help

Save the date! Join us on October 16 for our Product Ops launch event. Register here.

Re: BlockChaining - Is it Possible?

5402 0
cancel
Showing results for 
Search instead for 
Did you mean: 

Um, yeah - it is. But first, a little of the backstory.

As is often the case just when you’ve thought you’ve seen it all, a client asks -

Is it possible to chain blocks and run them sequentially - as one completes, the next one starts?

No, right?

But then she tossed in another requirement -

The computational results from the first block must be available to the next block and sometimes to all subsequent blocks.

Oy! Nothing like a mind-bender for a Monday morning.

This business requirement is daunting – indeed, impossible given the nature of Script Blocks. I’m sure the Airtable folks have pondered this, but as it stands, it’s off the table for now, right? Indeed, Script Blocks are simply not capable … until and unless … you factor in the amazing power of that which Airtable is known and most famous for - simple data/content management with an intimate relationship with integrated script.

Often, it is the alchemy of data and code that spark the most remote possibilities into a new reality.

Simple Workflow Example - a Happiness Survey

Imagine a three-step process asking basic questions about your day. It’s a survey per-se and I’ve embodied the essence of it into a simple table shown below. Each step has a question and a column for answers. Lastly, there’s a final step - Happiness Assessment - that computes your relative happiness based on your answers

The following screenshot shows this three-step process but also displays a very important field showing Block Script in a long text field.

As I mentioned, each step is a question, and each question is presented abstractly in the script using the value in the first column (i.e., Process Step). The final stage in the process is based upon the answers at each step in the survey process.

image

BlockChaining

To do this elegantly and well, chaining together different script blocks is ideal.

Each script in each process is loaded and executed sequentially. A single “runner” Block orchestrates the execution of each data-based block and it manages the in-memory scope of the results from start to finish.

image

The final step includes the block shown below which displays the resulting happiness assessment. Note the reference to aRecords - this is the variable that contains all of the answers gathered from each of the chained blocks.

image

And the outcome in the block runner reveals this display when all four steps have completed.

image

Summary

Block chaining is possible. In and of itself, this is an important realization. While my example is super simple and somewhat lame, imagine the incredible solutions that could be built by chaining block scripts together in easily-managed table data.

  • The execution order of block segments could be altered by simply dragging table rows.
  • Imagine using this to administer dynamic tests where specific (named) users must be tracked.
  • Learning systems could be provided through Block Chaining.
  • Searching block script for key elements and debugging is made simple by Airtable search.
  • Building complex expert systems are more possible because blending data is virtually unlimited.
  • Block Chaining is somewhat ideal for creating code reuse.
  • Building code in Long Text fields is terrible (just sayin’… build them in a real block and test, then deploy as data objects).

As I mentioned, it is also possible to manage, share, and aggregate computational results that occur across multiple block segments.

Tell me - is Block Chaining a thing?

43 Replies 43

Imagine you’re running multiple script fragments from a list of records and in that process you need to summarize the outcomes of each fragment’s choices (button 1, button 2, etc.). Now imagine you need a global variable that sustains those choices made as each fragment is executed. Lastly, imagine a requirement where the final script fragment being executed needs to know the choices made by all the other script fragments executed by the eval() method.

You need a global variable that can sustain the outcomes across all script evaluations and such that this variable is known and accessible inside each script fragment evaluation. That is the purpose of aRecords (i.e. answer records).

Feel free to find other ways to meet these requirements with a different design, but it’s likely this design is a good one.

Mke sense?

Thanks a lot @Bill.French,
I’ll read to you with all due attention after my work.

Yes, it could always happen if I experiment in order to learn, but be sure that I had no second thoughts of thinking that I would find a better design!
I consult you on this Community.airtable to learn the art, the technique of good design.
Thank you very much for bringing us your teaching since Script-Block exists.
It’s very kind of you!
(As I tried to express non-technical nuances in English, I hope I used the right words.)

oLπ

Hello, @Bill.French,
I come back to the subject again, not to appear to be the smartest, but because my approach is experimental.

var thisCode = "(async() => {" + ctxScript + "; return(stepOutcome);})(aRecords)";

and

var outcome = await eval(thisCode);

where

thisCode could be (for exemple from STEP1):

await eval("(async() => {let scriptQuestion = “Are you happy?”; let stepOutcome = await input.buttonsAsync(scriptQuestion, [‘Yes’, ‘No’, ‘Back’]);; return(stepOutcome);})(aRecords)");

are focused in what follows:

Assuming that there might be a hidden bias in my experience, in the current state of the results I get:

(1) It seems well that aRecords in

})(aRecords)

at the end of EVAL is never modified anyway by this EVAL code line ;

(2) It seems well that })(anythingElse) is running and giving back the same script results if I first add

let anythingElse

at begin of the script
AND it appears in this case that console.log(anythingElse) is giving back undefined at each script STEP ;

(3) If I’m replacing

})(aRecords)

by })() script is running and giving back the same script results ;

(4) If I’m replacing end-of-script-line

`})(aRecords)

by })`

in

var thisCode = "(async() => {" + ctxScript + "; return(stepOutcome);})(aRecords)";

that becomes then:

var thisCode = "(async() => {" + ctxScript + "; return(stepOutcome);})";

script raised to error then stopped this way:

ERROR
R: Cannot deserialize 15
at main on line 

(5) It seemed well that only script line

// update the array with the outcome
            aRecords[i]["outcome"] = outcome;

is updating aRecords step by step as you wished.

Be sure that my approach is purely well-intended: I’m not trying to have the last word, nor to look like I’m the smartest.
I’m just trying to understand how this EVAL really works in relation to (aRecords) end-of-script-line, aRecords which I also inspected everything (in my opinion) that’s readable from throughout the script to follow its evolution before coming back here.

Best,

olπ

No one truly understands how eval() really works. :winking_face: Perhaps this will help.

This is the magic of eval(); it makes it possible to construct code in a very late binding process purely as a string and then execute that code AFTER the string has been fully constructed.

This doesn’t pertain to the ongoing conversation, but is a question regarding the OP, @Bill.French

Could I use this strategy to save the text of a minified JavaScript library (say Moment.js) in a table, to be implemented in any Script block in that base simply by using eval() on the value of the field holding the minified library? Could I use that pattern to basically “import“ libraries I enjoy using into my Scripts?

I believe this is possible. Never checked into it, but I have often wondered if this approach wasn’t a pathway to extending the flight ceiling of Script Blocks by dynamically introducing code into a solution for which the code occupies no space (i.e., script memory per-se) in the lately-bound process. Note - you may have experienced a script block is unable to load more than about 2,000 lines of script and minifying seems to help.

My example makes it obvious that …

  1. Script fragments can exist in records/fields; a fragment is no different than a dynamic library
  2. Script in records/fields can be executed with eval()
  3. Return values from dynamically called script fragments can be persisted
  4. Processes that use multiple script fragments can be strung together and even reordered, filtered, and updated dynamically

I’ll give it a shot then, when I’m not rolling the internet on my phone :winking_face:

It totally works!

CleanShot 2020-06-28 at 10.27.58@2x

Pasting the entire minified moment.js library into a script block is rejected for making the script too long. However, a long text field can hold the entire minified library:

CleanShot 2020-06-28 at 10.30.17@2x

And that library can be called into the Script block with eval(), as if you were importing it with import.

As you see from my screenshot above, you will clearly not have intellisense while editing, and any calls to the eval'd library will be flagged as errors, but once the library is eval'd its models can be used in the script.

Thank you for discovering this strategy, @Bill.French – this is going to make the Script block so much more flexible for junior scripters who prefer to lean on other people’s work :winking_face:

You’re welcome!

Yep - perfect use case for this feature looking for a problem to solve. :winking_face:

This will probably not be a big issue as libraries – for the most part – are well-tested and few will have the desire to modify them. But, this doesn’t stop any of us from using this approach for creating and managing our own reusable libraries in this way.

Sidebar - if Airtable is able to create a JSON editor for long text fields, it can certainly create and install a code editor for javascript because - wait for it - json is javascript. :winking_face:

Sidebar.2 - BTW, this happened when I envisioned a way to manage code as if it were data and what better example for doing so with the advantageous relationship that Script Blocks share with data tables?

Sidebar.3 - feel free to write the Show & Tell with a title that’s more aligned with what you are showing here; “BlockChaining” doesn’t really express what you’re accomplishing with libraries.

Sidebar.4 - no developer (me included) should ever be given credit for using eval() in creative or potentially dangerous ways. LOL

Many thanks @Bill.French !
It seems already to me to be the right link but I would ingest and process it during free hours !

Bill had already suggested this in this thread or elsewhere and there you tried, and succeeded! Bravo and thank you very much!
It’s time for me to go on vacation (soon) to try to give something to the Community in return, but for the moment, in javascript, I’m learning to play the Who and the Rolling Stones as perfectly as possible : I’m not composing anything original yet. But it will come !
oLπ