Skip to main content

Slowly piecing together a Regex script in the Scripting App, but I’m stuck with table.updateRecordAsync not reading the field that’s active in the loop. If I hard-code the field name in with quotes it then works as I hoped, but if I use the field.name from the loop, it won’t parse.


So the below works (but isn’t very useful as I’m trying to cycle through fields rather than hardcode a string);


await table.updateRecordAsync(record, {"🔍Test_1": String("test1")});


“test1” will successfully write to each record for field “ 🔍 Test_1”. But when I swap out the hardcoded Field name string with field.name it unfortunately fails to parse.


await table.updateRecordAsync(record, {field.name: String("test2")});


Running Console log on field.name, it comes up as expected - so I’m not too sure what I’m doing wrong and will appreciate some help. Full code below - and keep in mind that I’m still learning Javascript - I’m finding it tricky to break my old coding method and habits to learn the new techniques that Javascript keeps throwing me - but practice makes perfect… just wish I wasn’t being stumped on something that’s probably overly simple… but I can’t get it cracked. >_<


let table = base.getTable("Log Files");



// query for all the records in a table



let queryResult = await table.selectRecordsAsync({



    sorts: R

       {field: "Log File Name"},

    ]



});



//Cycles through each record



for (let record of queryResult.records) {



    output.markdown(`**${record.getCellValueAsString("Log File Name")}** - ${record.id}`);



    //Cycles through each field and looks for 🔍 prefix

    for (let field of table.fields) { 

        if (field.name.includes("🔍")) {



            output.text(`${record.getCellValueAsString(field)}`)



            console.log(field.name)

            console.log(field)           



            await table.updateRecordAsync(record, {"🔍Test_1": String("test1")});



            await table.updateRecordAsync(record, {field.name: String("test2")}); //this line won't execute?



            output.text(`${record.getCellValueAsString(field)}`)



        }



    }



}

Further to this, I’m wanting my Script to handle dynamic changing field names, and only process any field with a 🔍 prefix, but I think the fact that table.selectRecordsAsync is insisting I type all field names of interest in, I’m worried I might be on borrowed time before it’s depreciated? How can I code await table.selectRecordsAsync to happily process all fields within my table without writing their names out?


The below will clear the strike through, but defeats the purpose/goals of having my code loop through to find the fields of interest.


let queryResult = await table.selectRecordsAsync({

    fields : ="Log File Name", "Log Content","🔍Test_1", "🔍Test_a"],

    sorts: "

       {field: "Log File Name"}

    ]

});

Put square brackets around your variable when using it as an object key. This is a JavaScript thing, not an Airtable specific thing.


await table.updateRecordAsync(record, {[field.name]: String("test2")});

You will also want to eventually refactor your script so that you are not updating one field at a time records inside the nested for loops. Your current method is very slow. Instead build an array of updates that you can then submit in batches after the nested for loops to reduce the number of asnyc requests and improve performance.


—-



This line also probably isn’t showing what you want. You need to do a fresh read to get the newly updated field value.

Put square brackets around your variable when using it as an object key. This is a JavaScript thing, not an Airtable specific thing.


await table.updateRecordAsync(record, {[field.name]: String("test2")});

You will also want to eventually refactor your script so that you are not updating one field at a time records inside the nested for loops. Your current method is very slow. Instead build an array of updates that you can then submit in batches after the nested for loops to reduce the number of asnyc requests and improve performance.


—-



This line also probably isn’t showing what you want. You need to do a fresh read to get the newly updated field value.


Yup, I noticed it needed another refresh before reading that field, but was so {sfrustrated.amount] : “very”} with forgetting those square brackets. :grinning_face_with_sweat: Thanks so much for the help @kuovonne


Refactoring is also a big part of my learning - but as you can see, I’m at the stage of learning code by getting it to work, and then in the coming weeks will re-write it using modern techniques to solve inefficiencies.


Thankfully, this is just a side project to help me scan through logs, so speed isn’t critical - just the result must be accurate.


What are yours and anyone elses thoughts on the depreciation of “table.selectRecordsAsync”? How would I approach a dynamic scan of my table fields if I’m not knowing their names in advance, or rather, not wanting to type them all out (which breaks the minute there’s a field name change).

Yup, I noticed it needed another refresh before reading that field, but was so {[frustrated.amount] : “very”} with forgetting those square brackets. :grinning_face_with_sweat: Thanks so much for the help @kuovonne


Refactoring is also a big part of my learning - but as you can see, I’m at the stage of learning code by getting it to work, and then in the coming weeks will re-write it using modern techniques to solve inefficiencies.


Thankfully, this is just a side project to help me scan through logs, so speed isn’t critical - just the result must be accurate.


What are yours and anyone elses thoughts on the depreciation of “table.selectRecordsAsync”? How would I approach a dynamic scan of my table fields if I’m not knowing their names in advance, or rather, not wanting to type them all out (which breaks the minute there’s a field name change).



selectRecordsAsync by itself is not being depreciated. The use without specifying a list of fields is being depreciated. Thus it will still exist, but you will need to say what fields you want.



You can get the list of fields from the table object. See the documentation for details.


selectRecordsAsync by itself is not being depreciated. The use without specifying a list of fields is being depreciated. Thus it will still exist, but you will need to say what fields you want.



You can get the list of fields from the table object. See the documentation for details.



These growing pains will save you a lot of trouble in the long run. Not sure how long it’s been since you pushed yourself in JS land but the last half a decade have been amazing, feature-wise, so getting up to speed should be worth your trouble.


On a somewhat related note, try to avoid using let declarations out of habit because that’s where a lot of typing issues tend to emerge to take over the world and destroy everything you ever held dear. Unless you’re explicitly looking to mutate a value at a later point, always use const because it at least help guard against the most banal typing mismatches. And you can still mutate the properties of your ‘constants’ as much as you want unless you’re using something like Object.freeze. It’s just the reference itself that the const keyword is safekeeping at runtime.


Regarding your question about the deprecated-to-be behavior of selectRecordsAsync, I wrote about this in the past already but basically, you can mimic the current functionality with just a few extra words if you go with the functional approach:


const table = base.tablec0];

const fields = table.fields;



await table.selectRecordsAsync({fields})

So, it’s just the field declaration that you need to be on the safe side.


These growing pains will save you a lot of trouble in the long run. Not sure how long it’s been since you pushed yourself in JS land but the last half a decade have been amazing, feature-wise, so getting up to speed should be worth your trouble.


On a somewhat related note, try to avoid using let declarations out of habit because that’s where a lot of typing issues tend to emerge to take over the world and destroy everything you ever held dear. Unless you’re explicitly looking to mutate a value at a later point, always use const because it at least help guard against the most banal typing mismatches. And you can still mutate the properties of your ‘constants’ as much as you want unless you’re using something like Object.freeze. It’s just the reference itself that the const keyword is safekeeping at runtime.


Regarding your question about the deprecated-to-be behavior of selectRecordsAsync, I wrote about this in the past already but basically, you can mimic the current functionality with just a few extra words if you go with the functional approach:


const table = base.tablet0];

const fields = table.fields;



await table.selectRecordsAsync({fields})

So, it’s just the field declaration that you need to be on the safe side.


Thank you for these tips and advice @Dominik_Bosnjak - I really do appreciate it. I have a couple of recommended JS Books that I’m working through as time allows, and they help a lot - but advice from yourself and others such as @kuovonne is absolutely priceless and I can’t thank you both enough.

Reply


Terms & Conditions