Best way for managing checkboxes in repeating groups and saving data?

[julian5]

Hey everyone.

Use case with example:

A user is ordering a hotdog online. They can order as many different sauces as they want.

• Ketchup
• Mustard
• Hot sauce
• Mayo

This restaurant has offered the same sauces since the beginning of time and steadfastly refuse to change their menu. So I’m putting the sauces in an option set: Hotdog Sauce.

In the order data type, I have a field called “Requested Sauces” that is a list type of the Hotdog Sauce option set.

On my order form, I use a repeating group with the data type Hotdog sauce.

Since there is no order created until they submit the form, I have nothing to bind to.

In the sauce repeating group, I have a custom state called “Selected Sauces”.

When a checkbox is changed, I then set the state of the repeating group:

When the checkbox isn’t checked, I :minus item to the list

Then when the form is saved, I save the Requested Sauces field in my data type to be whatever the Selected Sauces custom state is.

This has worked well for me so far, but it occurred to me that it might not be the best, efficient, or most maintainable way of doing this.

Does anyone have a better way of doing this? It’s tedious to set this up every time. Remember, I cannot bind to a parent object in this use case.

[georgecollier]

I use this method.

Don’t know how else you’d optimise it. I prefer to use an icon rather than checkbox and conditionally change the icon when List of X contains the relevant option, but that’s just a style preference.

[boston85719]

@julian5

Does anyone have a better way of doing this?

I have done it the same way…but the concept of is there a better way of doing it largely depends on little details, such as whether or not you worry about the user refreshing the back for any number of reasons this could happen and if the custom state values are lost or not.

I recently had to upgrade an app that is essentially a menu ordering app, with customizations to menu items as well as options like sauces or allergies. As the goal was to minimize WUs, I opted for an approach similar to yours in the sense that the order is not created until they submit the form. There may be some differences, as in the app I worked on it was a ‘form’ but had about 20+ different views as the user moved through the flow. Due to those concepts of saving WUs and not wanting custom states lost when user refreshes page or uses browser back button, I used URL parameters to store all the selected values.

This allows for a feature to show the user the ‘last order’ that they may have abandoned (for this I incorporate local storage).

Most of the time, custom states are fine if not concerned about lost values due to page refresh or browser back button usage, but if you are concerned about those things, than URL parameters is the way to go.