It seems like I can include an image in a text field. I would like to have a way to have a text only field that does cannot include an image. I would like to be able to limit a text field to only a text data type, and an image and text are different data types. For example, a number field can only include numbers, and a date field can only include a date. Number and date fields cannot include different data types. Why can a text field include non-text data (an image)?
Perhaps this would be part of the column options? There could be a toggle that says to limit the text field to actual text. If we want to get fancy, we could even have an option to limit the field to single line text.
Text fields have always been âanything goesâ kind of fields ⌠and the fact that itâs not necessarily constrains by a specific data type can actually help customizing Coda to oneâs liking .
It adds the flexibility the other fields might be lacking (due to their data types/their limitations), even if itâs just for âdisplayâ .
Iâm okay with having an âanything goesâ kind of field. Thatâs how I view a canvas.
But sometimes you want to be able to constrain a field to a particular data type. If the only valid data for a particular field is straight text, I feel that we should be able to enforce that. Itâs a common situation.
Agree. Thereâs a certain developer comfort in knowing that text, and only text, will ever exist in a field. This can help to eliminate other downstream problems when a user copies and pastes embedded (hidden) tags, and all sorts of craziness that can creep into a process.
One approach - a Pack that simply transforms the value in the column to plain text. Such a pack could display plain text, but sustain the actual value.
A RegEx formula could also be used to replicate the column as plain text, but you know how I feel about duplicitous fields.
I think you need to view the text column type as an âalmost anything goesâ kinda field as well (i.e., rich formatting, etc.). And because I just said that, I had to click the upvote. If a text field can be a link, it should surely support plain text.
The advantages of a plain text field are many including instant sanitization. This is something no-code developers need because they donât know much about the shape of text under the covers. Half the battle when building no-code systems is capturing clean data and this seems to be a good way to assure clean data for whatever purpose such data will encounter further downstream.
Under the hood, itâs JSON all the way down.
The Text column type came first, and now there is indeed an understand that âTextâ really means âUnstructuredâ.
Canvas came much later and thatâs more like âUnstructured + you can add tables and formulas and anything elseâ.
So yes, we are left with a gap, and I too often find myself wishing for âText Onlyâ field that sanitizes input for me when itâs copy/pasted.
The number type already (sort-of) does that with copy/pasted numbers, and so does the Date type.
JSON all the way down for everything including the entire doc itself, or JSON only for text columns? Thatâs what _Merge() shows, right? But the actual shape of the JSON is undocumented and therefore subject to change?
Is there a Whatâs New that shows historic info on when features were released? I wonder how long Canvas columns have existed.
Thanks for the historical background. Thatâs why I suggested adding a column option to allow for restricting text fields to only text. We canât change legacy behavior, but adding column options should let users preserve legacy behavior by default while also adding this new feature.
Just because I ran into something similar recently, I think a pack could be written to make a custom column type where the value could be checked against a regex pattern or you could set a multiple select option to trim out emojis or whatever.
JSON all the way down for everything including the entire doc itself, or JSON only for text columns?
I am not the expert under-the-hood tinkerer here (that would @Paul_Danyliuk btw), but from what I see a Coda doc is essentially a big JSON document that is downloaded in its entirety when you open it in your browser, then it is âinterpretedâ for you by the Coda front-end.
The doc is not strongly typed, so the Column type you specify is more of an indication to the front-end on how to interpret and present the JSON it finds in each cell. Nothing stops the end user from putting Text content in Number cell and so on.
And yes, itâs basically what _Merge() shows, but itâs not documented and you use at your own risk.
⌠and the fact that itâs not necessarily constrains by a specific data type can actually help customizing Coda to oneâs liking 