@petter - Nevermind. I just rewatched @dan1’s grocery app demo video and I think I realized my probem. I was trying to create a list or add the first value on my list for that user as part of “creating a new thing” using the “set a field” function like I had for the other input cells. Looks like I need to have a separate element to create the list ahead of time and then use the “add to a list” function as a secondary workflow after creating a new thing, rather than trying to do it all at once. I’m going to try that and see how it goes.
@dan1 - Watching the second half of your “How do I build a grocery list app?” video has helped me with custom states and lists. However it is still not clear to me how types of things behave when a field of another type of thing. For example: when creating a list, why can’t your user field be list of “thing”? In your video at minute 14, you create this field on your user type as “List_item”:
I was expecting the field type of “Grocery_List” to be “List” for each of the grocery lists you’ve created as their own “thing”
and then you are adding that “list” to your “Grocery_Lists” list even though it is the “wrong” type
Hopefully you can follow this example from your video.
In more general terms, I’m running into this same issue a few different places. On my user type, I have a field named “Companies” defined as list of type “Company” but then I can’t add the names of companies to that list because they are being entered in the inputs as text not as a “company” type. Or I can get the company to be added to the list, but then all I can see is the string of characters, not the company’s name.
I’m not sure what I’m missing, but would appreciate clarification on this point.
On my user type, I have a field named “Companies” defined as list of type “Company” but then I can’t add the names of companies to that list because they are being entered in the inputs as text not as a “company” type.
Wouldn’t the simple solution here be to use a search box that has a data type of company and you search the company’s name? Not sure why you’re using an input with type of text here. Could you explain / share a few screenshots?
If you could, please try to upload your screenshots with a bit higher resolution. A bit hard to decipher the ones you shared earlier.
Sorry if I’m making this too complicated. I’m trying to partition data through creating privacy rules (and dynamic choices) as Petter describes below.
I followed your video example to create the lists @petter describes above and it seems to work within the repeating group visual, but when I look at the company list on the user, I see this (assuming these are the unique identifiers that Bubble creates for each “thing”:
and when I try to reference current user’s company_list as the dynamic choice in a drop down menu, I get 4 blank rows.
Does this make sense?
OK, for anyone else having the problem with the unique ID showing up in the data table, there is a button called “primary fields”.
You can find it in the “app data” tab of data and that is where you set the unique identifier field label you want to display, so that you see “company 1” not “1544913740854x649…” I might have read this somewhere, but didn’t have context for it at the time. One problem solved, still working on the much bigger one regarding database relationships.
Just this week I was also struggeling with making a list, another video gave me the simple answer: begin with the list field you want to populate as the first value and then use the :plus command to add the values you wanted to add to the list in the first place.
If you know then it is easy.
Would you recommend planing from the database first or the design first? I seem to be trying both in my one site that is heavy on the database side and can’t seem to figure out which get me from point A to point B smoother with less backtracking and fixing.
best post I read and wish it was the FIRST post I read when I started down this Bubble path (which I love!!)
Thanks for the kind words!
Actually, I’d plan for the why before planning database structure or any design. By why I mean, why am I building an app in the first place? The reason this makes sense to me is that it gives you two different perspectives: what item is actually being stored in the database, and for what purpose? And with that, you can set up a structure that you don’t need to change later.
Let’s take two examples of database-driven apps that have a similar item but different purpose.
An online marketplace for cars
Purpose: Allow customers to search for different cars, put them in a cart, and purchase
A repair shop inventory
Purpose: Allow employees at a car repair shop to keep track of cars that are in their care
Both databases have the same item – a car – but the purpose of the database is very different. In App 1, the most important app feature you have may be to allow customers to efficiently search for cars they are interested in buying. In App 2, it may be focused around who owns a car, and what is its status
Each of the apps require you to make structural database decisions early on for them to work efficiently for their purpose. App 1 may need a bunch of data types related to search and recommendations, and App 2 may need you to consider privacy regulations for the cars and their owners.
So purpose first, then database, then design.
Hope that made sense.
I’ve found some value in design first helping me structure the database. But still learning to be efficient. Or at least trying.
I’m building a tournament software and there are a lot of moving parts. First build was database and design at same time and now reevaluating the database structure to make it more able to be scaled.
Yeah, there’s no “wrong order”. The best method is the method that works for you, so please regard my previous post not as an attempt to describe the “best” or “correct” way, but merely trying to illustrate what my thought process looks like when planning for an app.
o. I am far from right…I’m just winging it. I really appreciated your view and wish I had it when I first began…because now I am downstream fixing a ton of things and rethinking the design of database and design.
Seconding @petter again here. Thinking through the why is an incredibly important part of building an app.
When I’m at the outset of building an app, I try to spend a few hours outside of Bubble trying to figure out what the app aims to do. Then I’ll design a close to ideal database structure. Only after that, do I start porting my structure into Bubble. (Otherwise, I’ll fall down a rabbit hole of experimentation…)
When you start developing apps (in Bubble or in general) thinking through a database may be difficult. But there’s great value to at least sketching out your data types (and their associated fields and relationships) to avoid a duct-tape database.
Regardless, one of the biggest mistakes I see beginners make is to go full force in building without a solid understanding of field types. (Ex. an address split into 5 different text fields versus using geographic address, using “text” for something that should be a number, using multiple fields when a “list” would work better - ex. Listing Image1, Listing Image 2, etc).
That’s some good stuff.