@gnelson Great idea and point! 
Will do!
@sizzily86 Awesome!
I think that’s a really great idea to first get the hang of setting up, and querying data types and fields through an RG. I think I did it this way too!
One thing to mention, in the Fruit/Grocery example, you may have already done this but I would change the ‘Fruit’ field, to be a single Fruit, instead of a list of Fruits - inside the Grocery data type. I also changed it to GroceryItem (just incase that helps see that each GroceryItem as a single thing, not multiple Groceries stored within a single data type). This is because Date of Purchase, Expiration for that GroceryItem’s Fruit Purchased, and Stored Location will probably pertain to one specific GroceryItem purchased (as its reflected in the Excel sheet you already have).
In summary, each GroceryItem will be associated with one type of Fruit (in the Fruit field), but each Fruit could be associated with many different GroceryItems, since anyone can buy the same type of Fruit, on different dates, and store it where they prefer. To show how lists work, we could also choose to store a list of GroceryItems on the Fruit data type:
This way, if we had a GroceryItem form like this:
The first action in the workflow creates the new GroceryItem Thing:
Then the second action, adds the new GroceryItem Thing, to its Fruit’s Thing’s list of GroceryItems field:
So for the row where Peter bought an Apple, this would be entered into the inputs:
And the row for where Bob bought an Apple would be:
Those new GroceryItem Things are created and look like this in app data:
Then we can also see that those two GroceryItem things were added to the Apple Thing’s GroceryItems field (which is our List of GroceryItems):
Here we see two long unique IDs in the GroceryItems field. This is showing that we’ve connected the GroceryItem Things for Peter and Bob, to the Apple Fruit Thing successfully. We can double-check this by changing the Primary Field View for the GroceryItems to be the Buyer’s Name:
And then this will show:
Now for displaying all of this information in the repeating group. Here we can have two different setups:
- This setup uses two repeating groups. The outer repeating group does a search for Fruits:
And the inner blue repeating group, does a search for the GroceryItems connected to that Fruit. We need two repeating groups because we have multiple Fruits to be displayed (on the outside), and then we want to show multiple GroceryItems, inside each Fruit’s cell. The data setup for the inner repeating group would be:
Then in preview mode, it looks like this:
In the Strawberry first cell, there are no GroceryItems to display in its inner repeating group, because there are no GroceryItems connected with the Strawberry Fruit Thing in our database.
In the second Apple cell, there are two GroceryItems to display in its inner repeating group, because Peter and Bob both bought Apples.
In the third Pineapple cell, there is one Grocery Item to display, because John bought a Pineapple.
- The second option setup is almost exactly like the first, with the only difference being about with how the data is queried in the inside GroceryItem repeating group.
Here we’re still doing a Search for Fruits on the outside repeating group:
And the inside repeating group displays each Fruit’s list of GroceryItems, using the expression ‘Current Cell’s Fruit’s GroceryItems’:
In preview mode, both setups produce the same results:
Editor:
So this probably isn’t the best example for understanding when to use a list of things and when not to, but I remember that this Twitter example really helped me in the beginning:
In it Vlad explains an overview of his data structure extremely clearly, and when lists of things were used.
Then, this thread is also really awesome in explaining when to create ‘join tables’ in Bubble as well (ignore my posts there and look for Nigel’s!):
Let me know if you have any questions!