When building in Bubble, I’ve found I’m often hamstrung by the inability to leave anything “partly finished”. There’s the essential separation of Prod and Dev, yes, but there’s no equivalent of “branch” vs. “master” (understandable) or even something as basic as “commenting out” a piece of code (curious). I wonder if this latter feature is something that the Bubble team would entertain adding in the near term.
There are cases where I’m working on something, but just can’t quite perfect it, but I need to push other features live. So my only recourse is to “hide” the unfinished element. But that 1) still requires the element has no errors, which block deployment to Live, and 2) negatively impacts performance if the unfinished element uses system resources (like a complicated search).
Anyways, it just occurred to me that adding a feature that’s equivalent to commenting out a line of code – perhaps a checkbox like “Exclude this element from page” (default = unchecked) that basically just puts a around the element in the generated code – may be an easy solution for Bubble to implement, so figured I’d ask. It’d be a huge help.
Anyone else have this problem or thoughts on the proposed solution?
While I think this would be useful for workflows, I am afraid that the goal here is to have a what-you-see-is-what-you-get editor. So by commenting some elements you would break that.
Another nice possibility could be to be able to decide if a page can be published or not (kind of commenting the whole page).
Anyway, I like the idea, it would be very useful for instance if you are developping a new feature that is not finished and you have to push a quick fix for a issue that you just found.
Typically, I’ll either create a sandbox page (which only I can access) or a copy of a page.
if it needs to happen on a current page, you could draw it in a group that isn’t visible on page load. (And collapse elements height when hidden).
When I have a deprecated workflow that I want to keep for reference, I may create a failing “Only when” criteria for the associated workflow. (Which I later remove when ready).
Using @dan1’s suggestion to put a lightweight but guaranteed failing When clause (e.g., User = “xyz”) on a workflow or workflow step is an effective hack to keep a workflow’s definition but ensure it doesn’t run. That doesn’t solve the “commenting out an element” issue, but it helps a bit.
Another idea that came to mind for future implementation. (Will leave it to others to vet if the idea is good or not).
Using the “Folders” concept in Bubble, give each page a dedicated “Disabled Workflows” folder. (Capitalizing on a potential ON/OFF condition logic, if a workflow is set to OFF, then it would appear in the “Disabled Workflows” folder.
Pros: it makes it easier to have a development environment where User A doesn’t inadvertently push User B’s feature before User B is ready. Allows old workflows to be kept for reference while other concepts are in testing.
Con: it enables messiness.
I think you’re right, but I like the simplicity of that approach - perhaps a switch-like widget that can be toggled with a single click, providing a clear visual indication of whether the action is enabled or not. Ideally, there would be a badge on the workflow as well, to indicate one or more of its actions are disabled.
EDIT: And why not allow toggling an entire WF on and off as well.
I generally agree that it shouldn’t be used as a way to permanently disable functionality - i.e. commented code should not be committed to a source repo - and that there’s less of a need to comment code with the availability of source control tools such as Git (and its stashes).
However, given the nature of Bubble development, where all the “logic” isn’t immediately obvious at a glance (much of it being hidden in sub-panels, expandable fields, or otherwise “buried” in the UI, etc.), the ability to quickly disable actions and workflows would streamline the process of experimenting and trying out different approaches/solutions to a given problem.
EDIT: I also wouldn’t leave disabled actions/workflows in a deployed app, but it would be nice functionality to have during development. (Actually, they could probably be automatically stripped when making the app live.)
My version of “commenting out” workflows is simple enough to replicate over and over and has never caused me any issues: append an impossible “When condition is true” to the workflow you want to disable:
If you use the “Get data from page URL” option, you can always enable the workflow by adding ? or & xyz=123 to your address bar URL, for example.
I use the same method. I also use the note feature to mark the intentionally failing conditions. With a native app, it helps to keep one set of notes on the main “stage” group.
I reserve one color for workflows with which I’m currently tinkering. Easy to see, and it feels soooooo good to move WFs to a non-tinkering color.
It would add the Photoshop-layers concept for native and intricate pages.