Scripting Extension / Automation - Retrieve Fields from View

Not many, I’m afraid. I’ve tried to optimize the process of writing new scripts by creating a helper script that collects table, field, and view IDs on a specific table and builds some boilerplate code that I can insert into any new script. I have to weed out the fields that I don’t need, but even when the table has over a hundred fields this only takes a few seconds. It’s still easier than manually entering the fields that I need, and I also get a form of autocomplete based on how I designed the code, so using the setup is very efficient. I’m thinking about adding some more customization features and releasing it as a custom extension if that would be helpful.

Custom extensions have access to the fields that are in a view.

Are you creating brand new records or duplicating records? If you are creating brand new records, you need to type out each of the fields anyway in order to populate them with values.

If you are duplicating records, things are a little different. I rarely have to duplicate only the field values in a specific view and not others field values. When I do, I use the view as source of manual information, the same as a typed list in an email. I look for trends in the field list. Do I want to start with all fields in the table, and then exclude certain fields? Or do I want to start with a partial list, and then add additional fields based on field type or a naming convention? My most common scenario for building a list of field values to duplicate is to start with all editable fields, excluding linked record fields, and then manually add in the handful of linked record fields that need to be duplicated.

If creating a view with the fields to duplicate would be primarily a communication tool (versus leveraging a pre-existing view), I sometimes use a different method of communication. I use my “Field List” app to generate a table of fields. I do some pre-processing to make the list of fields prettier for the client. Then I add fields that the client can use to annotate the list–typically a single select saying if they want a field included or not and a long text field for any additional explanation. After the client fills out the table, I filter/sort/group the table, then can copy/paste field names.

Thanks @Justin_Barrett and @kuovonne

I’m thinking about how to construct and export JSON objects for each record in certain views, to then be used within another application. Within my Framework, Airtable acts as the place where designers ideas are created, designed, managed and saved - and then, I’m looking at methods of exporting that data as JSON for use in the external app.

Within the Table containing the records for export, there’s a dozen or so views, each with unique hidden fields. Each View has fields shown that are completely unrelated and unnecessary to other views - so I was hoping I could just point my script to an Airtable Views object and loop through the visible fields to construct my JSON objects of each record within that view… but as I can’t simply look up what fields are visible in what views, that makes this project enviable - with the exception that I basically reconstruct each view via hard coding in script. :frowning:

So with the above said, my thought process is changing that, I need to output all my fields but then perhaps filter out the null-ish fields to create my final objects - which means I just have to code up the all my field names once.

Appreciate any further advice or tips on this.

EDIT:
Looking into the Field object;

{id: "fldQ1M7zUyZBntPXU", name: "Class Map", description: "", type: "multipleRecordLinks", options: Object…}
id: "fldQ1M7zUyZBntPXU"
name: "Class Map"
description: ""
type: "multipleRecordLinks"
options: Object
isComputed: false

Hmm, perhaps I could simply tag the consumed views within the description - and then filter/map via checking the description first. :thinking: … erk, it’s still extra work, and not exactly what the description is there to be used for. :frowning:

What I’m really wanting/expecting in here was a “View” key with an array of views the field is visible in. :frowning:

{id: "fldQ1M7zUyZBntPXU", name: "Class Map", description: "", type: "multipleRecordLinks", options: Object…}
id: "fldQ1M7zUyZBntPXU"
name: "Class Map"
description: ""
type: "multipleRecordLinks"
options: Object
isComputed: false

This is pretty much what my script does that I mentioned earlier. It loops through the fields array that you can get from a table instance and generates output that I can copy and paste into another script. If an array of all field names will suffice for now, this will do the trick:

const table = base.getTable("Table Name")
output.text(`[
    "${table.fields.map(field => field.name).join(`",\n    "`)}"
]`)

The script that I use does quite a bit more, but this will probably help for now. If you want field IDs instead, replace field.name with field.id

@kuovonne I wasn’t aware that custom extensions had access to view fields. That’ll definitely be something to add when I convert my existing script to a custom extension.

const table = base.getTable("Table Name")
output.text(`[
    "${table.fields.map(field => field.name).join(`",\n    "`)}"
]`)

The fields in the view are in the view metadata.

Revisiting this problem today - the Scripting App workaround that I’ve decided on is to hardcode my own view object within my script. :weary: On the plus, I’m glad I have learned about this problem in my own tinkering, rather than on a deliverable.

const myViewData = {
	Chassis: ["Name", "Crew Supported", "Weapon Bays", "Generation"],
	Core:    ["Name", "Generation"],
	Engine:  ["Name", "Mass", "Generation"],
	Armour:  ["Name", "Mass", "Generation"],
	Shield:  ["Name", "Missle", "Projectile", "Generation"],
	Weapons: ["Name", "Weapon Type", "Mass", "Generation"]
};

//A bunch more code goes here.
for (const element of matchedFields) {
	let techRecord = await input.recordAsync(
		`Assign ${element} for ${modelRecord.getCellValueAsString("Class")} Class`,
		technologyFilter,
		{ fields: myViewData[element] }
	);
}

Basically, the above allows for the looping of input selection, but shows the correct fields within the record cards - so long as they’ve been hardcoded correctly without typo.

I’ve asked Airtable devs to look into providing a return of visible View fields within a view object. So frustrating that it’s lacking.