Programmatically Hide / Show Field(s) - Add / Modify FILTER to an existing VIEW?

Hi,

Is there a way to Programmatically(*) Hide / Show Field(s) - Add / Modify FILTER to an existing VIEW ?

Same question came into my mind about:
COLOR & SORT.

Best,
oLπ

(*) = by SCRIPT Block.

No, this isn’t currently possible:

Thank you @Shrey_Banga & Script-Block team !
I hope these instructions will be added in a future evolution of Script-Block, in a not too distant future, because I’m tired of cloning my tables-templates by adapting Field-Names and Field-Types and Views by hand.
Thank you for your understanding,
olπ

1 Like

@Shrey_Banga @Airtable
Nobody has posted about this in a while, but I think the addition of the recent Airtable Buttons makes this much more viable

The ability to show/hide field(s) based on button pushes (through scripting or natively) could be essential for quickly toggling extra information or variation on existing information in a table (an additional roll up field or formula for example)!

Very often I want to be able to see a little bit more information without having to create a separate Airtable view (This could be an easy way to reduce a lot of clutter for users like me who have many views for their table)

Hi @Shrey_Banga , is this on the roadmap? I have use case where I programatically create a table with lots of fields for my users but I’d love to also programatically create / edit a view for them with the less commonly used fields hidden by default

programatically create / edit a view for them

Hi @Shrey_Banga & @Eugene_Kim

this is an old use-case of mine, and I would know if Custom-App would one day propose a Custom-View , customizable by js ? REACT ?

I found some workarounds to make my template-view look different from Scripting-App but hide/show fields definitely stays out of scope !

olπ

Doesn’t this run a bit contrary to the whole concepot of filters/views? Like, I understand how it’s different but if Airtable had any intention of actively supporting such use cases, they’d have made that part of the platform more programmatically modular to begin with.

I’m pretty sure you can do that and way more with the SDK, though.

I wanted a button (labelled “View child records”) in each record of a parent table to set filter conditions for a child table. I created a button with the URL of the child table, and the button appended “?filter_{field}=” & ENCODE_URL_PARAMETER({field-value}). The button worked great, and even moved the focus to the appropriate table tab, but alas the page redrew without the URL filter specs and just displayed all the records of the child table. What ultimately “worked”, if you want to call it that, was to append the URL filter specs to a SHARE VIEW URL. The displayed page then showed the filtered records, but alas they couldn’t be edited–because it was just a read-only share! It appears that if you want to filter a child table by some field value from a parent table record (all client X’s orders), Airtable forces the user to manually search through potentially thousands of client records, copy the appropriate client ID field content, switch to the Orders table and manually configure its filter spec. All the cute Airtable demos have only a few records, so this problem doesn’t become evident. Hundreds of clients and thousands of orders later, users are pulling out their hair. Solutions, anybody?