All right, let's draft out a rough idea of what we'd want steps to actually look like for the end user, for the developer using Laravel prompts. And the first thing we'll need to do is actually create a new branch in git so that we're not trying to push changes directly to main. git checkout -b to create a new branch. Let's call this one steps. All right, so from the IDE, I want to create a playground in order to build this ideal syntax. And I noticed index.php between this and the last episode, where they actually show many different types of prompts.

And I noticed index.php between this and the last episode, where they actually show many different types of prompts. So intro, they have a suggestion, they have text, they have passwords, select. They've got it all. And it'd be a perfect starting place for steps. So let's go ahead, copy and paste index.php. We'll call it steps.php. And then let's think about our syntax. In maintaining consistency with the rest of prompts, I'm imagining we'd have something like a steps function that would return a builder that allowed us to chain on as many

In maintaining consistency with the rest of prompts, I'm imagining we'd have something like a steps function that would return a builder that allowed us to chain on as many different steps as we'd like. So perhaps we call an add method. Add is going to receive one of these prompts, like intro, for example. And then if we want to add a second step, we just call add again and pass in another prompt. And we suggest as a second example. And we do this over and over again for each prompt in the series. Let me go ahead and do that off camera so that you're not watching me copy and paste.

And we do this over and over again for each prompt in the series. Let me go ahead and do that off camera so that you're not watching me copy and paste code. All right. With the magic of editing, I am back. And I've added various steps into this builder. I've come across an interesting one here, which is confirmation that you want to actually install dependencies, which then shows a spinner. And I don't think it makes sense to have this and this confirmation as a separate step. Rather, I think this would all be a single step inside our builder.

And I don't think it makes sense to have this and this confirmation as a separate step. Rather, I think this would all be a single step inside our builder. So I'm going to take this code and I'm going to add another step. But what if we said you could pass in a closure and that closure could basically do whatever you wanted. So in this case, it confirms that you want to install dependencies. It shows the spinner. And then at the end, it could return whether or not you actually want to install the project. I think that makes a lot of sense. Taking a look at the remaining output in this script, it shows some example error warnings.

I think that makes a lot of sense. Taking a look at the remaining output in this script, it shows some example error warnings and alerts. I don't think we need that, but I do think we should show this note at the end. So let's take that and then we'll add that as a final step to this prompt. Add and we'll show the note. Here's another issue we need to think about. So this note actually makes use of this path variable, which is actually a response from this text question up here. So we need a way for a step to receive previous responses.

this text question up here. So we need a way for a step to receive previous responses. Again we could do that with a closure. So we could have a closure and that closure receives an array of all responses so far. And then we just need to use the key, the index of the step. So this is the zero index. This would be one index and this would have an index of two. So instead of path, we'd simply say responses[2] and that should show us the same output. Nice. All right, let's get rid of all of these variables that are in the script so far to clean this.

Nice. All right, let's get rid of all of these variables that are in the script so far to clean this up a little bit. We need a way to run all of these steps. So why don't we chain a method onto the builder called run? Let's remove the outro. And obviously, having removed all of those variables, this var_dump will no longer work. But how about at the end of all the steps, you receive the responses as an array and we could just pass responses to var_dump instead. Okay, so let's go through this one more time.

we could just pass responses to var_dump instead. Okay, so let's go through this one more time. We create a StepBuilder using steps. We can add as many steps as we'd like using the add method. If a step needs to perform multiple actions, well, you can pass a closure instead of passing a prompt directly. And you can also receive any previous responses inside that closure to make use of inside the prompt that you output. Finally, when you're ready to execute all the steps, you call run. Now, in my head, I'm already thinking, how do I rerun any of these prompts?

Finally, when you're ready to execute all the steps, you call run. Now, in my head, I'm already thinking, how do I rerun any of these prompts? Because that's basically what the stepper is going to have to do, right? It's going to take all of these steps, it's going to run them in order. But if you revert a step, if you go back, it needs to be able to execute that prompt again. And I don't think that our current setup actually allows that. So I think at least for now, we're going to have to wrap all of these prompts that we add as steps in a closure. And that will actually allow the functionality that we're after.

add as steps in a closure. And that will actually allow the functionality that we're after. It's not too big a deal, especially now that we have shorthand closures. It's actually pretty clean. Also, thinking about this, we have this intro, welcome to Laravel, I shouldn't be able to go back to that step. It doesn't make sense that I'd see that intro more than once. So what if we could pass another parameter to add, maybe revert, and we could set that to false. And if that is false, you wouldn't be able to go back a step.

to false. And if that is false, you wouldn't be able to go back a step. We could have that in other places. For example, after you've entered a password, maybe we stop you being able to go back beyond this point in time. That gives me an idea actually, as well, because when you install dependencies, although technically this is just faking, it's going to sleep for three seconds, what I imagine is actually happening under the hood is it's running a composer command or an npm command. It's doing something. Now if you revert this step, we need to be able to undo whatever we've done inside the

It's doing something. Now if you revert this step, we need to be able to undo whatever we've done inside the step. So instead of just passing false to revert, you could also pass a closure, and that closure can perform any undo logic that you want. So in this case, why don't we just go ahead and create another spinner. That spinner would sleep for three seconds, and it would say something like uninstalling. So in other words, if I undo this particular step, it's going to uninstall anything it installed whilst running the step, and then it will run this step again to allow me to reinstall the dependencies.

installed whilst running the step, and then it will run this step again to allow me to reinstall the dependencies. All right, so we do have basic syntax here. Obviously it's not going to work. If I run php playground steps.php, I'll get an error because there is no function called steps. But this is one of my favorite ways to work. Build it backwards. Start with the implementation, create a script or a playground file, toy around with different ideas.

Start with the implementation, create a script or a playground file, toy around with different ideas. What would steps look like in a perfect world? And once you have that syntax in your head, on the page, and you've ironed out some of the initial kinks, it's time to make it work.