In this video, we review the newly set up KOS UI project on VS Code.

WHen you open the project in VS Code, it recommends the extensions based on the project setup. Ffor example, code formatting, administrative tools, etc. We recommend installing all recommended extensions. Using the terminal of your choice, open the project location and install all dependencies using:

Once dependencies are installed, in the project structure, we usually focus on two areas for active development:

So one of the first things you might notice when you open up Visual Studio Code is you might get a little notification at the bottom saying that there’s a few recommended extensions to install.

If you get this, it recommends you show the recommendations, and then there’s a little cloud that you can use to install them.

Now the recommendations are actually coming as part of the scaffolded project.

It comes with a handful of recommended plugins that will help the developer experience things from code formatting to administrative tools to linting and various other things that are really important from a developer perspective.

So we’ve bundled up a bunch of recommendations that you can choose to use.

If you just hit the cloud, it’ll actually go off and install all of the recommendations for you, and everything will be ready to go.

So once that’s done, we’re ready to start getting our dependencies installed.

So the first thing you’re going to want to do is open up the integrated terminal, and there’s a couple of different ways that you can do that.

So the reason for this is rather than having to pivot between your external terminal program and VS Code, we want to try to keep everything as contained as possible.

So reducing the amount of swivel chair, reducing the context switching, it all helps to improve the overall developer experience.

Your mileage may vary, but this is the process that I like to use when I’m developing.

So don’t put up the integrated terminal.

There are a couple of ways to do that.

The first is VS Code’s command palette.

You do Command-Shift-P, and it will pop up a little menu of all of the various commands that are available, and one of them is going to be create new terminal.

There is an additional shortcut that you can use, which is going to avoid that step, and you can just say Control-Shift and backtick, and it’ll open up another instance.

You can see there’s now two separate terminals that are available for me to use.

I’m going to go back to just the one for now, and what I really want to do from here is install all of my NPM dependencies.

So it’s as simple as NPM install, and it’s going to go off and pull down all of the dependencies required for using the various SDKs for setting up a dispenser application, as well as all of the dependencies needed for the development environment itself.

So now’s probably a good time as any to go into some of the things that are already pre-configured while this goes for a couple of minutes.

So if you go into the package.json file, you can actually see all of the dependencies that are included.

There’s not a lot of dependencies we needed to build with the SDK.

The first is the UISDK itself, and then there’s the dispense SDK, which is really used for dealing with applications that have an assembly, and you learned about that in an earlier session.

But really, this is what’s going to allow us to talk to a back-end application and set up our models to build a front-end application in the corresponding middle layer with the models.

There’s a number of development dependencies, which are really around supporting the development environment, and we’ll talk about some of that over the next little while.

So that’s all installed, and you can actually see in the node modules that there’s been a number of modules that have been installed.

So the environment is ready to go, and we should be able to start exploring within this environment all of the capabilities that are available to us.

So first thing, we can take a look at just generally what’s in the applications itself, look at some of the code, and then we’ll take a look at some of the tooling.

So let’s first off look at the project structure.

There’s really two main areas that you’re going to be focusing on as part of active development.

There is the apps folder, which is where all of our UI applications are going to go.

In this case, it came pre-configured with the dispenser UI project, and all of the various TypeScript configurations and all of the ESLint rules that we recommend for a modern front-end development practice are already there and pre-configured.

There’s nothing you really need to do, as is the build pipeline, which is using Vite.

So this will take care of minification and all of the things that you need in order to have a functioning UI application.

So what that means is you get to focus more on the code.

So when we drop down into the source folder, we can start to look at the actual code that’s been created.

And there’s a little bit here in this bootstrapped application that’s not just a standard React app.

So it comes already set up with everything needed to run a UI, a React application.

But most importantly, it has this context provider, which is wrapping everything.

And this basically allows this UI to run in the context of a KOS session.

So effectively, this is the part that’s responsible for connecting to the back end and setting up all of the various web sockets and getting the environment ready to go.

So that when you’re writing code, you’re really just focusing on everything inside of here.

Everything has been pre-configured and pre-wired.

You have the ability to change any of the configurations for your specific environment.

And in fact, there are environment variables provided that help to drive and things like what port is it connecting to and a few other configurations.

Most of these you probably won’t need to use for everything.

But there is the ability to tweak some of the behavior as we go.

Without getting too far into the details of the UI, the other part of it is in the libs directory.

And this is where we talked about the models that we have.

So by default, there is a single model that gets created here in the dispenser directory.

The dispenser model is really just a, you can think of it as the root model for your application.

You can choose to use it or not, but it’s a good practice.

We wanted to have one created for you so that you can see what’s part of a model and how to use it.

We’re going to go through all of this when we start talking about actually creating models.

But for now, just understand that when you create models using the tooling, they will appear in here, in this models folder.

When you create components or parts of your UI application, they’ll appear up here.

From here, we can start to look at some of the tooling that’s available within the environment.

The first thing is some of the plugins that were installed, you remember the recommended plugins.

One of them was the NX console.

And when we talk about the NX console, that’s really referring to the tooling that’s helping to support this project, which is actually a NX project.

NX is a mono repo implementation, which allows us to actually have a lot of different projects and configurations all within a single repository or a GitHub project.

