It’s a small tweak that is broken
Absolutely agree. What are weekends for ? No confederation has been taken here about working code using Toggle operator… Has Bubble similar now removed Toggle from the user manual ?? this is simply irresponsible
Any chance this update is having more ramifications? In our case, we can´t display data read from APIs.
Our app was working fine Friday, even yesterday. Today we made a couple of changes when we started to notice the problems. We rolled it back to yesterday’s version and Friday’s version (when the app was running fine), but we have the same problem.
In the screenshot below you can see how the text with red background should display a text received from an api call, but for some reasons it is not been rendered…
@santanahugo752 Unlikely to be from this update, though it’s possible you’re running into something else – would you mind submitting a bug report? Thanks in advance!
@dbyrne Again – sorry for the inconvenience! Your runmode shouldn’t be affected, and @w.fly’s fix is a great option for this. Toggle has been removed only for Group Focus elements, since its behavior was incongruent with the Toggle action for all other elements; everything else should still work as expected.
I can run App in Dev with the “Error” I need to deploy and I don’t have the time for this mess.
Help please
I would like to go to run mode. but I’m not allowed to deploy due to these so called errors. It is really quite unacceptable what Bubble got up to over the weekend , re-writing the user manual in effect
I’s Bubble playing " my way or the highway " and never mind the users
Well this event has been recorded.
and what if you actually want to Toggle from the last Show/Hide state ???
The @w.fly is a half fix / half broken as it leaves dropdowns in an open state… that’s why you have Toggle… it will have do for now I don’t have the time to be messing with this and suffer the consequences of bad UX as a result
Not as simple as a toggle but this was my fix…
- When icon is clicked > show GroupFocus
- Duplicate the icon you click to show the GroupFocus > Add condition “when GroupFocus is visible this icon is visible”
- On the duplicated icon > Hide GroupFocus
2 Likes
Actually that’s a really good point - It’s kinda forced a “2 step” approach instead of just putting a Toggle.
which is why we have Toggle in the first place
1 Like
I can see the frustration now - My icons now require 2 workflows to show/hide a group focus IF someone clicks that icon again (Let’s say I have an icon that you click to show a menu… then if you click the icon again, it hides the menu). Yes @aless clicking anywhere away from the group focus hides it automatically… but, if you want to use the same icon to hide the group focus, I’ve gotta setup a conditional to handle it.
Anybody have any examples of where “toggle” was confusing them? Perhaps I’m in the minority, but it has always made sense to me.
3 Likes
Hopefully this helps someone here. This was my solution to the toggle problem…
- When icon is clicked > show GroupFocus
- Duplicate the icon you clicked to show the GroupFocus > Add condition “when GroupFocus is visible this icon is visible”
- On the duplicated icon click > Hide GroupFocus
2 Likes
I’m sorry to say that the removal of Toggle as was , is generating so much trouble . We have a lot of dependency on perferctly working code that uses Toggle which frankly has been Vandalised by your “improvement” … Can you not tamper with what worked ?
Now I’m being held hostage by 5 of these toggle errors in a highly critical component ( reusable plugin ) …
You could have left “Toggle” alone and if you wanted add a new Toggle2 or something … that at least would have made some sense and left legacy code alone
Would it be possible to open up custom events to visual elements(maybe specifically the group focus in this instance if all elements would be too much), sort of how you can pass a thing into a custom event? It could even work by creating a new custom event just for elements and then in the custom element event, you can do a two-step toggle. Maybe a plugin could also do the job. This way all you’d have to do is create the custom event once, and pass elements to it when needed.
I have to agree with the others. I strongly advice Bubble to restore Toggle in a Focus Group, toggle make it way easier.
The update doesn’t make sense to be honest.
5 Likes
Hi again everyone,
we have been following this closely, and given the response here, relative to the overall minor consistency win, we have decided to revert this change, and to allow Toggling Group Focus elements from a click again.
Several notes about why we went with this revert:
- We had misjudged how broken this was in the first place: while we always saw this behavior to be broken in our tests, it turns out that under some circumstances, it was indeed working properly - I believe this depends on the implementation, and on the browser, because this is a more complex race condition than just “Group Focus hides before workflows run, so Toggle is broken”. Because this type of interaction makes sense from a UX standpoint, and because some people experienced it to not be broken (including us in a few places in the our own Bubble website when we built them), there was a much higher use of this feature than we expected, and this change affected many more people than we would have been comfortable pushing a silent breaking change for.
- While we expected this to only apply to new action creations, this also showed up in the issue checker and blocked deploys for what was essentially a mere recommendation, therefore this was a much larger breaking change than the tiny deprecation we thought it would be.
At this point we still recommend against using this action, under these circumstances, since it will look glitchy at the moment in some browsers - Group Focus elements will blink for a fraction of a second, then open again, instead of closing, when you toggle them closed.
Instead, the Two-step Show/Hide action set-up with conditions, which we have seen as a workaround, while less compact, should work much more reliably.
We are planning to tackle this as bug down the line, but it is a bit trickier to solve, because it relies on poorly defined behavior of what “should” run first between workflows and real-time page interactions.
We are also considering adding another level of issues that aren’t blocking - essentially warnings - to recommend against a particular pattern, while not preventing from deploying apps. This would have made this and other updates much smoother overall, so once we do this, smaller UX consolidations will be much less annoying to all users.
I hope that this sheds some light onto why we made the initial change, and why we ended up backtracking on it.
Sorry for the disruption, and happy building,
Best,
8 Likes