I am having an issue with visuals in the log-out flow of a user. I have recreated the issue in a basic example below to best explain my problem:
In this basic example, there is one user in the database, and in the video below the user has already logged in. My problem comes when the user wants to log out.
My page has two containers, a blue container and a red container:
The blue container is set to be invisible on page load, but visible when the first record in the database (in this simple example, the only record) matches the current user.
The red container is set to be visible on page load, but invisible when the current user is logged out.
Now, by logical reasoning, these two containers should disappear at the same time; the moment the user is logged out:
The blue containerâs database search should no longer match current user, because the current user is logged out.
The red containerâs should set to invisible, because the user is logged out.
However, this is not what happens. As shown in the video, the blue container disappears moments before the red container. This does not affect functionality or the user flow, but it is quite the eye sore in my application, where the UI is a bit more complicated than this.
As stated before, I am open to the idea that this could be to do with the fact that the condition on the blue container is reading something from the database, however it does then confuse me that the blue container actually disappears before the red container, and not after.
Any help or suggestion would be greatly appreciated.
Make both containers set to not be visible on page load by ensuring the âis visible on page loadâ checkbox is unchecked.
Then set the conditional on each container for âwhen they should be visibleâ.
So this means, the Red Container is not visible on page load and has a condition set to âwhen user is logged inâ and the property to change is this element is visible.
The blue container is set to not be visible on page load and put a condition for âwhen current user is logged in and the record matches the current userââŚadditionally, since you likely are using a search in your condition, you need to change that since the evaluation will take timeâŚso put onto the page somewhere a group and have the datasource be the search of the records and reference that group in your condition on the blue container.
If you do that, Iâd imagine the containers will not be visible are the same time.
Thank you for the response! I tried your suggestion of making the red container invisible on page load, and visible when the user is logged in, so that both containers are not visible on page load. Unfortunately, the error still persists.
I also implemented your second point by having the container that holds both blue and red use the database search for the first user as its data source, and then referenced this with âparent groupâs user is current userâ in the conditional for the blue container. Again, unfortunately, the issue is still there.
What I find really curious is the fact that the blue container disappears first. The red container is explicitly set to disappear as soon as the user is no longer logged in, and yet the blue one disappears before that. I am struggling to understand how the blue containerâs conditional is being evaluated before the user is even logged out, as that log out action is the only action that should trigger a change to the conditional statement of the blue container.
I added two text fields to the screen to display the email of the current user, as well as the email of the user that was returned by the search.
Theoretically, the moment the blue container disappears should be the moment that these two emails become different, because the blue container is literally set to be visible only if the current user equals the searched user.
However, having set this up, we can observe that the blue container actually disappears even when both emails still reflect as being the exact same:
Yes, add to the condition on blue container that user is logged in. I had suggested that originally and based on your current description it seems that was overlooked.
@boston85719 apologies I forgot to reply to that part.
I did implement this and it also did not change things. This relates also to the fact that the blue container is disappearing before the red container as I mentioned. It seems there is something that is being evaluated on the blue container before the âuser is logged inâ condition becomes false, so the âand user is logged inâ statement that I added had no effect.
For the sake of simplicity I am going to refer to two users here:
Current user: the âCurrent userâ object that you have access to through bubble.
Database user: A user record in the database that is being fetched manually through a search.
Basically it seems that when the action of logging the current user out is triggered, something weird happens so that the current user object loses its equivalence to the database user it was logged in as before the current user is actually considered logged out.
However, you can still use the fields of the current user to check for equivalence. When I set the condition to check if the database userâs unique id was equal to that of the current user, things work just fine and are evaluated as they should be - no more buggy UI.
You might think that this could cause issues where the current userâs unique ID equals the database userâs unique ID even after the user has logged out, but this does not happen! Bubble automatically recognises when the current user is logged out, and the unique IDs no longer evaluate as equivalent.
So essentially, when a user logs out,
User logs out
Current user object no longer evaluates as equivalent to its database counterpart, but âCurrent user is logged inâ still evaluates to true.
Small delay
âCurrent user is logged inâ evaluates to false.
So essentially if there is a chance of the current user logging out when your page is using conditional statements to show things on the condition that the current user equals a database user, avoid using the current user object itself, but rather compare the unique IDâs of the two objects.
This delay can cause annoying issues in the UI and I am not sure if it is something that would be considered a bug. What do you think @boston85719?
Itâll be easier to just get the page to refresh when a user is logged out. Instead of whatever you suggested.
I donât see any commonly used scenario where an app user will need to have a âlogged outâ environment when they were already logged in. Most apps will redirect users or refresh the page when a user logs out.
Bubble evaluates conditions one step at a time, so if the conditional statement is âcurrent user is logged out or current user is not user on groupâ then the first evaluation of user is logged out will evaluate to true and the condition is matched so no further evaluation is necessary.
If the condition is âcurrent user is logged out and current user is not user on groupâ then both conditions need to be evaluated, which means the first portion is evaluated and if it is not met, then no further evaluation required, but if it is met, then the second component needs to be evaluated.
That should not be the case. What it does it evaluates to null basically, so Bubble has overlooked something here.
When using the expression current user is logged in and display this in a text element, the evaluation when true will show as yes, but when the evaluation is not true, it does not show noâŚsince that evaluation is just looking to determine if they are logged in. See below screen shots
When you add to the text dynamic expression formatted as text, then when it evaluates to no it will show what is in the no field. See below.
Unique ID of a user that is not logged in can not be found in database as that user doesnât really exist, so that can work for some things.
Not really a bug since the conditions are not the same and one has two steps that might need to be evaluated compared to just one.
If you change the order of the condition with two steps to have the first step be the same as the condition of the other container with just one step (ie: user is logged out) then they should evaluate at the same time.
No worries, glad it worked. There are other nuances to conditionals as well. The order when on an element if there are multiple conditionals, they are evaluated from bottom up.
In the above, the input isnât valid will be evaluated prior to this input is valid. The example is simplistic but in practice if you have two conditionals that become conflicting and both are getting met, but the wrong one is utilized for your use case, moving the order around can help and may help avoid a need to add to the conditional statements.
And as mentioned the order of the dynamic expression matters as well as those are evaluated from left to right.
