Bringing Object-Oriented Programing (OOP) to Bubble

7 min readNov 17, 2022

With Bubble, anyone can build their own idea without needing to know how to code. But building an app is not just about coding or assembling Workflow actions. It’s also about designing the information management system, i.e. the algorithms and rules to manage data and app behavior.

These processes obey rules. With code, it’s a language, lines of code, a shared and sharing storage system, SQL, etc. With Bubble, it’s workflows, database, graphical elements, plugins, etc., each with their own rules.

For 30+ years of experience as a developer, i’ve used a set of rules widely used in the coding world called Object-Oriented Programing (OOP). And i think it’s possible to use that paradigm in Bubble to design the management of your application behavior.

But first, let me quickly define what Object-Oriented Programing paradigm is.

What is Object-Oriented Programming ?

Object-Oriented Programming (OOP) is a programming paradigm that uses “objects” — data structures consisting of data fields and methods together with their interactions — to design applications and computer programs.

Designing an object-oriented program involves creating a blueprint for the program called a class. A class defines the properties and behavior of an object. Once a class has been created, you can create objects that belong to that class.

OOP is a popular programming paradigm because it helps to model real-world objects. For example, you can create a class called “Car” that would have properties like “color” and “number of wheels.” You could also create methods for the class “Car” that would describe its behavior, like “Move(Forward or Backwards)” or “ Start().” And finally, you could also create events for the class “Car” that would notify about (un-)expected things happening during its processes.

Principles of object-oriented programming

There are four main principles of object-oriented programming:

1. Encapsulation

Encapsulation is the process of hiding the implementation details of a class from the outside world. By hiding the implementation details, you can prevent users of the class from accidentally changing the internals of the object, which could lead to unexpected behavior.

In the above example of the Class of a Car, you don’t need to know all the pieces and processes that are needed to “Brake()”.

2. Abstraction

Abstraction is the process of hiding the complexity of a class from the outside world. By abstracting the complexity, you can make the class easier to use and understand.

In the above example, if you want your Car to slow down, you just have to “Brake()”

3. Inheritance

Inheritance is the process of creating a new class from an existing class. The new class inherits the properties and behavior of the existing class. Inheritance is a powerful tool that can help you to reuse code and to create relationships between classes.

In the above example, we could have Car as primary Class. Then we could create the Classes Minivan, Sport car, SUV, … that would inherit all the characteristics & features from the Car Class and have their own ones.

4. Polymorphism

Polymorphism is the process of using the same interface for different classes. Polymorphism allows you to write code that is more flexible and extensible.

From the above example, we could use the same ‘properties’ and ‘methods’ applied to truck, motorbike, trains, tractors, …

What is possible to bring from OOP into Bubble ?

The basics exist already

Now, if you consider Bubble context, you can find back some of the definitions mentioned above :

(nocode dev defined) Objects ≍ Reusable elements
Properties ≍ Custom States
Methods ≍ Actions
Events ≍ Events

When you’re building an app with bubble, you’re also manipulating data through those features :

Datatypes, also called Tables
Record, an element/row from a table
CRUD functions : Create, Retrieve, Update and Delete records/data
Workflows : actions and transformations applied to information (parameters, custom states, records, …)

Sometimes, when those data manipulations can become very complex : inserting a new record means also inserting various records into other tables, calling some specific APIs, depending on values in the new record.

And, to add to this complexity, you may have to repeat this in different pages or reusable elements. Most of the times, you can use Backend Workflows and/or Triggers.

With time, those Backend Workflows may become very rich, complex, interacting with Triggers. Plus the fact that you may need to share all the manipulations and processes between frontend and backend, sometimes with the complexity of going back and forth between the frontend and the backend.

Bringing Encapsulation and Abstraction to Bubble

After getting lost in this data manipulation labyrinth built little by little, iteration after iteration, improvement after improvement, i’ve decided to use that OOP paradigm to build the management of my apps behavior.

First, I postulated that a Datatype would be managed by a Reusable Element and only by that. It means that i decided to centralize in one object quite all the manipulations of a specific datatype.

For example, for my Users, i’ve created a Reusable Element called

Object — User

For this Object-User, i’ve created a first Custom state :

Object-User -> csActualUser (Datatype : User)

It is the reference to the actual user manipulated by Object-User.

(not to be confused with Current User)

Then, i create 4 Custom Events :

Object-User -> cwCreate
Object-User -> cwUpdate
Object-User -> cwRetrieve
Object-User -> cwDelete

The purpose of each Workflow is obvious. But i have to specify few points :

cwCreate and cwUpdate, as events, can have parameters. Thos parameters are used to transmit all the needed datas
cwRetrieve use one parameter (the email address) and sets the csActualUser to the found user, if it exists, or to nothing (empty) if it doesn’t

There’re several interesting ideas in doing that way :

Wherever you have to manage Users, you just have to drop the Object-User Reusable Element onto your page, other reusable elements, … and call “Trigger a custom event from a reusable element” action to use your defined custom events.

If you want to edit your user’s data/profile, you can create a popup (popupEditUser) in theObject-User reusable element. You can then create a Custom Event EditUser, with one parameter (email address) that will do the following :
- cwRetrieve the User
- show the popup with the retrieved User
And the “Save” button on the popup will use the cwUpdate event to update the user data
You can still use Backend Workflows to manage complex User management processes. But all of them are hidden within one interface Object-User.

You can use the very same pattern when you have a main entity and sub one.

For example : “Quote” Datatype and “Quote Lines” datatype

Object-Quote ->cwCreate (creates a new quote with parameters)
Object-Quote ->cwCreateLine (creates a new line and sets, for example, a custom state with the latest created line)
Object-Quote ->cwDelete (in this particular case, this custom event will also delete all the related lines in the “Quote Lines” datatype)

Proceeding this way, which may seem to be restrictive and painful, let me know what is the main place where all my data manipulation comes from and hide all the complexity of the processes and “tips and tricks” that are used. Working this way also allows me to reduce my technical debt, sometimes forgetting in the depth of my application a place where a the very data is also managed.

What is actually missing in Reusable Elements

Though, in order to have some kind of a completion with bringing OOP to Bubble, today, one thing is missing when defining Reusable Elements in Bubble.

We have seen that :

with custom states, we’re able to create Object Properties.
with custom events, we’re able to create Object Methods.

Those two are accessible within an page where you have dropped your reusable element.

But it lacks the ability to create Objects Events, that may be called Reusable Triggers, that could be triggered from a Reusable Element Workflow (Custom Event, or Clicked Button Event, or whatever event), and that would be triggered within the page (or other reusable element) where your reusable element is dropped.

Creating a Public Trigger in the reusable element

Defining the Public Trigger in the reusable element

With this only feature, it would open such new opportunities !

To name a few :

Sending data from a reusable element to its parent container (page or other reusable element) without knowing what is the container
To extend the possibilities to create plugins to non coder Bubble devs (ie visual elements without a line of js code)

Bringing Object-Oriented Programing paradigm (part of it) to Bubble is at hand with a “small” new feature added to Reusable Elements building : the ability to trigger its own “public” triggers.