In the interest of some kind of data normalization and using key links in your tables/sheets it would be nice to display pretty text for the choice dropdown but save a key value to the database/sheet. This is more in line with how it is implemented in HTML which is what is ultimately driving things under the covers. This is the idea I’m talking about. The user would see the long text but the save would be the shorter. All that you would have to do is allow the user to optionally select a second column of data for the key values.
<select>
<option value="ford">Ford Motor Company</option>
<option value="saab">Saab International</option>
<option value="opel">Opel (are you kidding me?)</option>
<option value="audi">Audi Motors</option>
</select>
I ran into scenarios where I’ve wanted this. Can’t think of any good ones of the top of my head. Definitely something I’m accustomed to as a web developer.
@david This could be incorporated into a Pro Choice component. You could also add to it the Search ability that others are asking for. So you would have a basic Choice component and then a Pro Choice component. As for a use case for the key pairs. By saving off the key instead of the text, it would facilitate later on not having to find all occurrences of the text in those related sheets that the dropdown feeds. I use a key for most everything so there is only one place needed to change the display text. Someone could even use this for adapting the app for different languages. All they would have to do is change the text in the table that has the key text pair and voila, you have French. (or Bien and you have both French and Spanish )
@david I just thought of another feature that could be considered for this “Pro - Choice Component”. Allow for nested choices. Meaning once a choice is selected, as second list of choices would appear based on the prior chosen one. In other words, behind the scenes it would filter the next list of choices based on what was selected. I can’t picture the development interface at the moment but maybe someone could. I did see some Tutorial on how to pull it off within Google sheets but can’t find it at the moment. I have seen more than one request for this functionality. This one being the most recent:
I think it would also be useful for Unique ID Special Value. I hope that it is not a pro component because I feel like it would discourage relationship editing.
I’m continuing here from the UUID thread. I would love a hidden Value along with the visible Item in the choice list (ahem…along with per user data…ahem). But in the meantime, once a record is written, I think you could always use a lookup column or a vlookup in the sheet to get the associated underlying value or underlying UUID if that’s being used. I do this on one of my apps where the user selects a lesson type. Behind the scenes, I use a vlookup to pull the associated billing rate for that lesson type. Of course, this only works if the displayed value is always as unique as the hidden value. There might also be some advantages to write both values to the sheet instead of just the hidden value.
The addition of Per User Data for the choice component is huge and helps me progress a little bit on a couple of side projects. Now individual users can create their own values for a choice component.
I’d like to bump this thread now because I’m trying to work on a gas logging app. The app allows a user to create a list of their own vehicles. Right now I create a UUID along with the vehicle, so the user can change the vehicle name while retaining the same unique ID. While creating a log (after filling the gas tank) I allow the user to select their vehicle. The choice component currently allows me to select the vehicle name and save that name to a log sheet. Ideally, I would like to save the UUID for that vehicle to the sheet, but display vehicle name to the user in the choice component. I will be doing stats and calculations on the form entries to track long term gas mileage and UUID allows me to keep all of the stats together for a vehicle, regardless if it was renamed. With the current setup, I can’t change the vehicle name without breaking stats. Storing UUID instead would allow me to use relations to pull the the proper vehicle name and keep all of the form entries for that vehicle together. I could use a lookup to get the UUID from the vehicle name, but a vehicle name change would still break the old log entries and a lookup would fail.
I do have a way around this by presenting a list of vehicles first, have them select a vehicle, then present the form button and pull in the UUID to write to the log. I’m not in a desperate need of this yet, but it beneficial.
Yes, +1 to this request. I did a lot of searching and testing before realizing this wasn’t possible. My use case is identical to Jeff’s and this is a frustrating limitation.
Here here. I’m currently testing my app with a lot of dummy content that will change. So some of my choice components send data currently that won’t be the final data in the app. The ID for that particular row of course will stay the same even when I reboot the app with the real content. But I can’t have a choice component bring up a bunch of IDs. The user would have no idea what is what. Currently my workaround is really complicated and involves several extra columns as well as including the ID with the “pretty text” so I can parse it out inside sheets. Really hoping to see this soon.
I haven’t created this exact thing, but I’ve done something similar, and I think there might be a way to do it. I have an app that uses a set of nested Inline Lists (not Choices) from which users select their desired input. In the last screen, they push a Form button, which brings up a screen that allows them to review and submit (or cancel) their selections from the lists, which are added to the form using Column components. This allows me to drag along other information associated with each choice (e.g., a UID) into the final form. It’s not the most elegant or efficient approach, and there’s a delay, but it seems to work (in the developer interface, not so reliably; on my phone, it’s more stable).
Applying this to your vehicle case, it might work like this:
App opens to an Inline List of the vehicles (tiles with images of the cars, say), which is pulling from the Form sheet where users can add/edit vehicles
User selects a vehicle. This takes them to a Details screen where they can add whatever info you want to capture. This info is added to the row corresponding to the vehicle in the vehicle sheet (you’ll have to add columns to capture this new information).
Add a “review and submit” Form Button at the bottom of the Details screen. Now you can use Column components to pull any information you want from the vehicles sheet into the activity logging (form) sheet.
@apertur.co Yes, this is actually the approach I started with and it is definitely an option and gives an acceptable app flow. The problem I ran into though, was that I also have a user defined list of gas stations (with UUID). I want to allow the user to select a vehicle as well as a gas station. This means I would have two UUIDs from two sources that I want to save to the sheet. At this point, using your method, I have all the vehicle info that I can bring into the form, but I also want the user to optionally select a gas station. The best flow is to just provide a choice component for the gas station, since I can’t use your method twice to pull data into the same form.
I could get get around this by creating another sheet that would build a dynamic list of vehicle/gas station combinations (with UUIDs for both). Then using relations between the vehicle sheet and the generated sheet, I could present the user with their vehicles, they select their vehicle and are presented with a list of related gas stations from the generated sheet. Using a form button from that list would give me vehicle UUID and gas station UUID via the column values. The more I think about, I think it could work. Probably not on a large scale, but the app is only intended for a few users anyway.
I thought I put this into the https://features.staging.glideapp.io/ a long time ago but it’s not there. Anyway search for Search for “Choice Component - allow key display pairs” and vote for it.
)