Since the end of February/beginning of March, I’ve been encountering terrible performance issues on one of my apps. I’m currently discussing with the bubble team, but during my investigations I discovered something about how plugins behave that I thought wasn’t the case before.
I’ve set up this test app:
On page load, the app will run some plugin code. This plugin code does the following:
On the page itself, I’ve set up texts to display each state.
Expected behavior:
Shortly after page load, “Hello” will appear. 5 seconds later, “World” will also appear
Actual behavior:
5 seconds after page load, both “Hello” and “World” appear
This suggests that bubble’s “publish” all states at once after the plugin code finishes executing. But I could have sworn it wasn’t always this way. In fact, I could have sworn that just a couple of weeks ago, plugin states were published as they were available.
For those of you who have worked with plugins in the past, am I wrong about this? Or did bubble accidentally (or maybe on purpose) change how plugins work?
Maybe not. Just glanced at the subject and replied rather quickly.
EDIT
BTW, the approach you’re using to create a delay is not good at all. There are lots of examples on the web for how to create a delay using a promise without gridlocking the UI.
Appreciate the input. The sleep function isn’t elegant, but it’s only being used to demonstrate this issue by simulating other code that might take a while to run. In this case there’s no UI to gridlock
We’re currently trying to explain to Bubble that we’re seeing strange behaviours within the publishState() function.
As you say, historically this method has instantly surfaced the state for consumption elsewhere… including on initial load. Currently it seems to get caught and is taking up to several seconds to execute - where the plugin sits in a repeating group those delays get aggregated.
Yep this hit our pre-published plugins across both test & production.
I’m relatively sure it bled over without us either publishing any changes to the plugin or pushing an app update to live but can’t be 100% sure on that.
It’s confusing as to what publishState() could spend ~1200ms doing seeing as its scope is local and it doesn’t (that we can see from Network Activity) make or wait on any calls / responses.
Yipes. I can only guess this might be a result of work being done for compatibility with the new responsive engine. I’ll have to check my existing plugins.
Yeh, I wondered the same thing there.
It’s been discussed many times before, but versioning these changes is so important when production apps rely on the stability of existing behaviour. I thought this was what we would see the Plugin API used for but it’s not been used since November 2020 when v3 was released.
This is the EXACT problem I’m having - A single call to publishState() for a list of items takes several seconds. Since my plugin has many of these, I was seeing delays in the minutes while waiting for every single one of them to publish before repeatinggroups could load.
I’m relatively sure it bled over without us either publishing any changes to the plugin or pushing an app update to live but can’t be 100% sure on that.
I’ve been able to confirm that it affects a plugin with an element whose code hasn’t changed since December or January. I started seeing the issues around the time they released a number of under-the-hood changes on February 26, and affected both live and production, despite us not pushing anything that day.
@austin3 We got a note back from Michael Lee from Bubble support saying it has been fixed - and it really does look like it has been fixed - I see what was taking 3-4 seconds now down to 22ms.
I got a similar one - It does in fact seem publishState() is faster which is great! I’m still noticing, however, that the original behavior I detailed in this post still is occuring regarding the app waiting for all states to be published.
Need to double check on this it but I’m pretty sure we don’t have it on our end.
We often use a publish state to turn a “loading” state on before running an API call or a function and then turn it off when completed and so far both text appears in the right order (while everything is done in the same fucntion)
This beauty seems to be back.
As last time, the delay is occurring somewhere between publishState() → front end components being refreshed… my measurements point towards the culprit being the frontend reactive render (probably the Repeating Group per issue in this thread) rather than publishState() itself.
It takes almost a second for a simple change of state to reflect through onto the frontend.
Ugh. That sucks dude. A state update should be near instantaneous unless you need to hit the db to set state or something odd like that. If setting a simple value, it should be quick AF
I’m hoping, no offense, this is an error with your code and not bubble cause this would be a massively fucked oversight. Updating states almost instantaneously is really relied upon in most plugins
I won’t be foolish and officially deny responsibility
But latency issues on repeating groups is a recurring one on Bubble’s side. publishState() actually seems fine… from everything we can see via our logging and Chrome performance tools there is some chunky function taking over during the DOM refresh on the repeating group that then stutters for ~1 second.