So in this way we can have each of these things, all of the apps and the model projects and all of the various packages that we want to later on can have independent build life cycles and can be deployed separately if we wanted to.

But ultimately they are all contained by a single overarching build.

And all of these projects and packages are going to have dependencies on each other.

And NX is really responsible for ensuring that all of those dependencies happen in the right order and that it streamlines a lot of the build and deployment processes for you, especially as your code base starts to grow.

Typically if you’re dealing with a single application or a single UI component, you don’t need the power of a mono repo, but typically with any dispenser application, you’re going to have a consumer UI, which is where your end users are actually pouring beverages.

You might have multiple of those because there could be one for end users.

There could be a crew serve consumer UI, which is a completely different user experience, which is used for folks behind the counter.

They have different needs and requirements.

And then there’s almost certainly going to be a administrative UI or a non-consumer UI, which is going to help for technicians and management to deal with setting up the dispenser in terms of selecting drinks and various other processes and procedures that are required to maintain one of these machines.

So all of these things are separate projects.

You typically don’t want them living as a single deployed application.

You’d like to have them as separate.

So mono repo starts to make sense when we have more than one application or more than one sort of project we want to maintain.

So NX provides a lot of that, and the NX console provides the tooling to help drive a lot of this for you.

So when you go over to the NX console, you might be asked to refresh the workspace if it’s your first install.

And what it’s going to show you is what we already looked at.

There’s two projects.

There’s the dispenser UI, and then there’s the dispenser model project.

And they both have various commands that we can run against, and a lot of these things are familiar to anyone who’s done UI development.

So I can go in here and say I want to build the UI and just hit the play button.

And what you’ll see down in the integrated terminal is the project running, right?

So it’s going to run through the build process and produce an artifact.

Similarly, if I want to host it or run a development server where I can do that, I can use the serve directive to do that.

And there’s similar ones for the model project as well.

It has a smaller subset of things that are available on the model.

But basically, I can do similar sorts of things, which is great.

However, where the real power of NX comes in is its ability to manage dependencies.

So I can say just generically, I can run build and it’ll ask me what I want to run against.

And it’ll execute the command.

And it’s going to run the build not just for the UI project, but because the UI project has a dependency on the model project, it’s going to run the build for that first.

So all of that knowledge of understanding what has a dependency on what and where are the various parts of the build lifecycle are all managed by NX.

And it’s done dynamically based on what modules you’re using and what code is part of your project.

That just helps to simplify the process for the developer.

And it also helps to improve the build time and various wait times that you have where otherwise waiting for long builds to go through.

There are some things that we can do here.

I mentioned there’s build.

And then there is going to be things like serve.

And this is where we actually start serving up the UI in a way that we can consume it.

So if I run the serve directive, it’s going to bundle everything up and create a and host it on this location.

And it’ll tell you in the console, it’s going to automatically look for ports.

So if there’s already a UI running, let’s say you’re trying to run multiple UIs.

If there’s already one running on this port, it’ll find the next one.

And you’ll be able to open that up.

So the way that I can look at that, I can either go into my Chrome browser or whichever browser I have.

And in the interest of trying to keep things contained, I can also use an integrated simple browser that exists in here.

I can just put in the same address as well.

And what you see here is the welcome screen, right?

So it comes with this pre-built welcome UI.

And if this comes up, you know that a number of things have happened.

You know that the KOS model framework has been initialized, that it’s been able to establish a connection to a backend UI or a backend process application that’s running KOS and has been able to perform the handshake, establish a web socket transport, which is how the UI and the backend will communicate.

And as a result, the model has been able to come up and you’re presented with this screen.

If you don’t see the screen, it probably means that you have to configure your port mapping or you might have to take a look at how you’ve configured your environment.

But basically getting to this point is success, right?

So what we’ve been able to see here is the NX console and how it’s able to help to drive some of the build processes.

An important thing to mention though, is that for those of you that prefer to do things by the command line, all of the things that you saw in the console are available through the command line as well, right?

So if I run a build on the dispenser UI, it’s telling me what the command is.

And I can find that command here and actually run that in the CLI as well.

From the terminal, I can run the exact same command and it’ll do the exact same thing.

So the console is nice to have, it actually simplifies a lot of things.

And once you start using it and it becomes integrated into your process, it becomes really quite natural.

But for those that prefer the comfort of the terminal, then it’s still available and none of those things are closed off to you.

It’s really just a layer on top of it.

The one last tool that I wanted to show while we’re in here, and it’s part of the recommended package is Postman.

So it’s going to be something that’s quite common when you’re building your models and when you’re working with the backend.

You want to be able to see what various calls are going to be made.

And in here, I’ve configured Postman.

You’re going to want to set up a Postman account probably.

And from there, you can actually, again, I’ll integrate it in.

I can make calls to the backend against some of the various KOS endpoints that exist.

So in this case, I can take a look at all of the various handles that exist on the system and it’ll give me the results back here.

And there are a number of different system endpoints that I might want to use.

And so having a tool built into the IDE, again, is a good for development.

It’s a better development experience, right?

So I can stay focused on the IDE and not have as many times where I have to spill the chair out.

So from there, we’ve now got an environment that’s set up.

We have the monorepo that’s available.

All of our dependencies are set up.

And so now we’re ready to start jumping into model development, which it will do in the next session.

Thank you.