Building Actions
Last updated
Last updated
Building actions is quite similar to building elements. You add them to your plugin and test them in a similar manner, using a test app.
Two types of actions can be built: they can be client-side or server-side.
Client-side actions are useful for page interactions, or send some data to analytics, convert a credit card into a token using a library, etc.
Server-side actions can be used to make custom calls to external services, run a matching algorithm, compute an advanced computation, etc. These actions can return some data that can be used in subsequent actions.
Note: Server-side plugin actions encode files using base64, which increases file size by approximately 1.25x, so try to avoid passing files that are larger than 5MBs through server-side plugin actions. File URLs are a good alternative to use instead of file inputs.
Note: Option Sets cannot be retrieved via server-side actions. Client-side, Option Sets will be represented as { listProperties, get } objects (where listProperties lists all the fields on the Option, and get('field') gets the value of 'field' on that option set.
Note: When writing server-side actions, avoid using async/await syntax to wait for promises. The framework we use to to handle asynchronous code (notably used in context.async or context.request) relies on a special library called "Fibers", which works very differently from usual promises and will cause unexpected behavior if async/await is used. Consider using the traditional Promise.then/catch syntax instead, which is supported by Fibers.
Similarly to elements, you have to define the different fields, and then use these values in your code in the properties object. Please refer to the previous section for the different options you have access to when adding fields to an element or action.
The core of the action is the function that gets executed when a workflow hits this action. This function will be called with the properties and the context object. You can see the contextual documentation in the editor for the different objects.
Note that similarly to element functions, you should take into account that your code may be run more than once to fetch data, it is therefore recommended to always load data at the beginning of your functions, prior to modifying any state external to the function. See the next section for more information.
Here is for instance how an action that sends data to Facebook Pixel looks like.
Functionality of server side actions can be extended by the use of node modules. To do so, select "This action uses node modules", and paste in your package.json into the box that appears below. Modules may also be listed by hand; only the "dependencies" section is used. Require your modules inside your function as you would in any other situation.
When your list of modules has been added or updated, Bubble will need to build a deployment package, which will be used to run your action. This process may take up to a few minutes, and can be started by clicking the link that will appear below the box.
