In the last lesson, we modified what was just a simple create trip form and made it also serve the purpose of editing a trip.

One of the ways we made this possible was by having two buttons live in the form:

We just had conditions on each of these buttons to show and hide themselves whenever this form was in create or edit mode — in other words, whenever the trip property was empty, or in the case of the save changes button, when it was not empty.

But generally speaking, there is an easier and more powerful way to handle this: to actually have the logic live not on our interface elements like this, but live within our workflows.

To show you how conditional logic works, we just need to do a tiny bit of setup. I’m going to delete the save changes button that we had before. So, we’re just going to use one button here.

This one button, depending on whether or not we are creating or editing a trip, is going to have a different label. We’ll use the same trick that we saw in the previous lesson, where we look to see whether the trip property in this view is empty or not.

Then we can amend what we did in the last lesson by making this button always visible and removing the condition we no longer need.

Next, I’m going to go in and edit this workflow.

I’ll add the action we previously had tied to the save changes button, which is make changes to a trip. I’ll reconnect all of these fields to be exactly the same as we set them up in the last lesson.

Now, because we’ve got these two actions sitting on top of one another, we obviously don’t want them both firing one after the other, right? We either want this action to fire or the other, but not both.

Essentially, that means we have to add a condition to each of these actions, and only when that condition is true will that corresponding action fire.

Where we add that condition is down here:

When we’ve got the action selected, there’s a little section called only when.

This is really the same as when we define a conditional statement, where it says “when” and then we write an expression. It’s exactly the same — a conditional statement we add in the context of a workflow action.

So we can add that condition here and say:

In that case, of course, it’s that trip living in that property where we’ll run the make changes action.

If this is working, I should be able to add a new trip with some new values and create that just fine.

Then if I click on that trip and try to edit it — for example, add a new end date, add a cost, and add some example summary — and then save these changes, I should see the values for this trip be updated. And I do.

So this kind of conditional logic is really common, and you’re going to find yourself using this over and over in your application.

Now, things are about to get interesting. Over the next couple of lessons, we’re going to introduce a new data type into our application — a diary entry data type, which will allow the user to add a diary entry into their app that is tied to a particular trip.

This ability for our data types to have relationships with one another is really what unlocks our ability to create truly unique apps.

So let’s start building this in the next lesson.