Empty, required (filtered) choice component preventing form submission

Three choice components in use here, all required. As illustrated, options selected in choice components 1 & 2 could mean there is nothing to select in choice component 3. Because it is required, a user cannot submit the form.

It’s also visually odd as it’s not handled by the form as a non-selected state.



Suggestion:

“Requirement” as feature for choice components. Full feature options:

1/ Filter
2/ Sort
3/ Visibility
4/ Requirement
Set condition for when component is required
(+) add condition (here, make available filtering by screen)

1 Like

Are the choice component values determined from dynamic relations?

If there are not many possible options you could create a visibility condition for the 2nd choice to only show if certain selections are made in choice 1 and the 3rd only shows if certain selections are made in choice 2. I have a couple of items that would be required if the conditions for their visibility are fulfilled and I haven’t had an issue with it so far.

No, but I see why might think that.

I was suggesting “requirement” as one more choice feature.

1/ Filter
2/ Sort
3/ Visibility
4/ Requirement
Set condition for when component is required
(+) add condition (here, make available filtering by screen)

1 Like

Right…the only way to submit would be to hide that third choice component when it’s not needed. If the first two are simply showing value based on screen filtering then this is not possible, however, if you create that filtering logic in the GDE via relation columns, then you can hide the third box when that third relation is empty.

2 Likes

I think you mean manipulating visibility on component itself? that would yield a peekaboo type UX where component appears/disappears based on a selection – not ideal.

Yeah, that’s sort of what I was thinking so it sounds like that wouldn’t work for you.

I like Robert’s idea of filtering the relations columns though. That sounds interesting.

Of course, it’s an alternative. But in my case it leads to the same tricky spot. I need for that 3rd choice component to be there. If a user makes a difference selection in component 1 & 2, they will have a 3rd choice (a required one). So I can’t pre-emptively get rid of that 3rd component before the form loads. I just need to disable the requirement when it’s not necessary to make a 3rd selection.

Could you still have the “peekaboo” UX but instead of showing nothing you instead show a third choice component that’s not required?

you mean this?

Feels a little dangerous but I set up an ITE column to fake a DATA default value for the 3rd choice component (if Option 3’s value is empty, then empty character, else Option 3’s value).

Now default is a blank that’s not truly a blank. Still required but can submit. Meh.

hmm. you mean in total 4 choice components: 3 required, 1 not. Hide one of the required components when a selection is not required?

Can you add another line to the choice component that says “No Selection” so then if they choose 1 and 2 then you can still show them something that they can choose so they can move on with the form but it isn’t new data you have to worry about?

3 Likes

Thanks! Text is actually much better than an empty character. I’d even go for the dash used in the default non-selected states. Oddly, the only thing an ITE column will get me in a default is a blank value regardless of what I use in “THEN”

1 Like

Great! I hope that works out for you :slight_smile:

1 Like

It’s a band-aid. hard to trust what I can’t see.

1 Like

Yep! Not a perfect solution, but it lets you retain a third choice component that’s not required when it’s not needed for visual consistency.

As for your blank character solution, that’s one approach for sure. I was entertaining the idea (mind you I haven’t tried this ever) to have your choice components (at least the third one) populated via relations in the Glide Data Editor and then if that relation is empty (no choices needed) then do the switcheroo to display the dummy, non-required choice component.

Of course, all this hinges on the fact that the dynamic relations will work within a form…

1 Like

I like this.

I see, I see. This is interesting - haven’t tried dynamic relations either. Option 1 is already a parent/child relation so 2 and 3 can probably be folded into their own. The bad news on visibility is that I can only use values in the destination sheet and user profile to set conditions - not particularly useful.

Bah…yeah, you’re right on this one… ina form you get the destination sheet not the source sheet.

yeah just tested with dynamic relations. They too work with choice components (good to know!) but same visibility issue. Thanks for trying!