[Upgrade to Bubble Version 21] Improved Runtime Performance

Confirming that the probability of this Bubble Version causing issues in an application that has not upgraded to it is about as close to 0 as possible.

4 Likes

In my experience, a calmer, more streamlined approach than this is more effective in sparking action by the Bubble team.

3 Likes

While I’m sure we’ll never be able to properly educate Bubble users about your very cogent point #2, @gaurav, plugin users (many of whom I see affected by the color default issue today) should be advised of the following:

If a plugin just “breaks” suddenly in an existing page and you haven’t upgraded it nor attempted to use some new functionality in it, then the malfunction is due to some change in Bubble. Your first stop should be filing a Bubble bug report and then pinging the plugin dev for assistance. (Also, you can open your console to see what error(s) are being thrown. Not that this is informative to you, but it’s informative to Bubble.)

In the case of my experience with this today, I was only able to check out what was happening right as Bubble was already fixing the problem and so it went away even before I could do a screenshot for my own bug report.

5 Likes

@nick.carroll it wasn’t version 21 but an error in a bugfix Bubble had rolled out in color picker:

1 Like

Hi @mghatiya - lets take a step back so I can try to better understand your concern.

The “non-backwards compatible” change this version introduces is that elements that are set to be invisible on page load will not have a div on the page until they become visible. This means that any custom code (including a plugin) that tries to reference that hidden element on page load before it is made visible, may not behave as expected. I say may because it depends on how the code is written.

Now, it is nearly impossible to tell just by looking at the code whether or not a plugin/custom code would break or not, so the guidance is to keep an eye out for any plugin or code that references a specific element’s custom id and test to see if the app behaves as expected with the Bubble version turned on. If there is an issue, then the guidance is to adjust the custom code or notify the plugin developer or file a bug report with the team and not deploy any updates to Live on that bubble version until the issue is resolved (as is the nature with any Bubble version).

In your case, custom css that is applied to an element via its custom id should not cause any issues, but please do report any unexpected behavior you may see or use cases in your app that you are concerned about. I hope this helps.

3 Likes

Noted, thanks @treb.gatte.

No, plugin authors were not made aware of this change before the Bubble version was released. This was an oversight by our team that we will rectify.

For what its worth, our team is currently in the process of creating better documentation on our plugin editor api so (1) what is possible / not possible is known and (2) when we do need to issue a breaking change to the plugin api, we can properly notify plugin authors.

8 Likes

Comments like the below are a little infuriating.

It is only custom code/plugins that may have different behavior since we have no control over those.

Of course you don’t have control over the code of the plugins, but you certainly have control over breaking them. So bubble should 100% be reviewing common plugins for damaging issues prior to releasing code.

Get a group of testers, we will test free of charge for credits or something. But bubble needs to stop acting like their updates don’t have implications, and they need to work with the community.

3 Likes

Understood, thanks for clarifying.

So in all fairness, we did review and address the 100s of bug reports and pieces of feedback that came in during the time when this update was an experimental feature, and we did do testing with commonly used plugins (for example, the drag and drop plugin). I think our misstep in releasing this bubble version was not giving plugin authors a heads up about the change to give them time to make updates to their plugins before GA (which we will rectify asap).

That being said, you are definitely correct that we have a long way to go in terms of improving the reliability of our releases. In this case, the buggy release was a bug fix from earlier today, but the point stands. fwiw, we are hiring team members that will focus their time on this exact issue - and I do like your idea about crowdsourcing testing…

8 Likes

Thanks for the feedback.

Ok how about this. Gather 10-20 testers. Copy their apps to a test environment so it doesn’t affect the live app. Give them 48 hours to test and report.

Then, at least it’s somewhat on us if we don’t find issues also.

Just a thought.

4 Likes

Hi @nick.carroll,

Thanks for the response. Hopefully, I didn’t come off as angry as I’m not. I’ve done product development for big tech and it’s not for the faint of heart. :slight_smile:

