I’m looking for a way to read some information about the “current user” through JavaScript (not through a Plugin).
Is it even possible?
I need it for analytics.
Like what? What are you looking for?
First name, last name, email, and other user-related properties.
If not in a plugin, where is this javascript, and what are you trying to do with the information after you read it?
The JS is a global app-wide script. It loads an analytics tool.
The goal is to read user information (identity, etc.) and send them to the analytics tool.
I found something similar to what I want to build with a MixPanel Plugin.
I basically want to do something similar, but without using a Plugin.
I’m not sure how to do this without a plugin. I’m curious, why do you want to avoid using a plugin?
I know you can go to Settings-> SEO / metatags to add scripts in the body and header. I’ve added Google analytics this way. But that script can’t just get User info.
Here’s a sort of shot in the dark at what you might try. It still requires a plugin, but not one that you have to build:
Get the Toolbox plugin that allows you to run javascript in workflow actions.
Write your sitewide script that includes functions that will take arguments for user info and pass it to your destination (like Mixpanel or whatever).
In a workflow, us a Toolbox javascript action to call those functions and pass in the arguments for the current user.
This may be BS and lead to dead ends or security issues but it’s the only way I can think of without building a plugin. I mean, this kind of thing is why plugins exist.
1 Like
Thanks for the workaround, it’s interesting.
Well, other no-code tools don’t necessarily have a plugin ecosystem (most don’t) and it’s perfectly fine/safe to do without it. I usually write the code directly (I did it for MixPanel, GA, PostHog, etc.)
I was also thinking of using a Plugin that would make the user’s info available in JavaScript. I’m just not sure how to do that.
So, for integrations with things like chat systems or other add-ons where you want to identify the user (and possibly send other data about the user to the system), there’s usually some interface you can call and, if you’re just sending strings, you can do that with Run JavaScript (what Run JavaScript does is just eval() the contents of the script textbox). And you can send simple string data by just enclosing expressions you construct in the expression builder with whatever quotes are approriate.
As an example, I use Freshchat on one of my sites and, when we can identify the user (the user is logged in) I can send info about that user (including their unique ID within Bubble), whether they are a subscriber or not, etc. And I do that in a reusable (the footer) that appears on every page in my site. Like so:
Whatever service you are integrating with might have this sort of approach or it might have webhooks/API endpoints. In that case, send whatever info via the API connector in the usual way.
If for some reason you need or want to get parameters from Current User in your own JavaScript the only other way to do that is by building a plugin. In the client-side plugin APIs, Current User is available like any other Thing via the context object as context.currentUser which is itself an object with the listProperties() and get() methods on it, which can be used to retrieve the values of various properties, just like on any other Bubble Thing.
(A complete discussion of plugin building is, of course, beyond the scope of this reply.)
1 Like
Thanks for this, it helps.
I feel like I’m working with both hands on my back but I guess I’ll end up with something that works, eventually…
I managed to do it using a Plugin, as you said.
The plugin is essentially a single 1px by 1px element, with an initialize function, and it was added in a reusable Footer component.
Is there a more elegant solution?
What I would like, ideally, is the ability to set a whitelist and blacklist (in the Plugin config), to allow/disallow a list of user properties, in order not to make all properties available.
I’m not sure if tat would play well with what I just did, though.
Well presumably you already know what you want so only get those props you’re interested in. You already know their names.
You can’t exactly build the interface you want in Fields (try it and you’ll see), so you could just have a long text input there where you specify the internal field names that you’re interested in. Note that you don’t get those field values sent to you in initialize, they become available to you in the update function (which runs immediately after initialize) via the properties object.
Given the above, I’d just hardcode the values you’re interested in, e.g.,
if (["email", "_id", "name_text"].includes(prop)) userProperties[prop] = context.currentUser.get(prop)
Edit: unique ID field is _id
1 Like
Yeah, I could do it this way. (I was trying to design a plugin that would work for several customers, but that might be harder to achieve)
Unfortunately, what I did doesn’t always work. It seems to work fine when the user is not logged in, but I believe it’s because the plugin initialize is fast in this case.
When the user is logged in, I get not ready error thrown. I understand it’s related to Loading Data - Bubble Docs, but I’m not sure what I can do about it.
Here is the code I’m using, I believe the get() call in a loop is typically what takes too much time to process and runs into the “not ready” error. But I don’t really understand Bubble’s logic behind asyc calls, despite being really familiar with such concepts.
function (instance, context) {
const userProperties = {};
//console.log('CS context', context)
let props = context.currentUser.listProperties();
//console.log('props', props);
props.map((prop, index) => {
let value = context.currentUser.get(prop)
userProperties[prop] = value;
})
console.log('__BUBBLE_CURRENT_USER', userProperties)
window.__BUBBLE_CURRENT_USER = userProperties;
window.dispatchEvent(new Event('UPDATE_BUBBLE_CURRENT_USER'));
}
What data do you have on the user?
Using bubble methods inside callbacks can bring unexpected behaviour. Instead of map over props try a for statement to remove the callback and see if this is what is causing the error.
Keep in mind that lists and references to other data in the database will be objects with other methods to get the actual data, so your value is not always what you are probably expecting.
Yeah, well you can create the “identify user” part as an Action in the element plugin (the interface for that Action - its fields - will allow you to build an interface that lets the programmer user select some fields on the User object, unlike in the fields interface for the update routine). Again, a complete tutorial on this is beyond the scope of this reply.
And then, in use, the Initialize and Update routines just initialize your element and, upon receiving an “initialized” event, they can execute the Action in a workflow.
If you’d like to understand more about this concept, you could watch some of the videos about my Floppy plugin. For an example of throwing an “initialized/updated” event you could inspect/fork my open source Fielder plugin. (Though Fielder does not have any element Actions.)