Set State Data/Memory Efficiency - Set State as a Thing vs Unique ID only?

Need help
1

So I am saving a “history” of products users view in my mobile single page app by setting the state of an element with the products when people view them, so that they can press a back button to take them to the product they just viewed. Right now, I set the state of the element to a “thing” (in this case a product) and each product has obviously has a bunch of data fields associated with it. Would setting the state to only the Unique ID of the product (and then searching for that product using the unique ID to display the product) result in better performance or memory usage?

Basically, does setting the state of an element to a “thing” mean that the element is holding on to all the heavy data associated with the “thing”, and would setting the state to only a Unique ID be much more lightweight?

2

My experience has been that it doesn’t make any difference. Saving the thing is functionally the same as saving just the ID as the data associated isn’t pulled unless you use it. I may be wrong though, and it would be interesting to find a way to test.

3

Pretty sure saving a Thing into a state forces Bubble to load the entire Thing. You can actually view this in the debug inspector. Your state will have all information about the Thing loaded (constrained by your privacy rules).

I’m on mobile so i cant check a browser inspector at the moment. Just sharing based off my experience.

4

Ignore my previous answer in this post. After testing with a bit bigger amount of data (400 items of a data type with 15 fiields) I did not notice a big difference in using the item or the id. Whether it is on page load, during browsing, while copying the data between states. Maybe when the amount of data is larger (more items or data types more heavy) it will matter. But in your case, how many people will have a product history of 400 items. Also noticed that images are not retrieved until they are actuallly shown to the user. On mobile you might want to play around a bit of course because of less memory and processing power.

5

Things ARE their unique IDs. No diff. And the CORRECT thing to save is THE THING, not the Thing’s unique ID.

1 Like
6

The question is does it

But I am pretty sure it doesn’t until you actually request fields from the Thing

7

No that’s not exactly how it works.

2 Likes
8

Actually, no… it’s the other way around…

Data for a Thing is only retrieved from the database when you reference a field from that thing - and that includes the unique ID field.

Take the following example DB:

Book
Name
Other data 1
Other data 2
Other data 3
etc.
Unique ID

User
Name
Favourite Book (of type Book)
Unique ID


When a User loads a page, all of their User data is loaded, e.g.

Name: Dave
Favourite Book: 019283746786x8373984383927482746
Unique ID: 02823827382738x91738297169291100

Referenced things are just stored (and loaded) as a string (unique ID) until you actually make a reference to a field from that thing (and that includes the unique ID itself), at which point the full data of the thing will be loaded.

No data at all will be retrieved from the Book database if you don’t refer to any fields from it.

So, if you have a custom state of type ‘Book’ on your page, and you set it to the Current User's Favourite Book, all that happens is that the lookup reference to the book is set into that state - no more data is loaded to the page.

If, however, you had a custom state of type ‘Text’, and you set that to the Current User's Favourite Book's Name, in order to access the book’s Name, the entire data of the book has to be loaded to the page.

And the same applies to setting the text custom state’s value to the Current User's Favourite Book's Unique ID (although you might well think that wouldn’t be the case - since the unique ID is already on the page in the User’s Favourite Book field - but it is). Simple to test this with your browser dev tools.

So, to summarise:

  • Setting a custom state value to a Thing doesn’t load the thing.

  • Setting a custom state value to a thing’s unique ID does load the thing.

i.e. it’s more light-weight to set the custom state to the Thing… not the Thing’s Unique ID

So, as already pointed out in this thread, the correct way to do this is to set the custom state to the Thing itself.

Obviously, if the thing (or things) have already been loaded to the page (and in many, if not most cases, including your specific example, they will have been) then it makes no difference in terms of the actual data/memory efficiency etc. but still… the correct way is to use Things, not fields from Things (including unique IDs).

3 Likes
9

Ah looks like i was mistaken then.

Maybe it loads when viewing in the Bubble debugger inspect function.

1 Like
10

This was a great explanation, that really clears things up for me. Thank you!

1 Like
11

This topic was automatically closed after 70 days. New replies are no longer allowed.