Text field that allows only text

Suggestion Box
1

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.

2

Text fields have always been “anything goes” kind of fields :blush: … and the fact that it’s not necessarily constrains by a specific data type can actually help customizing Coda to one’s liking :blush: .

It adds the flexibility the other fields might be lacking (due to their data types/their limitations), even if it’s just for “display” :blush:.

2 Likes
3

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.

3 Likes
4

Hey there! I recognize you from Airtable forums and you were always super helpful whenever I had a question. Glad to see you over here too!

1 Like
5

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. :wink:

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.

2 Likes
6

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.

2 Likes
7

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.

1 Like
8

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.

9

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.

1 Like