Reusable Elements should accept multiple data sources

It’s very common to create a custom state on the current page which contains important information.

For example, the page item-details might have the custom state selected-item and discount-code. On that page, you might deploy many reusable elements in order to render important information about the selected item, for example, you might have a “Buy Now” button which when clicked redirects your user to the cart.

You would like to pass the discount-code along with the selected-item to your “Buy Now” button, but you cannot, because the discount code is a custom state on the item-details page, and that property is not accessible inside the reusable element. You could try to pass it in, but you can only pass one object to your reusable element, so you’d have to choose whether to pass the discount or the selected-item.

This massively limits how much you can use reusable elements. You can use a reusable element only when responds to a single piece of information, never multiple pieces. This also has the consequence of making it impractical to nest reusable elements, because if you have element1, which accepts data source A and element 2 which accepts data source B, then if those show up together in a larger component element 3 you can’t pass them both their data, you’ll have to choose just one.

Likely, this was implemented this way in order to prevent users from relying on properties that don’t exist (e.g. what if you put the “Buy Now” button on the all-items page, and that page doesn’t have a discount custom state?

But this could all be easily avoided if Bubble would implement reusable elements that accept multiple data objects instead of just one.

See these related topics as evidence that this is something the community would benefit from:

1 Like

I’m not sure I follow. I’m pretty sure you can access all of your states that you put on the reusable element, between the inner and outer section. Also, you can use url variables which is a great place for something like a discount code.

I hope this helps,

that’s only if the state is on the reusable element. I don’t want to have to create a workflow that adds the custom state to my reusable element every time the page loads and every time the value changes. I just want it accessible.

url variables are great for something like discount codes, they’re terrible for something like a uid which needs to be searched because you’ll have to rerun the search for each element. What you’d prefer to do is perform a single search for the uid to resolve it to an object, and then just pass that object around

Fair, just giving you options. I can’t see this changing.

Why? It’s a simple interface from the user’s perspective, just add an additional button under this that says “add more data sources”

alternatively, it could be a new conditional that allows you to change custom states from the conditionals:

I’m not saying it’s not a good idea. But I’m saying they have other fish to fry. Good luck!

What do you think is top of their priority list?

New pricing model, hosting in other regions, hopefully not making our workflows randomly stop working at 8AM, etc

I agree multiple datatypes would be VERY useful. The custom state thing is fine but like you said it’s hard to rely on a workflow on page load to set the state especially with nested reusables.


I use reusable elements alot and here are some things you can do if haven’t already.

If you don’t want to rely on page load workflows in your RE you can:

Have a ‘initialize’ state in you RE that will trigger actions like you would on a page load.

Use ‘when a condition is true’ workflows for inner elements that need a specific data type. So a state of the appropriate data type in your RE that when is not empty will trigger your inner element actions.

There’s also a trigger ‘RE workflow’ action that you can use. Though I can’t recall if this is a native action or it’s from a plugin…

I think it’s a nice feature to have but you can already put different data types into your RE using states.


Can you say more about this?

For example you want a group in your RE to display a list of ‘comments’ related to a ‘post’ but activates a loading screen sequence first.

The setup:

  • A state of data type ‘post’ in your RE which we will name active post for this example.
  • Repeating group with data source “search for comments” linked to active post.
  • In your RE also; a “Do when condition is true” workflow that detects “when active post is not empty” set to “everytime”. This contains the actions for the loading screen sequence.

So now whenever i fill the state of active post, the loading screen sequence while the RG loads the ‘comments’ for ‘post’.

This is a just a simple example but you can pretty much do anything with a RE what you can do with a page element. Using REs save me a lot of time.