Weweb and executeWorkflow - Connect Any Library

Ray Deck shows how to connect external JavaScript libraries to WeWeb using executeWorkflow, which lets third-party code like Plaid or CAPTCHA trigger WeWeb workflows by ID. The trick: workflows get stripped during build unless you reference them somewhere, so add a dummy comment or custom-JS call to keep the ID in your published bundle.
Chapters
Hi, so a question that comes up a lot when I'm helping people with the hard end of WeWeb stuff is how to get these various modules that we might be working with in WeWeb, like, you know, Plaid, or things that introduce popup elements, or things that are, you know, event-driven, like CAPTCHA or security-type things. How do we get them to feed information back into WeWeb so that WeWeb can then, you know, keep on doing its work? I sometimes call this going over the wall, where you have information that's happening on the JavaScript side and things are happening on the WeWeb side. And the answer is going to be making use of workflows and having stuff that's happening from outside of WeWeb be able to trigger workflows that happen within it. So let's talk about what that means for a second. We can have— let's just add to our element here, we're gonna have a paragraph, right? And this paragraph is gonna have text. And we are going to, just for the sake of things, we're going to create a variable. We're gonna call it p— text, and we're going to bind that text. And we're going to say, well, this pText should be part of— this text here should be bound to pText. We'll go here and we'll say from project pText. Great. And now you can see it doesn't have any text anymore. So we can solve that by updating the variable, right? And we can update the variable to a workflow. And so I can drag over here and we will say we have a workflow here and we're going to call this say we're going to do lightning bolt, which is how we set up actions for a button. And we can have an action that's going to change variable value. And that value of p text, we're going to set to I clicked the first button, right? Close. And then if I were to just run this for a second by going into preview mode, I click the text in button, it says I clicked the first button. And that's, that's how it works, right? I'm able to use a workflow to change a variable and that variable then changes the element that's on the page, Or that workflow could send new information to the backend or do any sort of other interesting things that we want WeWeb to do. So the next key question is, how could we disconnect that from just being tied directly to the button? How can we have some arbitrary other piece of code maybe be able to run that workflow? And if you're a little bit more advanced in WeWeb, you may have seen this before, where you can say, well, let's— we'll make another button to illustrate this point. But we can go to the cans up here and we can go to, you know, go to our, instead of adding a variable, we can add a workflow. We can create a new workflow. We'll call it, you know, my first workflow. And we can say that workflow, which by the way, just runs on execution, right? So there's no direct event. There's no click button that goes along with it. We can say, well, this event is supposed to, we're going to have it change variable value. And the variable we're going to have it change is called p_text. And we're going to change it to, I ran this from the workflow. And then we'll say close to that. Now, how then do you invoke that workflow? And we're going to do that from the second button, and we'll call it, you know, second button. And in this button, we're going to go here, say add a workflow, and we're going to add an action. And that action is actually, instead of directly changing the variable value, we're gonna say we're going to run that workflow. I'm going to run that workflow. We'll tell it to run my first workflow, close, and then we press play. And then when we run the second button, it says I ran this from the workflow. So that's now each of these, but each of these buttons have a different job. We can do more than that. We can say that the workflow that we have created, not just something we invoke directly, right? When we go to my first workflow, but we can give it what are called parameters. And parameters are like arguments or inputs to a function. To find out what its context needs to be. So we can say new text, and that's just gonna be of type text. We'll leave it like that, although it could be anything. We will say that we're going to add an action here, which is going to be, right, so instead of setting the new variable to I ran this from the workflow, we're going to bind it to the thing from the action. I'm gonna click on lightning bolt, clicking on this parameter. Right, so now we can say, um, that when we run this, uh, second workflow, the second button, right, which invokes that workflow, it needs an argument, right? Because now it says, okay, you're running my first workflow, but you need to give it arguments. What arguments are going to give it? We're going to give it, you know, I ran this from the parameter new text, and we'll say close. And let's try pressing the eyeball. And so the first one, I click the first button. The second one, I click the parameter new text, right? So the parameter that we just set controls what the text is going to be. And if I want to change what that text is, I actually go to the second button now, because second button is controlling in here what argument is passed. And if I just call this, you know, param instead, and I say close, and I say eyeball, see, now it says param new text. So, so far we haven't really done anything new though, right? We've created a little bit of centralization of your workflows. You can imagine how you can sort of turn them into like, you know, chunks of workflow. But the really interesting opportunity here is being able to access these workflows from outside of WeWeb and in other JavaScript that you might have incorporated into your project, like libraries you're loading in. Which might have like an onSuccess type event, and you want to be able to then have onSuccess go invoke this workflow based on like a code or something that you got from whatever that library does. How do we do that? For this, I'm gonna open up my friend, which is right-click here, and I'm gonna click on Inspect, and that brings up the dev tools. I can click on Console and ignore most of this other stuff. And this is something you can run from any arbitrary JavaScript, both stuff you've loaded into WeWeb, as well as stuff you might have from the content script or things you bring in from a script tag or the WeWeb web and better from state change, uh, where we can use dub dub lib. And dub dub lib is really cool because it has in here a method called execute workflow that will allow you to execute any of those workflows you made from the cans over here. But how do you know what to invoke? Now when we do this, we see that takes two arguments called e and t. So I will say, uh, and then And this can give me an error because the workflow is not found. And the reason workflow is not found is because there's no workflow called DFGDFG. We need to find out what the identifier is of that workflow. So is it just called my first workflow? And it is still not found. And the way we get that information is actually by clicking on this little dev icon up here and with a little, little caret and the underscore. And we click where it says show dev information and turn that to hide dev information. If it already says hide, you're already set. And then we can click back into here. And now we have an ID that goes along with this workflow. So just to show you how we're getting here, we go to CAN, we go to workflows, we pick that workflow, and you have this ID. This is blue text up here. We click on that. And then, so now what I can do is say, well, let's just introduce all of that. So now we can say text and button, we can say second button. And then if we try to run it from this, well, kind of nothing happens. Why does nothing happen? Well, that's because the second thing here, this DFG, DFG doesn't make any sense. So instead, what we would do is actually say we're going to put this into an object, we're going to use these little curly braces. And we would say new text, which is the parameter name that you have in your workflow, right? So you have my first workflow and the parameter is called new text, new text, say colon, because that's the key. And then I'll say DFG, DF, g, just because it's funny. And that's what I previously put in. And we will go back over to here. I run that, see, it shows DFG, DFG. So it will also, from the point of view of your JavaScript, run as a promise. And that means if you await, you know, the execute workflow, or do a then on it, And we can say, you know, console.log, congratulations. Right? So it will run that. We can change up what this is going to be in here. Right? And it will add whatever those things are. One of the very cool things is the code that you run from out here actually works even when you're in edit mode, as opposed to being in eyeball mode. Let me switch to being in edit mode and I'll demonstrate that for you. Uh, where we click on the console and we go here and we'll say, right, and then it adds that stuff over there. So that means in your callback that you have associated with whatever this function is you're going to work, uh, you're going to just add in the www— the dublib.executeWorkflow, get the workflow that you pulled from the you know, from this blue text here that was available to you because you're now set to showing your dev information, which is why it says hide because that's the action. And then, then you have access to it. Now there's one more little weird piece of consideration here. Let me show you something, which is if this second button did not actually reference that workflow, right? So basically, so if that workflow exists, but it's not being referenced from an existing piece of code in WeWeb, Well, let me show you what happens when I publish. Okay, cool. There it is, the preview. That took a little bit longer. We sort of cut that in the middle here. And if I go click on the open, you're gonna find we have the first button, which does the thing. Second button doesn't do anything anymore, right? We took out that workflow. If I were to bring up my dev tools using the same way I did before, and I say I'm gonna go over to the console, I'm gonna clear out all that stuff, and then I run my thing again, you'll notice nothing happens, and the workflow wasn't found. Why was the workflow not found? The workflow wasn't found because the way WeWeb publishes, it looks for all the stuff that it knows needs to be referenced from somewhere on the project. But if it is not currently referenced, it will, um, it won't include it in the publications. Actually, I think it's pretty sure it's looking for the ID in question. So let's try adding the ID back into here. So we're going to go back over to our, um, our data and go to our workflow, and we're going to go to my first workflow. We're just going to grab this ID because this ID is the thing that we really need to save. And now we're going to say, well, inside our— not that workflow, but somewhere else on the page, like on the, you know, maybe on that previous button we did. Close. And we will say, well, we'll close out that workflow. And then we go back to this. Let's just take a look at this workflow for a second. And let's— or we can, you know, on page, we can say let's just sort of add a Add a workflow to it, and we'll do trigger workflows on page load. And we can sort of have something that does really nothing at all, right? Let's have it custom JavaScript, and let's see if we can just say, you know, just add a comment and have that run. Let's see if that works. And close, and publish. And we are going to try running this now. We're gonna go open up again in our start from scratch. Again, the first button works. Again, the second button doesn't do anything. And we're going to just ask whether this works now. Yeah, see, it works. See, all it was looking for, you can see it one more if I want, and of course I can change that to my heart's content. And things and stuff, right? So all I had to do in WeWeb right, is make sure that somewhere it referenced that ID. It's just looking for anywhere in essentially its code base as it thinks about it to make sure that ID exists. You can embed it onto a, um, onto a variable, onto a, um, you know, onto an element that's on the page. And the way I just did it in a way that would have no other side effects is by putting it into a workflow— not that workflow, uh, putting it into a workflow on the page Right? Trigger workflows, workflow, and then introducing this little bit of custom JavaScript. And the custom JavaScript has nothing but a comment line. That's what those slash slash thing does. And by doing that, I guarantee that the ID of the workflow is present. That then pulls in the workflow and makes it available to the external JavaScript, even if you're not calling it from anywhere inside WeWeb. This is, you know, a thing I found a lot of people get stuck on, is how to make sure that the workflows all get across to, you know, your other side. And so my recommendation is when you have a workflow and you want to call that workflow from the outside, you know, go to page load or some other workflow you're working with and just, you know, make one here. And let's just say, you know, store, you know, workflow IDs, right? And you can just sort of warehouse them in these comments. That way they have absolutely no effect on the performance of the whole operation, but they can— but they make sure they remain available to you on the other side. Hopefully this all gives you some sense of how you can work with WeWeb and with any external JavaScript library that you choose to bring to the party, including ones over from, say, ScriptTag, or from the other libraries you might use like Plaid or other financial libraries, security libraries, whatever they might be. And going forward, if this is helpful to you, I hope that you'll let us know in the comments and also what projects you're trying to integrate with WeWeb. And if you're finding that you are, you know, getting into things that are even more sticky, well, the hardest 5% of these no-code projects is exactly what we do as a community and in our office hours over at StateChange. We love to work on the novel problems together. And I hope that this little video here has made this problem a little bit less novel and a little bit less scary and hopefully out of the 5% for you.










