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.
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.)
// 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.
This doesn’t pertain to the ongoing conversation, but is a question regarding the OP, @Bill.French…
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 …
Script fragments can exist in records/fields; a fragment is no different than a dynamic library
Script in records/fields can be executed with eval()
Return values from dynamically called script fragments can be persisted
Processes that use multiple script fragments can be strung together and even reordered, filtered, and updated dynamically
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
Yep - perfect use case for this feature looking for a problem to solve.
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.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!