Another one from what I have experienced:
Repeating group with api calls as data source are always loaded even if the RG is not visible. So I use conditionals only when this RG is visible → data source = api call
Another one from what I have experienced:
Repeating group with api calls as data source are always loaded even if the RG is not visible. So I use conditionals only when this RG is visible → data source = api call
The newest addition to the new build I’m working on:
It’s amazing how you can miss the seemingly obvious by doing something another way for a long time…
Hope you put that html element into the reusable header
Oh yeah, then I only need to paste the ID and not the option too!
I often use negative padding on elements without the need to re-arange into a colum or row. Eg: -27px
There is a bug that gray`s out element references such as dropdown values, usually that happens when you update that dropdown data source value from a option set. You can fix by refreshing your editor.
No data displaying in your repeating group? Double check privacy rules applyed to that data first.
Standard file uploader and image uploader saves that information directly into bubble’s database. Long term apps may cause flooding and un-used files. Highly recommend tracking and deleting usign delete files workflow
before deleting or updating a data that contains that file url.
In a “Do When” workflow condition, when you cannot setup the condition you want (because Bubble doesn’t give all possible logical options), sometimes you can define that logic in an element’s conditional
tab and then copy/paste it as the condition for the “Do When” workflow.
Somewhat advanced and doing this wrong can blow up your Bubble app but… Say your app rely’s on a free plugin but the plugin publisher no longer updates the plugin so you need to update or customize it yourself. Normally, you fork the plugin, add your code, and then have to migrate (right-click replace) all usage of the old plugin to your new one with the enhanced functionality. Manually doing this one by one for each element/action that a plugin has can take a long time, especially if the plugin is used throughout your app. Not to mention, it’s error prone. There’s a faster and better way!
Since a Bubble app is just a json file, you can export your app, open it in a text/code editor, and mass replace all references/usage of the old plugin over to the new plugin. When you save and import the modified .bubble
file back into Bubble, the editor will refresh and the migration job is done! Actually just made a tutorial of this for early adopters of a plugin I made - see this 5 minute loom if interested.
Say you’re testing a workflow and it doesn’t work… so you open the Bubble debugger and step through the workflow and then it magically works. The reason this happens is (almost) always a timing issue. You can often fix this by placing short Pauses
before relevant actions.
that gives you the illusion of a fix because it works specifically for the combination of your machine and your network. what if the device is slower and computation takes more time? what if the network has a sudden slowdown? what if bubble takes an extra second to complete a database operation?
random pauses will work like a toss of a coin.
we both know that understanding bubble execution rules is the key to apply a true stable fix
Another option set technique I find very handy is a “boolean” option set with 3 options: true
, false
, and null
. This benefits situations like:
null
value and its subsequently explicitly set value, which isn’t possible with the native yes/no data type when the explicitly set value is false
. For instance, this is helpful when constructing a JSON string to send somewhere that also distinguishes between false
and null
.This can cause serious issues down the line. It was officially stated a while ago that if you cannot form the expression naturally in the composer, then it is not officially supported (even if it is valid) for that use case and may break in the future.
I do use this method to get around some bugs like matching data not loading in the composer options dropdown.
I recently came across the Responsive Viewer Chrome extension (a recommendation from @romanmg). I find it far more helpful and efficient than the editor’s responsive view or browser’s developer view.
Always approach extensions with caution. Extensions can cause weird bugs in the editor and in some cases break things.
Indeed. I use the Responsive Viewer extension on tabs where I’m previewing the app without the debugger enabled.
Create a sandbox page with examples and other info that are helpful to reference while developing. For instance:
Put each section in a collapsible group to keep the page manageable. For instance, each section comprises a group that contains a checkbox that toggles showing/hiding another group within the group.
To make it easy and quick to add a new section when you need to test or document something, keep a “next section” group at the end of the page that can duplicate whenever you need a new group.
Exclude the page from general access with a Page is loaded event that redirects when Isn't live version is no
.
Create a folder of backend workflows that are helpful in the development process. For instance:
These are all really interesting tips.
I’m wondering about the preloading of repeating groups when you have a SPA.
It seems the dynamics might be different?
Anyway, I’m going to study it more.
Thanks everyone.
Do you mean having hidden repeating groups loading data when page is loaded?
This thread already has all sorts of little gems
Bubble is so often a solo-venture that you rarely get to see how other people do things and can end up stuck in your own little world and miss something that’s completely obvious to someone else.
Here’s another one from me. Stuck with slow data loading, or want better empty states?
Create a skeleton reuseable element.
Whenever you want to use it, place it next to the text/group you want to be skeletoned (skeleted? skeletated?).
Add a simple condition on the data group that hides it when empty:
Add a condition referencing the data group on the skeleton reuseable to make it visible:
You can set the size of the RE outside of the RE to fit whereever you’re using it.
Why a reusable element, rather than a shape element or something else?
This is often much nicer than using placeholder text, or making the content entirely empty - see on the right card in this video where the user builds their profile.
Bonus points if you recognise the design
Mind elaborating with an example? I rarely use ‘unhandled error’ action itself. Maybe your way of combining will prompt me use it more.
What does that mean?
In reusable header have a trigger of when unhandled error occurs, put an action to show an alert with the unhandled errors code and/or message.
Make the formatting options such that you can not see the element…think white with 0% opacity