Scroll to Entry slow on 4000+ entry database

When using “scroll to entry” on a database with several thousand entries the action lags when the workflow is told to scroll to an entry toward the end of the list. It can take up to 30 seconds and sometimes timeout the page. I’m not using any filtering or search functions which might slow it down either. When the entry is toward the top of the list (say several hundred or even 1000) it is very quick.

The database is just 7 fields of short text. Does anyone have any creative solutions for scrolling to an entry in this scenario? The purpose is to show the user entries that are close in proximity to the current entry.

1 Like

This is because you are loading 4000+ entries…try loading less and the scroll to entry will work faster as it will not have to load each entry that comes before it for the purposes of scrolling to it

1 Like

I understand the concept of limiting the results, but in this case it’s a list of color options and I want the user to be able to scroll through all color options. Is it possible to start loading the results in a certain area of the list first, and then allow for scrolling the entire list?

I think the only solution is that adding pagination. Loading all the data and drawing it on the screen is not an easy situation to overcome even with coding.

Is it an option to make it a two step process, first show the major colors and when a user clicks one, show the variations for the chosen color?

1 Like

quickly and without an ability to stop the scroll as a way to produce an effect to convey to the user ‘look at all these colors we have’ as a way to impress the user?

Scrolling to the specific color isn’t necessarily for show, but just a way for all colors to be accessible to the user without many more clicks. For instance, if they are in the greens I want them to easily be able to scroll to get to the reds without having to click through a bunch of “pages”.

For more information the app automatically pulls colors from an uploaded image and matches them to a color in the database. The user then has the ability to change the color by selecting a different color in the database.

My dream would be to be able to load say 40 colors before the chosen color, and 40 colors after that are displayed immediately. Then, when the user scrolls in either direction the next 80 colors are loaded, etc.

Does the DB of reference colours change often?

If fairly static, this might be an option:

Preparation:

  • Export 4000 items to a JSON file
  • Upload file (to get url)

Live:

  • Page JS downloads JSON file
  • JS fiddles with it a bit
  • JS to Bubble gives the data “Bubble approved data structure” - either parallel lists, or a list of fake API result objects
  • RG consumes data and renders fast

Interesting idea. The data is static so it should work. How would you propose the data is rendered in the list so it can scroll in either direction?

Do you mean up and down? lol

Lol, yes. I wasn’t sure if you were responding to this or not:

My dream would be to be able to load say 40 colors before the chosen color, and 40 colors after that are displayed immediately. Then, when the user scrolls in either direction the next 80 colors are loaded, etc.

The RG would display all 4000, and hopefully not complain about it as its all on-page.

If you’re talking about a wrap-around list, where the start is joined to the end, RG probably wouldn’t handle that, you’re looking at a custom HTML widget.

Now I mentioned widget, have you considered a colour wheel or one of the other popular colour selectors?

1 Like

I see what you’re saying now about the RG displaying the list from the json, that actually might work great. Let me test it out a bit.

The 4000 colors are specific values so I wouldn’t be able to use one of the prebuild plugins.

@nate8

Hmm, “Show all items immediately” is a bust!
So is a normal RG with scroll to 3500

I think the RG isn’t winning, I’ll try a html table

Oooh so nice, scroll to line 4000 is like instant!

Of course its more work to design than a RG, including plumbing in the row controls/buttons, so consider it an option.

I’m going to catch some zzz’s

Amazing! Thank you for testing that. I’ll play around with a table and see how that goes. Thanks for testing that out for me today. I’ll put some work in tonight.

You’re welcome :slight_smile:

It also works with a bunch of <div> elements inside a <div> container, a bit more flexible than <table>

is it possible to share the editor you did this test on?

I’m really interested to have a better understanding of the approach in terms of

With the realisation that RG can’t cope, the revised approach would be:

Preparation:

  • Export 4000 items to a JSON file
  • Upload file (to get url)

Live:

  • Page JS downloads JSON file
  • JS renders data to DOM list, i.e. HTML of data and row controls for user
  • JS to Bubble gives event and row data resulting from user interaction

I tested with 4000 rows directly in a HTML element and Bubble was okay with it (not sure about mobile performance, but its still less data than a photo), which means the whole JSON file could fit on the page instead of being downloaded!

I only tested for performance of RG vs table vs div, along with scrollto, so the test app doesn’t cover the interesting JS bits. If you still want it, I’ll tidy it and share.

1 Like

That would be awesome :grin:

I find that this is the best method to process data client side in Bubble: As plain text. I use this method alot in different ways.

I find that even native Bubble elements work better with plain text using simple operators like Regex and splits.

1 Like