Accessing current url in server side actions

Plugin builders
1

Hey forums,

I am new with Node.js or with server side code, I was wondering if its possible to access url query parameters from a server side action.

Example “https://example/domain?value=1”

I am building a plugin, I need to get the current browser URL dynamically. I’ve been breaking my head over this all day your help would be very appreciated!

2

Just configure that as one of the fields the Bubble programmer has to send. There’s no other way to get that info.

2 Likes
4

@jonah.deleseleuc: Keep in mind that Server Side Action plugins may be executed in the context of a page, or in a backend workflow where there is no “page” context.

I can see there are cases where we might wish that the plugin’s context object included additional info, but at the moment, it’s just:

context = {
     currentUser: {
         get: function(fieldName: String) - returns the value of a field for the object
         listProperties: function() - returns an array of the different fields you can access 
     }
     userTimezone: (String) The tz database name of the timezone that the request was made in (e.g. America/New_York), or UTC if no timezone information was provided
     request: call request with a node request function, returns the response synchronously
     async: call context.async with a function that kicks off an asynchronous operation, 
         taking a callback taking (err, res). Returns res or else throws error.
     keys: Object with Keys defined in the Plugins Tab
}

So, the workaround at the moment, is to give your SSA a string field for current URL and in its documentation, just tell the user they should set it to This url.

I can see that in some cases it might be nice to get this as part of the context object, and it would be reasonable to file a bug report / request for enhancement asking they add window.location.href as a context value.

3 Likes
5

Snooping on the network requests, it looks like the current page URL is sent in the x-bubble-r header, so all they’d have to do is expose this as another value one could get off of context.

1 Like
7

You’d do better then to nag Bubble about making objects available client side. This is a stupid limitation that isn’t really worth working around in this way, IMO.

1 Like
8

I mean, all you want to do is define some object (a Thing) and then be able to make objects of that type in the page. It’s just broken the way it is now.

1 Like
9

This is absolutely something we need to get Bubble to fix. It is one of the most limiting factors for extending Bubble. We should be allowed to define first-class citizen data types that are not tied to any database or API call. The API hack is OK but it falls down in many ways very quickly (e.g. action vs data API and needing to define two types of the same object that can’t be interchanged.

Presently, I built a tool to define my own data types (schema) and then loop over the schema to automatically generate any number (e.g. 20+) API calls just to create reusable data types.

3 Likes
10

Exactly, I agree with your points. For future reference, what I want to be easy to accomplish is:

  • Be able to return javascript objects from the client-side similar to the way the API connector works

  • Have more information included in the context. For example, I’d like to get the current page URL. I’d like to avoid having users of my plugin have to give “things” in action fields. It’s not clean and not user-friendly.

  • Have “Result of Step x …” available for client side actions. Why is this not already the case anyways? Seems like you guys just … forgot? :sweat_smile:

11

One thing… if the url doesn’t already have the query parameter I’m looking for, the URL that gets changed after step 1 isn’t given to step 2 … actually, the original URL before the workflow gets initiated is used… is this an issue with async timing or is this just how it is?

12

Okay, so the answer @keith suggested unfortunately doesn’t work. Adding a field and populating it with “This Url” is not effective. Steps & the issue:

  1. Set query parameter with a client side action (step 1 in workflow)
  2. Read url from properties.current_url inside server action (step 2 in workflow)
  3. The url that is given to the server side action is the url from before the workflow started … the query parameter does not exist. When you refresh the page, it works.

But not the first time :frowning:

13

@jonah.deleseleuc , the values of an action plugin’s inputs are evaluated precisely at the moment you call that action. They are evaluated and passed to your plugin’s action code via the properties object. (Similarly, in the case of an element plugin, any field values for an action are evaluated at the moment that Element Action is triggered and passed to the defined action code, again as a properties object.)

After that, they cannot change, of course.

So if you fire an SSA in the page and you pass the value of the current URL, the SSA will then do its thing (whatever that thing is). If you subsequently change the page URL, that server side process knows nothing of that.

That’s not a Bubble limitation, that’s just how functions work.

1 Like