One of the things I see Bubble needing soon is a program similar to the Microsoft MVP program (https://mvp.microsoft.com) This would help catch these issues earlier.

I’ve been in the program now for 10 years (5 yrs as Office MVP, 5 yrs as Power BI MVP). You have to be nominated by three MVPs to even be considered and many don’t make it. Once accepted, you are under a strict NDA that you will incur the wrath of God and Microsoft Legal if you break it. In return, you get early product design input and product pre-release access so that you can provide feedback, do testing, and most importantly, help the rest of the world understand how to use these new features. We get special forum badges, email signatures, jackets, etc. We also get to present at Microsoft conferences and in official webinars as well.

Y’all are growing and rightfully so, this product rocks! There’s no need to reinvent the wheel here and even a small MVP type program would be beneficial. If you ever want to talk to the person over the Microsoft program, I can put you in touch with her.

Thanks!

7 Likes

Isn’t the “experimental feature” time something like you just described but for everybody to test?

The problem with some plugin today was with an update that nobody new it was going to happen. Without building restricted circles this can be avoided with an email notification to any account that created a plugin saying: we will apply this change in a week, you can test this change now from the plugin editor and see if it will affect your plugin.

@dorilama while it’s a bit confusing what the relationship is between the color picker bugfix (I guess more accurately – an enhancement to allow support for color variables being used in color pickers in plugins) that went out across all versions today and Bubble Version 21, the thing that caused certain plugins to break was the former (not Bubble Version 21 specifically).

And it was a real bonehead error. Whatever that bugfix version of the color picker was doing, it didn’t accommodate the case of the picker being empty and returning null. So Bubble’s code was trying to do some hex/rgba conversion on null and crashing. Hey, we’ve all been there, amirite?

3 Likes

Hey @nick.carroll

We understand that the divs will not be available till they are rendered or visible.

The issue that I am always faced with is looking for the div that matches the ID. If the div is not available on the page then I attach some kind of observer so when it does appear I can execute the code

So here’s a question! Why doesn’t bubble provide this as native functionality in the plugin editor. It would be much easier for everyone if bubble had some sort of method or function that we can call on that would execute the plug-in code when the element appears

Since I bought this up can we also have a look at these

  • have bubble load script tags for us
  • utilizing open source scripts that bubble already uses

I can go on forever but I guess these are the most important things

5 Likes

@AliFarahat probably because there’s no real way to know that your plugin is waiting on such-and-such an element (consider that in your plugin interface, that field’s just going to be some random text field that accepts a string that represents the unique ID of the element you’re waiting for). There’d have to be some special input field to make this connection. (Which is not to say there couldn’t be one, but I wouldn’t hold my breath for something that tweaky. I think there are bigger questions of a similar nature, like “why is there not a canonical “getList” function?” )

You develop more visual plugins than I, so I’ve only run into this issue once out of umpteen plugins, but as you suggest, I handled it like so:

instance.data.funcWaitForElement = function waitForElement(selector) {
        return new Promise(resolve => {
            if (document.querySelector(selector)) {
                return resolve(document.querySelector(selector));
            }
            const observer = new MutationObserver(mutations => {
                if (document.querySelector(selector)) {
                    resolve(document.querySelector(selector))
                    observer.disconnect();
                }
            })
            observer.observe(document.body, {
                childList: true,
                subtree: true
            })
        })
    }

And then used in some other function like:

instance.data.funcWaitForElement(instance.data.drag_rg).then((elm) => {
        // do something that requires this element to exist
})
5 Likes

@AliFarahat, you’re not asking about situations like this, are you?

This is what initialize is for. You could instead just do:

As the docs state, initialize is executed just once when your plugin element gets instantiated in the page.

Edit: To be very clear: Your plugin element doesn’t have to wait for itself, because initialize. (But you may need to wait for some other element, in which case you’d take the approach I outlined in my previous reply.)

Edit 2: Also, you can load your scripts in a non-render-blocking way using defer. There are some things that the plugin API gets right and one of them is that initialize will only run after the dependencies you’ve defined in the header are loaded, so there’s no problems there and nothing you need to worry about except perhaps competing versions of the same dependency amongst similar plugins.

Once dependencies are loaded, initialize will run once for [this instance of] the plugin and then, immediately thereafter the update function will run for the first time (which is our first access to properties that the user might have provided in the element’s main property inspector), so the end of that routine is our opportunity to set things like an “Initialized” internal state and corresponding external “exposed state” and in that way we can tell the user that our plugin is either done with its stuff, or ready to accept Actions in the case of plugins that actually do stuff.

1 Like

@vnihoul77 Any idea how this affects performance for pre-fetching?

I’m assuming this update is supposed to increase the performance of non-prefetched apps, but I wonder if there’s any impact on prefetched apps.

2 Likes

Im sure a silly question, but can one downgrade a version by restoring a previous save point? Ie, I can test an app in v21 (not live) and then simply revert to an earlier save point if too many things are funky?

@drfalken I don’t know if reverting to a previous time would revert the version, but they let you rollback to the previous version you were on.

right, I guess that’s the question if it also rolls back the ‘bubble engine’ version

@keith I understand the cause of the issue and is perfectly clear.

What I propose is bubble alerting any account that creates plugins that a change is about to be published in x time, and the ability to apply that change on the test app of plugins.
In this way we can have a window of time where we can test the change without affecting production apps.
This could be a system similar to the experimental features: you go on your test app and enable “future plugin system update”, and then test if your plugin works.

My plugins (all private) were not affected by this change, but I would like to be notified when bubble is planning a change in the plugin system so I can check that everything is fine.

3 Likes