How to communicate between reusable elements using ENV Variables in Bubble.io

Dennis H. Lewis shows how to use the bdk Environment Variables plugin to let Bubble reusable elements talk to their parents. Custom states fail inside repeating groups, but environment variables let you pass unique IDs back so the parent knows which row triggered a change. You have to reset them after handling so they can fire again.
Chapters
Ever tried to get a reusable element inside a repeating group to talk to its parent and you just can't? Yeah, that limitation has probably cost you hours, maybe days. But today I'm going to show you the workaround that Bubble's own documentation doesn't even mention. Hey, I'm Dennis Lewis from Ratio.dev. i've been building applications since before the Internet was a thing. Literally worked at IBM's top secret Aix operating system back in the day. And after 40 years in tech, I can tell you no code does not mean no work and it does not mean no challenges. But here's the thing. Most challenges in bubble, they're solvable. You just need to know the right tools. And today that tool is a plugin called Environment Variables by bdk. Stick around, because by the end of this video, you'll never struggle with reusable element communication ever again. Here's what we're going to cover. Why the traditional approach fails and when it does work. How environment variables solve this problem. Kind of magic and a step by step walkthrough. You can implement this today in your Bubble application. And before we dive in, if you want to level up your bubble game, check out the link below. We've got a free no code resource center packed with vetted plugins, how to videos, podcast episodes, great books to read. Some of them will leave them by yours truly. The resource center is updated every week. It's free, just your name and your email. So jump over to ratio.dev grab it and come back. I'll wait for you. Be sure to look through it. You're going to find lots of good stuff there. All right, let's start with the easy cases, because most of the time you don't need environment variables. One way that you can communicate from a reusable element to its parent is by placing a custom state on the reusable element. Here in the bubble builder, I have a reusable element called flower dropdown. And if I look at it here, it has a series of custom states. One indicates if it's empty, if it's been selected, yes or no, the selected flower. You don't have to really understand what this reusable does, but normally when you have a reusable element embedded in a page, you can trigger workflows that happen when one of those custom states changes. It's as easy as going in. You would create a workflow and you would say when a condition is true and then you would just reference that custom state of that reusable element and boom. That will work. That is the textbook way of communicating from a reusable element back to its parent in bubble. What's the problem? There's two major problems with this that might happen occasionally that you run across. One is when you want to communicate from one reusable element to another. Perhaps you want something in that reusable element to trigger a workflow that you have in the header of your page. You can't do that because the reusable element doesn't have the header. It can't communicate with the header because the header isn't its parent. That won't work. Now you could perhaps put a workflow in the page that that includes the reusable element that triggers a workflow in the header. You could do that. That's not going to be the best solution. That's case one. Case two is when you have the reusable element inside a repeating group because there bubble won't allow you to see the custom states of each row of the repeating group where that reusable element is embedded. Doesn't work. Bubble doesn't support that. And in these two cases I'm going to give you the solution today. The solution is a plugin by bdc. Let's jump over here. It's called Environment variables. It does have a small cost. You can go and check it out. It's not a big deal. What this does is it allows you to use environment variables like you would use in JavaScript inside your bubble application. The first thing you're going to do to make this happen is you're going to put on your page the environment variable element. And you'll see that once you've installed the plugin, you have down here an element called environment variable. You can have as many of these on your page as you need, but each element of this allows you up to six variables. You can do quite a bit with just one. But let's walk through how you set this up. In my case here I have. I've created Environment variable FDD and Environment variable number one is a variable name called isupdated and it's a yes or no. I'm in the reusable element here. I'm not looking to fire a workflow here, but I may be looking to fire a workflow in the parent element. And we'll see that in a minute. Is updated is a yes or no. Environment Variable number two is are the IDs of the selected flowers. In this case, they could be more than one. I'm Putting this into a text field and we'll talk about that a little bit later on. And environment variable number three is is of type harvest log. Environment variable number four is a task, a field. Note here I have. I've created each of these environment variables in here and I put them inside my reusable element. Now, I usually make them one pixel by one pixel. They do need to be visible. You can't just put them on the page and say, don't show them, make them invisible because they won't work. They need to be visible, but they can just be one pixel. You can sit it off in a corner somewhere, don't give it a background. It will be basically invisible to the user. Now, what you can do then is when you want to communicate back from your reusable element to wherever it is, be it the parent, owner or another reusable element, wherever it is, you would go into your workflows and all you would need to do is update the value of the variable. In this case, I would say update value number one, which was is updated. You have to keep track of this. It doesn't show them in here. I'm going to make that a yes. I'm updating that as a yes. And then I'm taking the result here, taking its unique ID and passing it into number two. And then I'm passing these values back into changing the environment variables that they all have their correct values. Now, that's how you would change the environment variable. But now let's look at where we received this information. We're going to go to Harvest, for example, and inside Harvest I will show you that I have installed here this very same environment variable. Now, it's important it's the same. Want to make sure each one of these is configured correctly. They coincide, otherwise it won't work. One is updated, same name, same type of. But here I've clicked off trigger workflow on change. That means every time this variable changes, it will trigger a workflow. And we'll see that in a minute. What I will do there is in workflows. I have a workflow over here now that says every time this environment variable number one, the number one value in there is updated, is, is changed and it's not, it's not empty. Because I, in this case, if it's empty, I don't want it to actually run itself. Then what I'm going to do is I'm going to trigger in this case a custom event and I'm going to pass it the harvest log and the Flower. That's the, in a nutshell, how all this works. Now one of the key things though is when you're using this from inside a reusable element that's in a repeating group. Now I want you to understand every time the page loads, the environment variables are all set to their default values. It's like a custom state, it's not persistent. Every page load starts clean. But now, if you have this reusable element in a repeating group, like I do here, in one case, that environment variable has instances in every one of the rows of that repeating group. Plus in the page now in the rows, nothing's going to happen because there's no workflow associated inside the rows. It's not going to cause cascading bunch of things to happen, although you could do that if you wanted to. It could be a bit of a workload hog that way, but you could make that work if you needed to. But in this case, how does my parent know which one of the rows in the repeating group has triggered the change? How am I going to know? That's why I'm passing. In this case, the environment variable. Let's look at. It has field number three is harvest log, is of type harvest log and it's. I've called it harvest. Whenever I change it in the reusable, I change this value to the one that I'm currently have inside my reusable element, which is inside the repeated group. And that comes back to me when this changes. Now I know exactly which row triggered the environment variable to change. And that's the row, that's the item that I'm going to pass into my custom event and do whatever I need to do. I now have identified it. That is how you loop it back from a reusable element inside a repeating group because otherwise you would just know that it changed. But which one? That's not going to get you to the solution. This is how you solve that problem. By the way, if you put this environment variable in your header, it will also get notified and it could trigger a different workflow in your header. Maybe you could. This can be very flexible as far as communicating between different elements. Now, one thing you want to make sure is that you, after you finish processing whatever it had to process, set it all back to its original state that the next time when somebody else changes, it will change. Because if you leave that environment variable is updated equals yes, then the next time a different row in the repeat group changes to yes, then it's not going to execute the workflow because it hasn't changed, because the workflow executes when it changes. That's why at the end of that workflow I always set it back to null or to empty. And that way I know whenever the next one happens, it'll be an actual change and it'll fire the workflow. Hopefully this step by step process will get you where you need to go. If you have any questions or any doubts, feel free to reach out to leave a comment, a question in the comments below, or reach out to us at ratio.dev, we love to talk to people. If it's something that you need help with, we would be glad to jump into your application and get things set up and going for you. That option is always on the table as well. Hope you've enjoyed this video. Give it a thumbs up a like subscribe to our channel. You don't know how special that makes us feel. You know, we're just this boutique bubble development agency. We love to build businesses with bubble. When we get new subscribers, that means somebody out there is resonating with what we have to say that makes us feel good. If you've enjoyed this video, stick around for the next one. See you there.
It.
More from Dennis

Is Google Killing Websites? The Future of Search, SEO & Web Design After Google I/O

Something we're still looking forward to in Bubble: richer design experiences! #bubble #nocode #ai

Big mistake companies are making right now: firing employees instead of empowering them. #ai







