Part 3 of 4

Build your first app

Build a todos app with authentication. See how Elements provides the building blocks and the analysis that keep Claude Code on task.

OK, now it's time to have some fun and build an actual application, and Claude is suggesting that we build a to do's list because it's a rite of passage, and indeed it is. If you're going to be a developer, you need to build at least one to do's app before you move on to anything else. I'm going to add just one thing to this though. I wanted to build it with authentication right off the bat, so I'll say OK, but add off also.

As Cloude code works on the application, you're going to see it come to life in the browser in the lower right, and you'll see the user interface come together, you'll see Cloude begin to drive the interface, log in as a user, test different to dos by test adding to dos, deleting to dos, and so on. And Elements is so fast that when Cloude makes a change, the browser is typically updated within a few milliseconds. So, it's a very fun experience to build with elements, uh, elements in Cloud. You'll see the application coming to life in real time.

You'll see as Cloude drives the application that occasionally the state in the upper right will turn to error, and that's because Cloude's made a mistake and Elements will correct Cloude into correct Cloude and Cloude will fix the issue immediately. And that's because the build server that Elements is running responds to Cloude's queries in microseconds, and then Cloude can just continue with its building. Claude's completed the application. The entire thing only took about a minute or two, and we have a full to do app in the right.

Let's just make sure that it works. And indeed it does. Before we conclude, let's take a closer look at that OK versus error state. When you see green, it means everything's OK.

When you see red, it means there's an error. I'll go over to the left and I'll have Claude introduce a TypeScript error. And I'll close the browser so we get a better view. When Claude makes a mistake, whether it's a TypeScript error or a migration error or anything that would prevent your application from working, it could be a failing test.

There's a number of things that could cause a build to fail. You'll see the state change to error, and the errors will be presented in the user interface. And in this case, Claude deliberately introduced an error so that we could take a look at it. I'll ask Cloud to fix the error, and when it does that, the build server updates immediately and we see that state change back to OK.

On simple applications, Cloud might be able to one shot it without creating any errors, but typically if the application gets complicated enough, it will uh create errors and it needs to be corrected. And that's one of the main things that Elements does and why Elements applications are so much more robust on the first try, but especially over time as the application gets bigger and bigger. Lastly, let me show you around some of the elements commands that I think you'll find useful and how to get your way around these panels in Claude Code. If I click the right panel and I use the queue key, that will exit out of the Element Start program.

If you want to start Elements again, you can use the up arrow or type Element Start and press Enter, and that will start your application server. If you need to bring back the browser, you can click this link or you can use this icon that kind of looks like a globe. I'll press the cue key and show you another command that's useful called elements test. When Cloud was building your application, it writes a bunch of tests.

I count something like 30 tests here, and tests in elements are extremely fast. They run concurrently, usually in a couple of milliseconds, and Cloud will make extensive use of them. In this view, you can see which tests you're passing and which ones are failing. This is one of the reasons why Elements applications will last a very long time over time.

So if you are building an application on the first day, it will Work by the 3rd or 4th week, you start to break things as you add new features, and tests are a great way to make sure that your application does not regress. Elements ships with the Postcress cluster and manages it for you automatically. It'll create a test database and a regular app database for each one of your applications. You can use the elements db command and that will drop you into a shell where you can interact directly with the database using SQL.

For example, since we created authentication, We have a user's table and you can see how the user was created with a hashed password in this database. You can press backslash queue to exit out of the the PSQL shell. There's a lot of other elements commands that we can cover in subsequent videos, but if you want to get a sense of what exists, you can type elements and then use the help flag, which is dash help and press enter and you will see all the commands here. Some of the features I just showed you are a little bit more advanced, you don't need to worry if you don't understand everything I just showed you.

And also remember that Cloud is here to help you, so if you run into any kind of problems, you're not sure what's going on, just come over here into the chat window and ask Cloud what to do next, and it knows everything about elements and can help you through anything, any kind of problem that you have. OK, builder heroes, congratulations, you have finished your rite of passage and you have a fully working to do's app with authentication.

0

Add a comment