As I understand it in Bubble-eze:
A thing exists in the database. When you set the value of a thing, It remains in the database. You can do a search for a thing at any time, from any page. You can change it, delete it, etc.
Think of a state as being a temporary thing that lasts for only the current pageview.
Simple Flight counter:
For example, if we were to build a simple add/subtract calculator to count flights, we would need three elements:
- Number of flights. (Starting value: 0)
- add button
- subtract button
When a user clicks on the +/- buttons, the number of flights changes accordingly. We want this to happen without using things, just states.
Workflows:
Step one.
When page is loaded, create and set the state of flights to zero.
and
Step Two.
show the number of flights and the current state of the group’s flights, (within the editor) dynamically.
Step Three:
When the (+) button is clicked, add 1 to the state of flights.
and
To create the (-) button, copy and paste the + button (with workflows). Change the new button’s workflow to subtract from the state.
IMPORTANT PART: During this whole process the value of “flights” never gets entered into your database. That is the only difference between states and things. You can, put the current value into the database as you would with any other element’s value. If you don’t save the value to the database, or pass it via URL variable, it will be lost when the user leaves the page.
Step Four:
When the user clicks on the “submit” button, the state value is set in the database and is now a thing.
In your case, you would first set the state of your repeating group to 1, representing the first flight. You would then, in your workflow, add and subtract flights based on user input. When the user is done adding and subtracting, the outside “submit” button submits the final state value to the database or API.
Wow, that was a lot. I hope it makes sense. You might want to ask @romanmg and/or @emmanuel if I’m right with this. They’re geniuses. I’m learning as I go.