I am developing a feature in my Bubble.io application that allows users to select a specific skill and then view detailed information about that skill on a separate page. While the setup works perfectly for logged-in users, I encounter issues with maintaining the selected skill’s context through the login process for users who are not logged in. I would appreciate any guidance or suggestions from the community to resolve this issue.
Overview of the Process:
Skill Selection: Users click on a “Learn” button associated with a skill, each identified by a unique ID.
User Authentication: If not logged in, the user is prompted to sign in through a popup.
Post-Login Redirection: Users should be redirected to a details page specific to the skill they selected, with the content dynamically populated based on the skill ID.
Current Setup:
Skill Buttons (for logged-in users): When a logged-in user clicks “Learn”, the skill_id parameter (e.g., Parent group's skill's unique ID) is passed directly to the skill detail page and everything functions as expected—the page correctly displays the skill-specific content.
Custom State for Not Logged-In Users: For users not logged in, the skill_id is saved to a custom state named skillid22 on the sign-in popup. Post-login, the workflow is supposed to pass this skill_id to the skill detail page.
Sign-In Workflow: The workflow for the sign-in button includes redirecting to the skill detail page, passing the skill_id from skillid22 as a URL parameter.
Problem: While the functionality works flawlessly when a user is already logged in, I face challenges with users who need to log in. Specifically, after signing in, users are redirected to the skill detail page, but it fails to display the dynamic content based on the skill ID set during the pre-login phase.
Attempts to Resolve:
I have confirmed the proper setting and retention of skillid22 before and after the login popup is displayed.
The order of workflow actions has been scrutinized to ensure no refresh or redirection occurs that might reset the custom state before it’s used.
The skill detail page is configured to use the skill_id parameter for dynamically setting content.
Could anyone provide insights into what might be going wrong or suggest what else I should check or adjust? Your help would be greatly appreciated as I aim to ensure a seamless user experience regardless of login status.
Quick update on my issue: I’ve pinpointed that the user sign-up action is resetting the custom state (skillid22) which holds the skill ID. This happens after new users complete their registration, leading to the loss of the skill ID before they are redirected to the details page.
Request for Advice:
How can I maintain the custom state throughout the signup process?
Are there alternative methods to pass data that might avoid this reset?
Appreciate any insights or recommendations you might have!
No need to use cookies or local storage and certainly not a plugin. Instead use URL parameters which can be sent to any pages and survive page refresh. Look around this forum for any discussions on how to implement it…
Local storage is harder to update (and slower), has potential legal / permissions issues and has other issues and inconsistencies and in Bubble typically requires a plugin. Meanwhile it has no apparent pros over URL parameters
Okay if you really want to debate about this I’d suggest starting a DM. LocalStorage is not slow at all, and for his use case once again, a good reason to use it.
As a post described in SA:
Apples to apples
There is not much value in comparing localStorage to object storage, the two have different purposes in JavaScript. It is likely that you will only need to touch localStorage a few times in your app and the rest of the work will be done in memory.
Local Storage vs Cookies
A better comparison against localStorage would be that of its classic counterpart, document.cookie. Both localStorage and document.cookie’s main purpose is to persist a value across browser refreshes.
As far as operations go… sure you need a plugin (though it should be native with Bubble itself), but it’s not very hard to implement. I use localStorage on almost all my applications.
States are faster, cause it’s built within your application, so that itself is out of question, but in terms of speeds, reliability, and user-facing data, (persistent data) Cookies and localStorage wins. Sure you may need to add some additional practices to ensure privacy and let the customer know you’re storing data on their behalf, but otherwise it’s a good option. Maybe not in this particular use-case, but a good ultimatum at the least.
This could boil down to over-all opinion, but you have mine.
That’s not nothing. That’s a big issue considering plugin maintenance and loads. A real issue. That has a real impact on page load on every single page of the app (including a landing page if one is brave enough to try to use Bubble to host that).
You must not know HOW MUCH other code (even a 100% vanilla app) runs in the backend, do you?
a simple localStorage.get is not going to cause any issues. With my plugin you Only need to run the plugin on a page you’re reading the data, not when you’re operating on it. If you want to read it across all pages, just make a global floating group reusable with the element inside of it. You now have a global variable (not private of course).
It’s only (ok mostly ) to counteract wrong information being posted.
For example “With my plugin you Only need to run the plugin on a page you’re reading the data, not when you’re operating on it.” indicate a fundamental misunderstanding with how plugins work in Bubble. Once again the plugin is loaded on EVERY SINGLE page whether you read the data or not and whether you’re operating on it or not. The page can have a single line of text and no conditionals or WFs and still will load the plugin…
not necessarely true, it depends on how you create the plugin. you can add shared global code that will be loaded by every page (and sometimes it’s exactly what you need) or you can add actions/elements that are loaded only if used in the page.
) to counteract wrong information being posted.
