In the Progressive Web App there are situations where you want to enable your visitors to interact with the application and do things that require tracking data before you force them to create an account.
How in this situation are you managing the state of the application for that user before he/she is logged in? I ended up using @karimoo’s dummy user trick proposed here which works but has the undesirable side effect of creating a dummy user record for every anonymous visitor to the homepage of the application. This ends up yielding a haystack of 95% garbage records in the User collection.
I looked into doing a periodic purge of any dummy user records on the User collection but that then has its own negative consequence which I learned later which is that the app then hangs indefinitely on the redirect screen for anyone who had previously visited anonymously but subsequently had their dummy user record deleted. They would have to clear their cookies to regain access to the app.
Just curious how others are handling this issue. AFAIK there is no such thing as session or client variables one can set to manage user actions & preferences prior to them becoming a registered user. Has anyone solved this in a more elegant way than the dummy user approach or are you just accepting that the User collection will always be 95% cruft? thanks
Very good question. In my experience, I practice the following:
try to sign-up “pseudo-user” as late as possible. E.g. for the services bookings type of app, I try to allow non-logged-in users view the main page, service catalog, product details, info pages. And create the pseudo-user account only when user tries to make the booking. The same logic applies to ecommerce apps (create a user only when he/she adds the product to cart).
This reduces the quantity of these dummy accounts.
I try to be sure that I convert the user to “real” one whenever possible. Taking the same example of booking app - I suggest to sign up upon booking finish, I also suggest to sign up on the main screen if I see that this user is “pseudo-user” (“Don’t lose your data!”), in some other places if appropriate.
Interesting to know why your app hangs if dummy user is deleted. I’ve never observed such experience. Would be curious to know how is it possible to replicate such behaviour (and therefore to think how to protect against it).
Would love to discover what other Adalo builders think!
So there’s no way you’re aware of to facilitate the experience of adding products to a cart and deferring account creation until the point of checkout?
Yes that’s exactly what I’m doing now. My account creation form actually doesn’t create anything- it updates the temp user to give them a real email address. That unfortunately doesn’t solve the problem of a bunch of cruft dummy users in the db though unless I’m missing something.
Very curious to hear how others handle this challenge. I try to let visitors become invested in the app prior to gating functionality behind an account creation form and I don’t see an elegant way to accomplish maintaining state with anonymous users in a way that doesn’t inject a bunch of dummy accounts in the db.
Presumably it’s because they’re cookied with their dummy userID and the redirect page senses that but fails to find their User record when it’s trying to redirect to the home screen that requires data stored in their user record. I will film a Loom video to reproduce this and append here.
Once I’ve experimented with “Session variables” collection and tried to put the data there… but it ended up in so much hassle, pseudo-users turned out to be much better solution.
When you add a product to cart, you somehow must (a) have a cart and (b) have cartitems linked to this cart. And the cart itself should be somehow attributed to an exact user who is adding products in this app.
As a crazy idea - you can have a screen with inputs, store the cart ID in one of them, and then use the value from this input to manage the cart… but anyway you will have to manage the “orphaned carts”. And you will have to build 2 versions of cart management (one with users, another with inputs). As for me, pseudo-users is easier solution.
Thanks!
This behaviour is weird. I’ve created a sample app, and tried to do similar things (not with automatic redirect, but with manual one). In my case after I delete the guest user, the app still takes me to the home screen (which is I guess expected), but also allows to update the Full Name and displays it (of nonexistent user!!).
I guess this is somehow related to browser storage, which is, in my opinion, is not correctly used by Adalo in this particular case.
@Victor Thanks for taking the time to record this demo. I just got the chance to go through the whole thing. Unfortunately force logging out all visitors on every session is not desirable UX for us. The idea is to allow them to interact with the app and do things that necessitate maintaining state as an anonymous user. If/when they finally decide to apply to a project we put them through the account creation process which is really just renaming their dummy user and giving it a real email address.
I think ultimately this means we will need to keep all dummy records in the user table as they contain state information for those anonymous users. Ideally the system would be resilient enough to not hang in the event that a user record has been deleted. I’ll keep messing with it to see if there’s some conditional logic that can handle this exception and not cause the whole app to hang in this case. Thanks again for your help. Seems like a useful workaround if you’re willing to accept that everyone is auto-logged out between sessions.
