I"m struggling to truly understand the logic behind the dynamic data builder for data source and the preceding field where you enter a type.
I get it at a high level; however, I, and everyone else I’ve seen use it, seem to be guessing along the way instead of knowing exactly what to pick next. We don’t deeply understand the logic. Without this deep understanding, bubble is incredibly challenging to learn and use whenever you’re trying to do something where you don’t have a step by step video matching your use case.
I don’t think a lot of us are randomly guessing what to pick next…
Just takes time to set up your data structure properly to best-fit what you are trying to do, then on the front end it kind of flows how you want (once you get over the learning curve of the actual way the editor UI works, etc)
Most videos are just general concepts and you have to adapt what they are showing to your own app of course
Any specific examples you need help with?
For example if a Car type has a Color field, and the Color type has a Hex field, then in a text element to show the hex value of a car it would be Car’s Color’s Hex
With my current issue I figured it out. And yes, it was what you said (related to data structure). But in my case I had to hack it and remove the option set’s a table was linked to and go database classic and create a connected table. I’m now failing to see how option sets are going to be useful. I get it sort of, but then in actual practice, when you want to actually use a relational database as it should be used and can be used, the benefits go away because it doesn’t work with option sets.
What I didn’t recognize was that was my problem and why dynamic data expression was not working intuitively.
I guess when I come across something again I’ll be back.
I feel like this is some kind of Bubble gaslight on my part on all your questions because I’m like “What are you talking about? It’s easy just set up your data and it works??” but it’s just a learning curve, getting used to how Bubble has worded everything, and conceptually how everything goes together.
IMO some videos I’ve seen dive straight into placing all the elements and workflows without actually showing the database why things are set up a certain way (not all but some videos) which doesn’t help.
Just depends on what you need. Some people are eager to use option sets then find out the hard way later you can’t add new options from your app, you have to add them from the editor and push it to live.
A good use-case for option sets would be “Invoice Status” so the type Invoice has a field Invoice Status. The option set has options like “Unpaid, Paid, Past due, Voided”. where inside your app you are going to have specific hard-coded things happening based off of what the status is. You might do a weekly scan of all invoices that are “Past due” and send an email to a customer that they need to pay it.
Or a car market place you might have an option set with options like “Listed, Sold, Cancelled” and based on the status of the car listing’s status you would be doing completely different things like showing the page to buy it, or showing the page of who bought it at what price.
My instinct is to still build a table so I can add connected tables to it later should the need arise, even though at present I might not see a need. It’s hard to get over that practice once established and once you’ve seen that design practice pay off. I guess it always comes down to tradeoffs. It seems, however, should you follow my practice, it’s easy to switch to option sets as a solution to improve performance if it’s a problem with scaling and you didn’t need the sub tables. But digging yourself out from the reverse scenario where you one day need sub tables, seems like a lot more work.
Yes I usually recommend tables except for my example like a Status or something where you are specifically making your app do different things based off of the option chosen.
Later down the line if there is an issue it is fixable even with a bunch of data in place. What you do is create a backend workflow that “converts” you’re current structure to your new structure and you have it run on each item in your database. Of course it’s a pain to deal with but it can be done at least
Also with option sets you can add more attributes (fields) so each option’s Display could be text, but each option can have it’s own number field tied to it for example
