Edit as Code // Custom Column Templates

[gandalfb]

Coming from https://community.getgrist.com/t/edit-as-code-custom-column-templates

Hi there,

I am currently diving into grist being really awesome.

Within my data there is a lot of repetition (like meta fields… Created. Modified. User. Etc)
Checks and references are repeatedly used.

Is there a possibility to edit the code?

Otherwise maybe custom column templates might help with that.

During the writing it might be possibility to prepare template tables and duplicate them. 🤔

Defining documents as code would be awesome, if not already possible and I simpy overlooked it.

Thank you!

Gandalf

[vviers]

Defining documents as code would be awesome

Agreed !

[vviers]

Starting to think about how we could help here. Will assign the team on this so that I don't forget.

@paulfitz @dsagal it would be useful if you could share with us whether you've considered this option already (seeing the "code view" panel in Grist makes me think that maybe was a plan at some point ?) and whether you think there are obvious hurdles we should keep in mind (I know the Grist data engine is designed like a high-end swiss watch ⌚)

My plan if we reached a working prototype would be :

• this would first live behind a feature flag
• turning this feature on in a document would need to be a very conscious action by the admin of a document
• manually editing code in a grist doc would deactivate all no-code features that we fear may not work properly anymore. I quite like what Metabase does for example : the nocode editor takes you as far as it can so that you don't need to write SQL yourself, but if you decide to grab the wheel and actually write/edit the SQL yourself then you agree that you can't go back to the nocode view later on.

[dsagal]

@vviers , it sounds like you are talking strictly about Code View, but I am not sure if OP's interest is limited to that. The Code View only specifies column types and formulas, i.e. the schema and logic of the document. But it specifies nothing of views (e.g. when creating columns by editing code, do you want the columns to become visible?). Even the logic isn't fully specified -- e.g. trigger formulas have the formula, but not the details of what triggers it (is it for new records, or changes to certain fields?)

In hearing similar wishes from others, I think views were of much interest. In particular, this came up, IIRC, when one has some tables with logic and a carefully constructed view (multiple linked widgets, nicely laid out cards), and wants to take that whole structure and copy-paste it (as code) into another doc. But creation of views as code has been brought up too (e.g. when you create a bunch of choice fields, if you know the choices, you may want to specify them).

So the first hurdle I see is having a good representation of a document. It could be essentially the output of REST API "fetch table" calls for a bunch of metadata tables, but that's very unfriendly...

But that's not the only hurdle. With an approach based on Code View, if you had a field Foo and you add a new one Bar, and remove Foo, and then save the code, how can Grist look at your new code and decide if Bar should be a new empty column, of if it's intended as a rename of the Foo column?