So, just a few things to get out of the way. So, there is a code of conduct at React Summit, so be kind to people that you interact with. We encourage interaction and talking with people, but let's be sensitive to that there are actual people on the other side, and we want to be caring for each other. But yes, please join the Discord, and I'm going to paste the link again for people who showed up. So, we recommend any chatting that you want to do, don't use the Zoom chat, use the Discord channel because we can have threads there, and we can make sure that we answer you appropriately. Zach is going to be mainly doing that interaction.Actually, sorry, I should introduce myself. My name is Isaac Mann. I work at Narwal. I'm an architect at Narwal. I've been at Narwal for two years. I've done a few of these workshops, and I also help with the documentation on NX.dev. Zach, do you want to introduce yourself? Sure. Hey, everyone, I'm Zach. I'm a senior engineer at Narwal, also been with Narwal for about two years. I've worked on docs in the past. Currently, I'm working on NX in the React team, actually, so this is a great fit for me. But yeah, looking forward to doing this workshop with all of y'all. And I'll be deep in the disk board here while Isaac's presenting. So I'm looking forward to seeing y'all there. Zach's also going to be listening to me and making sure I don't say anything wrong. He'll jump in and correct me if I'm making egregious mistakes. I'll do my best.OK, so yes, use the discord. If you do have questions that you want me to answer live, you can use the Q&A feature on Zoom. Or just, I don't know, tag Zach in the Discord channel. And any, you know, questions that he thinks are worthwhile to talk about verbally, he'll bring those up and we'll talk about them on the recordings. Speaking of which, there is a recording of this workshop that will be sent out to you. If you have to drop off for any reason, you'll get the recording later this week. We have the, this workshop that we're going to be doing is typically about six or seven hours long when we have people do it themselves. So we're going to, basically I'm going to be coding along with you and trying to get through six hours worth of content in three hours. So, feel free to, you know, please ask questions. We want you to learn as much as possible, but I am going to kind of move forward fairly quickly so I don't waste your time and so we can get through as much as we can in the time allowed. So with that, I think that's everything we needed to cover. Anything else, Zach, that I forgot about? Really quick, I just posted in the discord a link to the repo so you can start cloning that down and running the npm installs. So, maybe we can try to follow along with Isaac if you want, but he's going to be going pretty quickly. Yes, yes, please follow along. Please look at the workshop. At least for me, I find it most helpful to have... Let's see if I can move the zoom controls out of the way. I find it most helpful to be reading and listening at the same time. But I mean, whatever you want to do is fine, whatever, but... These, all these steps that I'm going to be running through are written out very clearly in this repo here. narwal-index-react-workshop. And so I'll just be going through this together with you and you should be able to, you know, if you want to go back through it and do it yourself afterwards, you should be able to follow all these steps on your own afterwards too. They're written out so that you should be able to do that. Okay, stop share. Okay, so I'm going to start off with a little slide show here, keynote presentation. Where I'm going to talk a little bit about what NX is, to get everybody kind of on the same page of what what NX offers, and then we're going to dig into the, the hands-on piece here. So hopefully you were able to see the talk that that Yuri gave last week. If not, Zack, could you like paste a link in the YouTube or in from the YouTube link in the Discord? I think Yuri shared it in Slack if you want to grab that link. But I'm going to do a basically another another summary of what NX is and and then we'll dig in here. Also the the content of this workshop is going to kind of mirror what Yuri's egghead course is. So if you want, you know, another person going through that mostly the same content. You can do that with with the egghead course. It's a free egghead course. That you can follow along with. Alright, so React at scale with NX. So and X is a tool for managing monorepos or repos of any size really but it really shines with with a monorepo. Now monorepos get a bad rap. They get conflated with monolith, so you don't have to make a monolithic application inside of a monorepo. What a monorepo is, is a, you know, a repository with more than one application inside of it. So there are there are definitely benefits to monorepos. And we're going to go through we'll talk about the benefits and then the next section we'll talk about the negatives of a monorepo. And then the third section we'll talk about how NX allows you to get all the benefits of a monorepo while avoiding all the a lot of the negatives of a monorepo. So first, let's talk about the benefits of a monorepo sharing, having code in the same repository. So one benefit is that if you had multiple repos, say, you had an application and a UI library that were in separate repositories, you get into the case where you have a big cycle time from from when a bug is introduced to when it actually gets fixed. So let's let's go to this scenario. Say, the common UI library developer makes a change to the library and then updates the version number and publishes it. And then they think everything's fine. But later, like maybe the next day or maybe even later, the the homepage app developer updates their version of the common UI library and realizes that that library change broke something in their application. So they have to file a bug with the common UI library and say, hey, you fix this thing because we can't update because you're your change that you made broke us. So then, the person writing the common UI library, you know, gets that bug and says, OK, I have to make those changes and then publish another version. And then later, another day or two later, the homepage app developer gets the latest version checks it and says, OK, finally, now it works and now we can, you know, use the latest common UI library. Whereas, if they were both in the same repository, the common UI developer would make a change, run the tests that were related to that change and realize, hey, within 10 minutes, they can see I broke the homepage app. I need to fix that. And so you've gone from a cycle time of a couple of days to minutes within an hour. Which is whenever you run the test, you can see that you broke the change. You haven't even pushed anything up to the Git repo. And you can fix that change. So fixing a change closer to the time when you write the code will make for better code and make it easier to fix the change rather than trying to remember what you did three, four days ago. So that's atomic changes. Then monorepos also give you a way to easily share your code. If you want to share your code in a multi-repo environment, you have to export it. You have to publish it. And then if you make a change to that, you have to make a new version and push it out again and bump up the versions and all the other applications. Whereas in a monorepo, you can just make a function, you export it, and then other places that want to use it, they just import it. And so you have a function like this, username is valid. And if that ever needs to change across the board, you just make the change in one place, and it's your basic dry principle here. So that's great! That's very useful.

Third benefit of a monorepo style setup is that you can have a single set of dependencies. So typically in any significantly large organization you're going to have multiple applications, and some of those applications get updated all the time because you're always working on them. You're going to have them at the latest version of React. But some of those applications are going to be... you know, you touch them maybe once a year, and they're going to be on an older version of React, and they won't get updated. And then, once you get an application that's three or four versions behind, it becomes pretty painful to update it, because you have to go back and remember what you were thinking about when you the last time you updated from React 14 to React 15. And you have to remember, okay, what were all the gotchas that I ran into then, that I have to remember to fix those things when I move it up. Whereas, in a monad repeater, you keep everything at the same version, so you do that upgrade from React 15 to 16 one time for everything, so you remember, I need to go through with the whole code base and make all these little changes that are all basically the same change, but you just do it everywhere at once, and you keep everything up to date. There are other benefits to having a single version of React across your code base, but that's a big one. So, code colocation is basically a monad repo without tooling around it. So, this simple code colocation is you just take the code and you drop it in a repo together without any tooling. And there are bad things that come with that. So, these are all the negatives. Basically, these things are what give monade repos a bad name, why people say, oh, no, you shouldn't have a monad repo, so we're going to talk about those things. So, let's say you have a library or, you know, project that depends on another project. The product's home page depends on the shared product UI. And you just make a change to the top one, the product's home page. Now, you got to run tests to make sure you haven't broken anything. But you know, because you only made changes to the top project that you don't need to run the test for the shared product UI, because there's no possible way that your change actually broke the shared product UI. So without tooling, you have no way of knowing, you know, unless you have it in your head, that the shared product UI tests don't need to be run. So that your CI system doesn't know that. So you just have to run the test for your whole repo every time any change is made. And that, in this very small example, that's twice as many tests. But in any, you know, reasonably sized application and it's going to be your dependency graph will look more like this or even, you know, much bigger than this. And so if you make a change to something at the top of this graph, there's going to be a lot of wasted effort put into running tests that can't possibly be broken by the change that you made. So basically you can, you'll be adding unrelated code will slow down the CI system for other parts of the repository. So you'll you'll have exponential slowdowns the more code you add to the repo. Another issue with a mono-repo, because it's so easy to share your code, so there's some code that you don't really want to share, but somebody is going to find it and, you know, you can label it whatever way you want. There's APIs in React that are labeled experimental don't use, but people use them anyway. And so when you have things like that you're this is going to be a similar similar concept that happens in your own organization's code. You're going to have things that, hey, I don't want anyone else to use this because I want I want the freedom to be able to change this later, but someone is going to find it and somebody's going to use it and you can't stop them without some tooling in place.

Alright, the third problem with an unmanaged monorepo is inconsistent tooling. Each application has its own set of npm scripts and commands, making it difficult for people to transition from one application to another without understanding the specific commands needed for each. Without consistency and structure, managing the different commands and flags becomes chaotic.NX can help by providing speedier command execution through executors that run commands. NX affected understands the dependency graph and can run tests only on the projects that are affected by code changes. It also utilizes local and distributed caching to speed up commands and tests. NX also offers controlled code sharing, allowing you to share code easily while restricting access to specific projects. Consistent coding practices are enforced through linting rules and generators that automate code creation. NX also provides an accurate architecture diagram, allowing you to visualize the actual dependencies in your code.An NX workspace typically consists of folders for apps, libs, and tools. Apps are the entry points into your application, while libs are shareable pieces of code that can be split up for better performance. The workspace.json file helps configure the projects and executors.

Okay. Okay, I will keep going then. Ricardo, put your, okay, if you have questions, put them in the- put them in Discord, and I can, and Zach will put them up to me. All right, so. The, so faster command execution. There are, here are the ways that NX makes your commands faster. So these are commands like build and test and lint and end-to-end tests, other things like that. So NX provides a concept called executors that run commands. And it's a structure to put your commands into NX so NX knows about them. So there are two main ways that NX speeds up your commands. Well, the first is NX affected, because NX understands the dependency graph of how different projects relate to each other, and how they depend on each other. You can run NX affected with a target of test. And it knows it looks in your does a git diff and knows which files are changed, so it knows which projects have been changed. So it knows based on which projects depend on the things that you've changed, it can run the tests of all the projects that are affected by your change. And it knows that there are other projects that can't possibly be affected by your code change. It speeds up your tests by getting rid of things that can't be affected. So that's one way of speeding up your tests or your commands. The second way is through local and distributed caching. So NX by default will cache your test command. So if you run the test command on a project without changing the code, it can recognize that your code and your configuration options you passed in your test command have already been run once. And so it can look in the cache and say, instead of running all these tests again, I'm just going to spit out the terminal output that was there before and give you the local file system changes that came before. So it can cache your build as well. So you can run the build, and then delete the disk, and then run the build again. And it just pops up that disk folder again, and just pulling it from the cache. So it can go from taking 30 seconds, because that's how long your tests take to run, to taking a second or two, because it just pulls it from your local cache folder. Then distributed caching. So the local caching is free. It comes with Nx by default. Distributed caching is NxCloud, so you get five hours for free, but basically it takes their cache and it shares it across your whole organization. So one person can made a change, run tests on their own PR, and then tell somebody else, hey, there's something weird with these tests. Can you check them out? And somebody else pulls down that PR, that branch, and runs tests and uses that same cache that ran on the first person's computer. So this can become, be really powerful and really speed up people's workflow. Basically you can only run, never test the same code twice, is the idea there. So Nx cloud, you get five hours a month for free, five hours a month of computation time that you get saved on, but then you pay for more than that.

All right, second thing that Nx does for you, it gives you controlled code sharing. So you want to be able to share code easily, but you want to be able to restrict and share just the things you actually want to share with other people. So each library, each project has an index.ts file at the top level, and whatever you put in there is available for anyone to use across the repo. But if you don't put, if you don't export things in your index.ts file, there's a lint rule that blocks people from trying to reach deep into your project and pull out things that you didn't intend for them to actually use. So you have that actual boundaries around your code that way. Then you can also use tags to say, hey, actually this project is available for other projects that are on the same app, but not that other app over there. So you can put tags on your projects and add some lint rules to put it even more structure around which code can be used by which other people inside the repo. Then you can use publishable libraries to push your libraries up to MPM if you want. And you can use the code owners file which is a GitHub feature that will force any changes to that code to be reviewed by a certain set of people that you decide. So somebody can't come in and change a particular part of your code without someone on your team actually approving that. So they can see it, they can change it, but then it has to be approved by somebody on your team before it gets merged in.

All right, third, you get consistent coding practices. So NX comes with some linting rules and that linting tools that's set up by default across your whole repo. You can have global linting rules and project-specific linting rules. NX also has a powerful tool called generators which allow you to create or modify code in a systematic automated way. So you can take a, like all those workflows that developers use, like for instance, to spin up a new route for your application. Instead of having a seven step process in your README file, you can have a generator that will actually do that for you. And so instead of people forgetting a step or doing a step incorrectly each time, you can automate that in the README file, just instead of having a seven step, it just says one, one thing, just use this generator, fill out the inputs that it asks for, and it'll create the code that you need, and it'll be the same each time.Then there are Narwhal plugins. So NX itself at a core, the core piece of it, NX understands the dependency graph and understands how projects can depend on each other, gives you the effective tool. Then everything else that comes on top of that are plugins. So plugins give you things like a framework support tooling that goes around your framework, like Cypress and Jest and Linting, things like that. So Narwhal gives plugins that handle the configuration of those things for you so that you can modify the configuration if you want, but because it handles the configuration for you, you can just jump in and do the pieces that you actually care about, get to coding your application rather than doing the configuration of storybook or Cypress. Then there are also community plugins that you can make your own plugin if you want to, or there are community plugins for tools that Narwhal hasn't created their own plugin for.Okay. Fourth thing, NX can give you an actually accurate architecture diagram because you can run this dependency graph and see what your actual code is doing rather than what you think it's doing. You can see which pieces of your application really depend on each other and not how you wish they depended on each other. And then as code changes, you can actually see up-to-date dependencies rather than a year ago, what the dependencies used to be. All right. So that's what NX does on a high level. Let's look at specifics of what an NX application, NX workspace generally looks like. So this is the file system here. You have the top level we've got these folders, apps are where you're going to put applications. So the projects inside of an NX repo come in two basic flavors, you got applications and libraries. Applications are usually we try to keep them as thin as possible. And they're your entry points basically into your application. And then they'll depend on libraries that do the bulk of the work. Libraries go in the libs folder. They can be they're shareable pieces of code or pieces of code that we just wanna break up and split up so that you can take more advantage of the NX effective the command and the caching. So the more you split up your code into libraries, the more NX is enabled to speed up your commands, your tests and build and things like that. This folder is where your output goes when you build your applications. Tools folder is where you can put scripts or your own custom workspace generators or custom executors that will run your commands. Workspace.json, this file helps you configure how your, what executors are gonna run against which projects. So it configures your projects, your libraries and applications, and says, hey, when I run nx build my application, this is the command that actually gets run. And these are the options that are available on that. nx.json has some more configuration for your projects, your applications, and libraries. In here you'd have configuration for nxcloud and configuration for the tagging structure of how you wanna... If you wanna say certain kinds of libraries can only depend on certain other kinds of libraries, this is where you would do that. At the base level you have TsConfigFile here that sets up TypeScript configuration for your whole repo. And there are several different configuration files that have a workspace level configuration and a project level configuration file. So if you have a certain project that needs a different setting for TypeScript than other projects do, you can set that at a project level. And override the... So the project level config inherits from the workspace config and then can override it, can extend it and override it. And the same thing goes for Jest and for things like ESLint and other tools.All right, so in order to create your NX workspace, you just run this NPXcreateNXworkspace command. And that workspace name that you fill in does three things. It sets up, it names your directory. It sets up the path alias, which is when you do import from at my org, that's the path alias that you use, and then your npm scope. So whenever you, if you ever wanted to publish a library from your repo, it would have that at my org as the scope when you publish it. These three things you can change later, you can make them different from each other. But by default, they're all the same thing when you run create NX workspace.We're gonna do the first lab here. I think this is a good pause, Zach, are there any questions in the discord that we should bring up? One interesting thing I came in in the chat was how is NX different from Lerna? Which you could address maybe briefly. Isaac, do you wanna field it? Sure. Yeah. You're on a roll man. Keep going. Well, I've been talking a lot. If you have an answer, go for it and I can fill in. I'll give you a break if you want. So one of the things, one of the big breaks we take from Lerna is Lerna tends to do a separate package JSON per project. And yeah, Isaac's bringing up. This is a question we get it quite a bit. So we have Victor, he's our head of engineering. He's put that blog post. I'll make sure to put a link into our discord if you wanna learn it more. Like one of the bigger points though is like I was saying, we split up projects so that in Lerna, each one has their own package JSON. So you're essentially like taking all your projects and hoisting up a layer at the Lerna and everything else. All these projects are mainly segmented still inside of Lerna. NX is taking the opinionated approach of trying to unify these things more. So there's one package JSON for most scenarios. If you get into like buildable libs or some node solutions, we do need a package JSON per file. But for the most part, they're extending the base, the root package JSON. So a lot of this is based around us creating a system for how your dependencies map, how they work and keeping those consistent and unified across all your different projects. So, I dunno, I think that's a fair representation. Yeah, I think so. So Lerna, you can run like your tests, all the tests across your repo in Lerna. But Lerna doesn't have the equivalent of the NX effected command. Also, I don't think Lerna has any caching mechanism. And, there's no... Yeah, Lerna doesn't have the generators to create your code. Lerna does other things that basically... For me, Lerna feels like a multi-repo approach, but they just happen to be in the same Git repo. Yes, that's my perspective as well, very much so. NX feels much more unified in that way, like with the whole dependency graph and the optimizations we run off of that. And Lerna's a good tool. If you like using it, you can keep using it, but I personally like NX. Okay. 100%. Lerna is great.

Lerna is great. I don't want to dunk on it, but yeah. NX is different in some of the stances we take. I'll say that. All right. Go ahead, Isaac. I think that's all we got for now.Okay, cool. So I'm gonna be going through the labs in this repo here, the NX workshop. Good, we've got two and a half hours. And so you can scroll through here. We're gonna be building this application, just a silly little application here. If in order to run this lab, we'll need Node and Yarn. You probably already have those things installed, but if not, you can install those. There's some icons here that can help you.Let's see. So these are all the labs that we're gonna be doing. So let's start. I'm gonna click through this, go into lab one here. So generate an empty workspace. So let me pull up, I'm gonna do a brand new, I'm gonna do it here. So I've cloned the repo here, and if you want to, if you want to just jump to a particular lab, let's see, I'll just do it this way. If you wanna jump to a specific lab, there are branches in this repo. You can just jump to starting lab number and jump straight there. But if you wanna go through the whole thing, the whole workshop, I recommend just going to starting a whole new folder and running everything from the beginning that way. So we wanna generate an empty NX workspace with the BoardGameHorde company. We're gonna name it BG-Horde and we're gonna make it an empty workspace and say no to NX clouds. So let's go through that. And if you get stuck, every lab has a solution file that goes with it. And so you can copy that and run it here if I can paste. So we're gonna run this and we'll wait for npm install to happen. Okay, let's see, okay, and this is what happens, oh, it already exists. So I'm going to delete that. I have run through this workshop before. This is the equivalent of walking into some place and automatically connecting to their WiFi, right? Right. You've been here before, Isaac. Yep, okay, so I'm going to run this without the preset just so you can see what happens if you don't specify it. So here it asks you what presets you want. If you want, you can just pick React and it'll spin up some things for you. But for our workshop, we're going to pick MT. Come on. Isaac, do you recall off the top of your head how to specify yarn instead of NPM? There's a command-line argument for that, right? There is. I'll go look for it if you don't recall it off the top of your head. Yeah, I think it's Package Manager. We're going to say no to NxCloud, for now, and then we'll add it later. Actually, that's on day two of the workshop, so we won't add it later, but I'll point you to where you can get to day two of the workshop if you want to do that. Okay. So I'm going to open up the BoardGameHorde. Here, can minimize that. What is that? Okay, so now we have... So this one used npm install, which is fine. You can use npm or you can use yarn. Either one works, or pnpm. And so here is what our repo looks like. So we have no applications, no libraries. Our package.json has a few small scripts created for us, but they're not gonna do anything because we have no applications. And has just some, this is like the core of NX here. And a few helper packages. So not a lot going on here. Let's go to Lab 2. And Lab 2 has some slides to go with it. So the core of NX doesn't do a whole lot. So we need some plugins. So in order to see what plugins are available, you can run NX list. And that will show you what plugins are installed in your workspace and some plugins that are available to you. Then you can run yarn add plugin to add it to your repo. Like to add the Nest framework to your repo, you can do yarn add at narrow slash Nest. And then you can run some schematics that go or some generators that go with that plugin. Schematics is a particular type of generator, but we can just call them generators. So in order to run a generator, we can run NxGenerate, the plugin name, and then a colon, and then the generator name, and then followed by whatever options.So for example, you can do Nxg, which is short for generate. At narrow slash angular is the plugin name. That's just the package name and package as json. And then colon, whatever the generator name is, application in this case, and then the name of the application, my-app. So if we ran this, we could also, if you don't want to use the command line, you can use the NxConsole VSCode plugin, and that'll give you the, give you a form that you can fill out, or you can just type in the options that are, that you want to set. So there are normal maintained plugins for frameworks, for tools that help you, for end-to-end tools, backend, frontend frameworks, all sorts of generated code that you can create. Then you can also make your own workspace generators, which are, you can do lots of different things with workspace generators. You can just combine the provided generators that we have and specify specific options and say, hey, in our organizations, we only use this kind of, these kinds of styles. We're gonna use styled components for everything. So don't even give us the option of choosing something else because that will be the wrong choice in our organization or different other things you can set. Okay, so let's do those, do those commands. Let's look at the lab two. If I go back here, click on next lab, it's taking me to lab two. So we're gonna try to generate a React app. So once we finish this, this is what our app should look like and this is what our file structure should look like. So let's do, I'm gonna put this off the side here and this off the side here, I'm gonna do that. Right this. Right, so let's do, so if we run Nx-version, I have Nx installed globally, but if you notice Nx-version picked up my local version of Nx. So it recognizes, hey, I'm in an Nx workspace and the version I should be using is the version that's in this workspace, not the globally installed one. So it's smart enough to notice that.

So if you wanna install it globally, you can run this command and install it globally if you don't have that installed globally yourself, or you can do Yarn Nx, and that will do the local version of it here. So what is there? All right, so if we run Nx List, here are the, so installed plugins, we have Jest, a linter in the workspace, basically the core comes with it. And now here are some plugins that are available that we can choose from or community plugins that do different things. The Fortnow, all react plugin. So let's add that. We're gonna use NPM instead of Yarn. While here, let me run Yarn once. Yeah, I'm gonna run Yarn because all of the instructions are gonna use Yarn even though I used NPM install earlier. And we're gonna install that. Yeah, for the people asking in chat, even if you set things up without setting your package manager at the start, you can always do what Isaac's doing right now. And essentially, I think all you need to do is remove the package lock Json file in favor of the Yarn lock, and you'll be set for Yarn. And then you're set, yep. So actually, we'll do that as soon as this finishes. Okay, so that happened. And I'm gonna delete my package lock.json. All right, so we've got that. And I'm need to add material UI core. We could have put this on the same line, but we'll do it this way instead. All right, so now we've added those two things. So please follow along yourself. That way you'll be confident that you know what's going on rather than just watching me. So we're gonna make, we're generating a React app called store here. And we want to add React router if we're asked. So let's go to, I like to use the nx-console. Here let me hide some of these so you can see. I like to use this nx-console plugin here. And if you want to add that yourself, just search for nx-console. And it's this one. So this is what you wanna install. And it'll give you this panel on the side here. And I can click generate now. And it shows me all the generators I can pick from. So I want to create a neural React application here. And now I'm gonna hide this so when you do this, you'll have more space to see things. But I wanna call my application store. And every time you run it, it will launch a terminal here and do a dry run of your command and show you. So dry run means it's not actually affecting your file system, but it shows you here. These are the files that you'll be creating or modifying if you actually were to click the run button. So that looks about right. Let's see here, source, styles. I think actually I would like to do SCSS for the style. Directory is fine. So you can nest your applications or libraries under directory. Choose to use class components or functional components. Functional is the default. Cypress test runner, you can have no test runner if you want, no end-to-end test runner. Global CSS is off by default. So it will use CSS modules by default. And we'll use Linter. You can use ESLint or TSLint. ESLint is the default. We're gonna do yes to routing here because we wanna do the, make sure you add React router when asked. Okay. So this, obviously, you could also do this from the command line. It would be, you do write ndx generate, narwal-react-application, give it a name of store, style-css, and routing. Or if you did it from a command line like this, ndx generate narwal-react-application, we call it store, it'll prompt you with some, what do you wanna choose here? So I'll do S-C-S-S, yes, I want to add React Router, and now it's running. So either way works. I personally prefer to use this, to use this edX console plugin because it shows me all the possible options and it's just, the way my brain thinks, it feels nicer. But you use whatever you prefer. Okay, so we've created an application. Let's look at the files that are generated here. Hold on. All right, well, I guess it doesn't like me making that bigger, so I'll make it bigger like this. There we go. Okay, so now we have a store application here and we've got some CSS, a TSX file. All right, we're going to create a fakeapi.ts file inside of source here. fakeapi.ts and we're gonna copy the code from here because we're not really teaching you how to do React. We're just using React within an NX repost. So we're gonna give you a bunch of code to copy and paste. All right, examples. We can do some basic styling here. So we're gonna do the, this is the app.tsx file. So I'm gonna take that and go in here to app.tsx. Just paste over the top of that. Okay, that's good. And then the, nope, we found a bad link. All right, well I will go to here and go up a level. app.module.scss. This is the CSS that we want. Okay, paste that in there. I see, so that should be app.module.scss in that link. Okay. All right, the other thing that we need to do is put the images inside of this assets folder. So I'm going to... We could clone this and copy it down, but I've already done that, so... I'm going to take the, look under here, well, just under examples in here, examples lab2 assets. Gonna copy these and put them inside of the assets folder. The board game puns are 100%, the best part of this works fine. So if you're familiar with these, hope you enjoy the week. All right, so now we've copied over those pictures and now we can serve things and let's see what it actually looks like.

So we do nx serve store. Make sure I've saved everything, yeah. I've saved everything. Nxserve store and let's see what this looks like. So, localhost 4200. Good morning, Isaac. There we go. There it is. All right, so this is our application. We have three board games here with silly names and they're styled, but they don't do a whole lot just yet, but it works. So that's good. All right, let's admit this, call it lab two. And let's see, I think I have some, okay. Isaac, you probably want to add the files before you admit. Cause I think you only- No, yeah. I didn't add them. I thought the dash A was an add them. Yeah, no. You could. Yeah, yeah. Lab two again. No, VS Code will do it for you. Cool. We'll add them for you. All right. Yeah, it's been a while since I actually did Git from the command line. I usually just do it from here cause it's... Yeah. I like visual things. All right. Zack, anything from Discord that I should talk about? There were some questions about if there was a similar plug-in for IntelliJ. So we have, there was the third party one. I don't recall how you get that. I think, I don't use IntelliJ. Do they have like a apps space? They can download that? Yeah. So if you go to nx.dev, we have a page in here. NX editor plug-ins. And so NX console VS code plug-in, that's actually maintained by the NX team, but there are a couple plugins that are maintained by other people that you can use here. I don't know, I don't actually use WebStorm, so I haven't used these myself. But you can try out these two and they do similar things to what NX console does. So Zach, if you want to paste. I'll grab that link. Okay. Thank you. Isaac, I think we're also, some people are not able to keep up. Do you wanna maybe give a summary of the previous lab before we move forward? Sure. So summary, what we've done with Lab 2 here is we have created an application with React here. And we've made a, let's see, let's look at the whole... So we looked at plugins that are available that are available using the nx-list command to see the plugins that are in our workspace. Now you can see that we have normal react installed and some of its dependencies, Cypress and Storybook. We're actually using Storybook just yet, but it's just there. So Storybook itself is not installed until you use it, but the generators are available for us to install it if we want to. But there are other plugins that we can add if we want to, and then it shows the community ones. So we saw how to add a plugin using yarn add, whatever the name is. Yeah, I think, Storybook. I think as like if you do the command nx-list and then pass the name of one of these packages, it will give you the instructions on how to install it. Yeah, like that, you need the- Yeah, so nx-list at GNARWAL slash React. Yeah, so if you have it, it's going to show you the things that plugins bringing. So here is showing all the generators that came in GNARWAL with GNARWAL React. If you do one that we haven't installed yet, it will give you instructions on how to install it. So yeah, like that. So it will tell us it's not currently installed and gives you the instructions. This is how you could then add this plugin to your workspace. So that's probably the key part of getting this stuff in. I don't think we're doing all that much in terms of actual code for our React app. It's just kinda getting the plugin and showing, okay, this is how we can run a generator to then create an app from that plugin and using the resources provided by that plugin. Right. So I didn't spend any time at all looking at this code. This could be whatever we want, but for our purposes, we don't care what's here. This is basically a black box. Other workshops, I'm sure, will teach you React, but we're gonna teach you how to use React with NX. And so we got the CSS here. So this file was changed, this file was changed, we made this fake API file, which has all the data for our board games. So we got three different objects in here, and then we put in three images in the assets folder. And all these files, you can find in the NX workshop React repo. You can find them inside of the examples folder. Of your cloned repo. So I went under lab two, there's this app dot module dot SCSS file. App dot TSS. And then, these are all the, this is all the code that I copied over for lab two. Yeah, so aside from generating the app, most of this was copying and pasting those resources over. For anyone following along. We do have a question here, Isaac, maybe you could address it quickly. What Git blame like extension are you using right now? What am I using? That's a good question. I've been partial to Git blame myself. Or no, Git lens. Git lens is the one I use. That may be the one you're using as well. I'm not sure. Yeah, installed extensions.

Let's see, what am I using? Yeah, git lens, that's what I'm using. Yeah, so Git lens will give you like line by line blame right there. That's what you're seeing right there. It also enhances the Gits plugin piece on the left hand side. So you can actually step through commit, commit per file, I think by line as well. So very handy. I love Git lens. Yeah, it's really useful. Alright, let's move on to- It's got nothing to do with edX though. Yeah, that's fine. But that's all right. That they'll be asking what font I'm using next, but that's all right. We can share those things too. Alright. So before lab three, we're going to talk about executors. Now executors are what we use to run commands inside of an edX workspace. So if you look at your workspace.json file, it's going to look something like this, where you'll have projects, on line three, we have projects up here, line four is a specific project named review. And then underneath architect, or sometimes that's called targets. Let me just double check real quick, what got generated? We've got projects, store and targets. Yeah, so underneath targets here, you'll have different names for the different targets. So you can run NX build store. We'll run this executor here. So you have, this executor tells you where the code is located. Outputs tells the caching mechanism where the outputs are being placed, so it can cache those. And then options here tells you, what can you change about this command? So these are all, build configuration settings here. And then you can kind of bundle up your options, like as a set of options together underneath configurations. So when you're building for production, these are the options that you want to overwrite and use. So this is like the default options, and then if you say, dash dash configuration equals production or dash dash prod for short, it'll do all these options in here. And you can dig into, on nx.dev, you can look at these specific, I'll make this bigger, specific generators have, or specific executors here, I think it's the narwal-web. Narwal-web build executor tells you what each of the properties do, if you want to dig into what those specific things are. I'd like to highlight too, Isaac, if you don't mind. The nx-plugin is really great at that kind of discovery, I think. So if you go through and click on a, so if you go to the plugin and it'll show you the projects. It'll kind of give you which options you have for running as well. Yeah, so if I click here under build, that just runs it, that's not what we want. I think there's a way to get the form for the builders as well, but in general, I find that, what Isaac just did with just the play button, super helpful in terms of just saying, okay, what do I want to do? Okay, that's what it is. I use it all the time because I often forget the names of projects too. Right. That makes it helpful. So to get the form, you click up here, you click on build and you pick your project and then this is the form of all the different options that you have. Yep. And that has the same descriptions on them that you would get in our docs with the API stuff. So yeah. Yeah. Yep. Okay, so let me keep going through my slides here. Okay. So that's where you configure your options that are available. And your workspace.json. You can run those executors from the command line using nx run the project name and then colon and then target and then whatever options. So to serve your app, you can do nx run my app, colon serve. Or there's a shorthand for a few of the built-in targets like build, build, lent, test, serve, and I think end-to-end. You can do a shorthand, which is you put the target in front and you do nx space target space project and then the options afterwards. But the target can be any name you want. You can create a custom target that's like generate documentation and that one won't have a shorthand for it, so you'll have to run that using the top line up there, nx run my application, colon generate docs space, whatever options. So that's how you'd make your own, you'd execute your own custom executors. Same thing with nx console, which I showed you, and we're ready to dig into lab three and actually run some executors. And just a quick time check, we're one hour in and have two more hours to go. So I think we're on. Yeah, I think we're good. Yep. I think we're fine. Alright, so lab three, we're gonna look at, figure out what a target and an executor are. We're gonna invoke some executors, run them, change some options. And so the app itself, we're not gonna actually change anything about it. We're just gonna play around with some executors. So we want to build the app. So in order to build the app, we need to run an executor. And so here's the hint. You do NX, and then the target, the project name here, and then your target. This does not work super well on dark mode. But I was just gonna say, I had some of that. But yeah, that was just kind of trying to show the stuff we've already walked through here. So like I said in the chat too, I love using that plug-in as like a jump off board. Because what the plug-in does is essentially just construct that CLI command for you and then run it. And it'll show you what that command is as you run it. I'll use that as a jumping off point and then like copy that and paste it into my terminal. And then I just press up from there. So I don't have to run it again. So that is super helpful for understanding that. So the shorthand here for building the store, you can do nx build space store. And that takes all of the default options. And we can see when that finishes. Cool. We should see a dist folder. Okay, now we have a dist folder and dist apps store. And we've got our built application here. Let's see. So what's next in our lab? So we see a dist folder, check. We can push this up to a server and it would all work.

So let's look under project store target and not architect build. So we're gonna look at that, looks based on JSON. So we look into here under projects store targets build. Okay, so we found that. And this is the target, the build target for our project. And it has an executor option which points to Narrow Web Build right here. So this is basically telling us telling the target, hey, when this gets run, this is the code you wanna execute. All right, so the assets, we put the images in the assets folder. So let's look in here and see where those assets are set up. So underneath our options here, if you scroll through here, this is where those assets are configured, where we say, hey, pull in the favicon that's defined there and pull in everything that's defined in the assets folder. So basically it's gonna take under apps, store, source, assets, everything in here is gonna copy it to the dist folder. And now we've got the assets folder. Same thing with favicon.ico. It's got copied over to here. So underneath this favicon, got copied over to here. So if we wanted to change that, we could also copy over, let's see, let's do something silly. We'll add in copying over the fake API.ts, which you wouldn't actually want to do. But if I run this nxbuildstore, it'll copy over Favicon fake API in the assets folder. We'll let that run and come back to, there we go. So now if I look in the dist folder here, now the fake API got copied over, which we don't actually want, so let's go take that out. Okay. All right, so now we wanna send a flag to build it for production. So the way I wanna do this is, I'm gonna do build here, store, and I wanna look under here. So to build it for production in the NxConsole plugin, we have two different configurations up here, so the default has everything here, but then if you click on production, it changes all these settings to be what we chose for the production configuration, and you can see if I were to, let's see, if I make a change here, I guess, then it'll open up the dry run. I guess it doesn't do, I guess, yeah, executors don't do a dry run. If I click on run here, it does NxBuild store, and then all of the options that are for production. The other option is if you wanna do it from the command line, you can do NxBuild store and do dash dash prod for production, or configuration equals production for the long version of that. So it shows you that this command here was converted into this long form. So you can see the NxBuild store, got converted to NxRUN store build and then the production, the configuration is after another colon here. So now we run it with production. We can look at our disc folder here on step five, and it's created a licenses.txt file. Let's look in here, disc folder. So now it's bundled up all the licenses from our dependencies and packages them all in here. So we can check and say, okay, are we, you know, abiding by all of these licenses. So you can have your, your legal team look through that. Serve also is an executor. So we can, let's minimize this. Serve also is an executor. And what this does is it, it has a different executor inside of here, but it uses the build target. So it uses all the options that are set up under store build and then, but then instead of building it on your file system, it serves it up to you. And so it also has a production version and it'll use the production build configuration as well. So you can stack targets on top of each other. Okay? One thing that's also nice, because it has NX has local caching. I can do NX build store again and it happened instantly. And you can see I did the non-production version and there's no license file in here. And if I switch to NX build store dash dash prod, that's also cached and you can see the dist now has third-party licenses that TXT. Yeah, as long... Can you go back to the workspace JSON real quick? There was a question that came up. So regarding, can we look at the build again? I think there's some configurations in there where we can use something from the output. My, okay, options, line 31, I think is what I'm looking at. Line, yeah. So, this, well, we're looking at ways of configuring. There's a question on how do we configure a build with environment variables? I think we have some capabilities for that. Thought maybe that was it, but no, it's not. But yeah, there's other ways of setting that up. Let's see if I can find... Next.dev, environment variables. EMV files. EMV files. Okay, I don't have it written there. Let me see if I can find... Okay, there's a lab that comes later where you can use EMV files that I'll show you that when we get there. Cool. Sorry to jump ahead. That's fine. Yeah, we'll just move forward. Sounds good. All right, so let's look at, let me see if I have anymore slides. I think this is the last set of slides that we've got. Okay, I think we'll do one or two more labs and then we'll take a five, 10 minute break and then we'll start again. Okay, so far we have all of our code inside of one application. So this, I mean this works functionally but it's, you lose a lot of the benefit of, that NX provides. You need to split things up into multiple libraries, multiple projects in order to gain the benefits of your modular code. So libraries come in four different types, you can subdivide your libraries differently if you want, but these types that we've seen are useful to people that we've worked with. So the first type is a feature library. This would be like a route level library that it can contain UI components, it can contain network calls to data access, to access your data. It basically can contain anything you want, but it's like a high level library. Then there are, and we usually prefix those libraries with feature dash or feat dash. Then there are UI libraries, which are presentational components that you can share across multiple places. These contain components that don't do any network calls. You're going to provide data. You're going to communicate with these components purely with props. It's not going to make any network calls, not going to access your Redex store or anything like that. Then there is data libraries. These are libraries that don't have any UI associated with them, but they're going to do network calls, they'll do interaction with, these can contain your Redex store slices, things like that. Feature libraries can use the UI libraries and the data libraries, but not the other way around. Then util libraries are the lowest level. These are going to be your pure functions, helper functions that used to do different things. Any library can use a util function. But util libraries should only use other util functions, not going back up the hierarchy, I guess.

When you make libraries, you can put them inside a directory structure, you can you nest them inside of directories. You don't have to worry too much about what folder they go in at first, because it's it's easy to move libraries around. You can run a generator that modifies your code to move things around to different places. So you can reorganize things as the code evolves and changes. Generally, we recommend having a so if you have a store application, all the libraries that are specific to that store application should go under a store folder inside of libraries. And then as you add another application in, you can have a separate folder for that for libraries associated with that application, say your backend API libraries. And then for libraries that are used by both or by more than one application, you can make a shared folder that those libraries would go in. Yeah. So that's a basic useful directory structure to get started with.

Obviously, your organization is gonna be different and you can make your own decisions that make sense for you. So this is a very common question. When should I? So I've got new code that I'm gonna write. Should I split it out into a separate library or should I add it to an existing library? And this gets asked so often that we have a page on our docs specifically for this question, and switch to React, and let me pull it up. Library, creating libraries. Should I make a new library or should I add to an existing library? So this page is gonna list out, the standard answer is that it depends. So this list out some reasons why you'd wanna make a new library and some reasons why you would not. So generally all the things that NX gives you happen on a per project basis, per library basis. So if you don't have any libraries, then NX is not gonna help you. If you have everything all on one application, NX can't, you know, the caching mechanism is gonna cache just your application. So any change you make to that application is gonna break the cache. Whereas if you split things out into multiple libraries then it's gonna cache on a library level and so that the cache is less likely to be broken. Like the whole cache doesn't get broken at once, just specific parts. And then the same thing NX affected will not be all that useful if you have everything all in one application. So the more you split things up, the more NX affected can help you. The other thing is your dependency graph architecture. If your architecture is this is my whole app then that's pretty meaningless. So the more you actually split things up, your dependency graph will actually be useful for you. Then you can actually enforce constraints if you split things out into separate libraries. You can say, hey, these kinds of libraries can only depend on these other kinds of libraries. And then you have your enforce boundary, your API for your library. If you don't have things split out then you're essentially back into a code co-location again in terms of how you share your code. Anything inside of that application if everything's all in one application any part of that application can pull things in from any other part of the application without any structure put into it. So if you wanna enforce constraints you wanna separate things out into separate libraries. On the other hand, there is a cost to making a new library yeah, there's the cost of your own mental understanding of what's going on. So if you have to look at five different libraries to understand what a particular feature is doing then that's probably too many libraries. It's gonna be hard for you to keep all that in your head and understand what's going on. And now on the other hand sometimes there's code that changes a lot and the constraints that are in place are too restrictive. And you wanna have more freedom to change things a lot. And so then you actually want things to be in all in one library and not have those constraints on yourself. So you're the only one that knows how to answer these questions for yourself. But in general, you wanna split things out in more libraries in order to take advantage of NX and put libraries together in order to give yourself more freedom and flexibility to do the kinds of things that you wanna do. When you run the dependency graph, you can see how libraries dependent each other. And let me actually well, we'll do that actually in the lab, we'll make ourselves a library and run the dependency. Run the dependency graph. We have a quick question, Isaac. While you're in a little low, asking about constraining importing of specific external libs to a specific other NXlib, which I don't think we address in the labs we have but there are capabilities for this, which we had mentioned before in terms of setting some rules on how the graph can import from each other. So I'll post the links, we have some documentation on that if I recall correctly. I'll make sure to post that here in Discord. Setting up tags to, so another thing that comes up in that question, when I say libraries, I'm talking about pieces of code, like modules of code inside of your repo. I'm generally not referring to an NPM package. Those are also called libraries in the greater developer ecosystem, but yeah usually in this workshop, when I say libraries, I'm talking about an NX library. So you can set up rules on how your library, your NX libraries depend on each other. I don't think you can set up things saying, hey, these libraries cannot use this NPM package. Yeah, I'm sorry. I think I misunderstood the question. I think that was the spirit of the question was can we limit a certain NPM package to a certain lib. Yeah, to do that, you would need to write a lint rule for that and I'm sure there are rules out there, and so you would set that in the, so I can actually show you how to do that. So say, so there's the global ES lint file. So these are lint rules that'll apply to the whole repo, but if you say just the store application itself, you wanna apply a rule to just the store application, you can, oops, I didn't wanna do that. I'll just close this and open it again. You can put lint rules that are just for this project inside of the ES lint.rac.json file that's just for this project. And so this is where you'd put restrictions on which things you can import in here, things like that. All right, let's make a component library. So the application is gonna look identical after this. We're just gonna restructure the code a little bit. Here's what the file structure is gonna look like when I have a UISHARED library. And that'll basically be the only change. All right, so I think I've, I have stopped the NX serve. All right, so now we need to make a library. A library, so anything that's making code, modifying code, that's gonna be a generator. So let's see, let's look at this hint here. It's a generator. We used it before, but instead of an app, we're gonna make a library. So we can use the dash dash help command to figure out how to use that. So inside of here we can do NX generate. So we use the React plugin. And make a library, or we can abbreviate it to lib, and let's use dash dash help here. So you can obviously use NX console, or this is how you would do it from the command line. So you can specify a name, and I wanna specify the directory that it goes under. So we're gonna use this dash dash directory flag here. Let's see. Okay. So we're gonna do NX generate, and what is the name that we want it to be? We want it to be UIShared, and we want the directory to be underneath the store folder. So UIDashShared, and let's say I mess up the name here. Directory libs store. Let's see. Is that gonna do what we want? So let's look under here. Oh, wait a second. That's not right. We don't want LibsLibs, and our name here is UIDashShared2, which we didn't actually want. So let's, since I've committed everything here, I can just revert back to a clean Git history and run it again. So we just want the directory to be stored there, and we're gonna correct our name here. Now, the other thing we can do is you can do dash dash dry run here, and that will run the generator, but not make any changes to the file system. This is just an empty folder here. Let me just delete that. No, I really meant to delete it. There we go. And now we can see what would have been changed if we actually did it without the dry run flag. So this is under lib store.

That's good. And UI share, that's the correct name. And I think that looks right. So I'm gonna do it again, without the dry run flag. So that saves me from- Well, I was expecting that too. Inside of the plugin, as you, like on changes, if you ever touch the form, it's gonna run that dry run in the background. So you can see this kind of information as well. Yeah, so NX console. If I run generate library, and something here. So here, this is the dry run again. Yep. Yep. So this is the same thing, just with the NX console. Okay, so these changes are made. Let's double check that this is right. Store. Oh, that's not right. I don't want it stored. Should have checked the dry run. I should have checked the dry run. I thought it was right. All right, yep, okay, now let's revert again. Yeah, this highlights why you always want to have relatively clean get trees before running some of these, because if you do make a mistake, it's much more convenient to get reset than to figure out what all happened. There you go, sweet. All right, store. And, okay, so that's stored, we don't want. There we go, lib store, UI shared, yeah, this looks right. Okay. Now let's look at, so we're gonna generate a React component called header. So I'm going to actually commit this so that if I mess up the next generator. So we do, call this create UI shared library. I'm gonna generate a React component here. And we want to call it header and the project we're gonna put it in is store UI shared. Let's see, it's under header store UI shared. That looks right. Any other settings that we need to do? Header, and we want to make sure to automatically export from the libraries module or from the libraries index.ts file. So underneath here we wanna export. So let's check that and actually check it. And this index.ts file has been updated. So that's actually what we want. So we're gonna actually run it. So now we can see that it actually made changes. Come on, there we go. So now we can see that it actually made changes here. So it exported the header component from our index.ts file. If we did not export it from here, then we wouldn't be able to use it anywhere else. And actually I'll show you that level later. I'll remove it from the index.ts file and show you the error that would happen. That's super helpful for that slide as it was shown earlier, setting like some private resources you don't want other projects importing. Yeah. Okay, so we replaced the header components code with this. Copy that. We don't want on, in here, this header components code. This. Okay? Header.tsx has been updated. Generator options. We did that. We did this. Okay, now we're going to use the new shared header component that we created. So inside of app.tsx, in here. Okay, now we want to use the component. So, when we've, when we create a library inside of an NX repo, there is a path created for it in a TypeScript path. So we can import it using our, the namespace for our repo, at bghorde. And then you pass in the rest of the path to the library. So it's underneath the store directory and it's the name of it is ui-shared. So now in here, we can see there's the header component available to us and the store ui-shared component. So now we can use this header component. And let's see, where do I, I forget where we want to put it, if it's inside the container or outside the container. Let's see, so we're gonna import it like this, and then we put it above the styles.container div. So here, that. Oh, and then we need to wrap this in a fragment here. Is that right? Here we go. All right. So let's make sure we got this right. Say it says to wrap their app component in a fragment. Sometimes TypeScript doesn't pick up the fact that we have a new path here. So after you generate a library, sometimes you have to do restart TypeScript server. If you do Command Shift P and you type in restart TypeScript server, you'll see this option. One thing to watch out for is if you're not in a TypeScript file, that restart TypeScript command is not available. So you have to actually be, have a TypeScript file open in order to see that restart TS server. Okay. All right, so let's serve the project and let's see what it looks like. So we're gonna NX serve, store. So quickly recap as it goes I'm like half following along but at this point we have created a new library. We've created a component in that library. We are importing that component into our app and that's where this new purple header is coming from. Is that right? Yeah. So this is our header component that we just made. I can inspect this and let's see. Here it is header.

So there's our header component that we made. All right, I think, let's do a, like a 10 minute break maybe. Actually let me finish showing this off and then before we start the next lab, we'll do, we'll do a 10 minute break. Okay, so let me just show the dependency graph here. NxDevGraph can show you how your projects depend on each other. And I'll show, select all. So we have zoom too fast. So we've got our store application that depends on the store UI shared library. So we can see, let's see, let me modify this here. So if I comment that out and I run the dependency graph again, it knows that the store application is not defined. Not really depending on this. So it's, you know, it's changing the dependency graph based on your actual code. So it sees that there's this import happening. And so it says, oh, there's a dependency. So I need to update my dependency graph. The other thing I wanted to show off is the importance of exporting something. So, if I said in here that I'm not going to, I'm not going to export that, there's going to be problems. It's not going to run. So, it says, hey, I can't import header from there but let's say, you know, I'm a tricky developer and I know that it exists somewhere so I'm going to find it. So, let's say, I'm going to do, it's under libs and I'm going to look in there. It's under store, I know where it is. You can't stop me from getting it. Source and library, I'm bypassing that index.ts file because I'm a sneaky developer. I can do what I want. But wait a second. Or let Merle says, no, you can't do that. You can't import from a relative absolute path. You have to use the paths that we set up. So, you have to import from the index.ts file not from, and then let's see. What's the other way you can do it? So, this is super helpful in situations where you have like a, if this header component, for example, only made sense in the context of other components and you only wanted people to access the one component you meant to export. That's where this can come in particularly handy. Now, I've had that happen a couple times for me in the past. You have some people grabbing a component you didn't mean to expose and you want to at least know about that. So, yeah. This is helpful for that. Yeah, so even if you try to access it this way, that's still not gonna work. Actually, it would be under, it'd be lib header. Here we go. Yeah, so it still doesn't like that. So, we've got enforced module boundaries here. And so, I have to go fix this, uncomment this. And, okay, now it's happy again. Okay, cool. Let's do a 10-minute break and we'll come back and dig in some more. So, during that time, feel free to ask questions. I'm gonna take a quick break myself but I'll come back and answer questions and then we'll get started in 10 more minutes. We'll get started going through the next lap. Sounds good, I'll be away for two minutes too but I'll check the discord as soon as I'm back. See you all soon. I'm back. Let's see, got some questions. Check Brian's report here. Seeing module not found. One thing so you definitely want to capitalize header inside of your TSX, I think you saw the order that you may need to restart your serve. When you cross boundaries between so when one we create some of these lips, sometimes we are adjusting the TS config at the base, which is how we set some of these paths. So your serve may still be operating on the prior configuration. So you just need to cancel the serve and restart. I believe if you that's the issue. Hopefully that helps Brian, if not let me know. See. And that's provides. Publish. So, as stack mentioned there is a community plugin that can help with that. There is also ways of. So, with, with the generators we have, in general, you can set up when you create a lib to make it. So you can make it buildable, which means you can actually build that library specifically to put it in the dislocation. There's a super set of that option called publishable. So that is both buildable but it also verifies that it's a valid publishable name on the, on that lib to make sure that you can then just publish these things up into an NPM registry. So yeah, those can be helpful for that. For Brian, how to cancel the server. Yeah, yeah. So you can. Well, like sex says this. There's two things that could be happening. I'm not sure where you're seeing the error. It doesn't look like you've seen the error in your ID. But if you're seeing it only in your ID do like that said commence. Command shift key and then like, start typing restart to restart your TypeScript server for canceling the serve. So that's the nx serve command you want to find the terminal you are running servant. And cancel it there. And then just like press up in your terminal to restart to start that sort of thing. Again, I think that's what's happening. Yeah, looking at the failed to compile message you sent us. I think you just need to cancel yourself and restart there. Crossing my fingers, Brian. Boom! Congrats, Brian. Hey, Brian, thanks also for tweeting. I just saw that. Thank you very much. Sweet.

And thanks, Stack, for the shout-out. I really, before I came to Narwal, I was just in love with NX. And it was perfect, actually, for the use case we had at my old company where we're actually, like, making a suite of different products. Many of them would share similar modules. So, yeah, I think it's … especially Science, in that scenario. In general, though, I think I mentioned this in the chat, I'll use NX for pretty much everything. Just because … it's like getting your whole stack out of the box. If I ever want to do a convenience thing, it almost seems like overkill, but I just need alcoholic beverage. What it means is that it kind of likes adoptability. My favorite campaign is community developer, Lets Add New Content and I would say for every single content you can think of, I would just like to feel their world. I feel like in the case of Postal, there are stuff going just as well, and I would definitely send them out, but I think it's just that because they were the first ones who started Oh cool, is stack only, so normally, a lot of our tools kind of come off of the Angular tool chain, so it's cool to see people who use nx exclusively for react. It's definitely a use case we are looking to push harder in the time coming up. Let's see, I think we had a question. Is this Angular specific plugin or can it be used in nx workspace? There is, so there are some Angular specific things that happen. I think this is in regards to publishing and building. Publishing and building is actually a little bit harder with Angular the way a lot of the things are set up with their module system and packaging stuff up. So in Angular, we have to go through all the setup using ng-packager package to get something to a point where it's publishable on a registry for other people, for other projects to use. So, I'm actually not sure for that third party script, if it's specific to Angular, it can be used with React as well. But I think probably with React, you could use the publishable piece, the publishable option when you generate the lib, and that will at least get you to a point where, once you build it, you should be in a situation to publish it to a registry. I don't think at the moment we have an executor command to actually publish it for you, so you'll have to do that last step yourself. Just using the npm publish I guess to push the thing up there and point it at the disk directory. So I wouldn't think you'd need the plugin in that scenario. But it's not something I've personally done before, so I'm not exactly sure. Cool. And Stack's using it now to post to React, with npm. Cool. Stack I'm not super familiar with that plugin, so there's some extra stuff around there I'd be interested in what all it's doing. Yeah, cool. And yeah, so to Aaron's point, there is some very interesting things we're looking at shortly in the future. So we're looking at what we call incremental builds. So this is, the idea here is you create a workspace and what's all of your libs are buildable. And then that way, so with the dependency tree that Isaac was shown earlier, you can kind of imagine it. Once you build, if you were to touch something towards the bottom, you're affected kind of crawls up the graph from there. Because if you touch something at the bottom, unavoidably, things towards the top are affected. Just because those things at the top build based on things they depend on down below. By running incremental builds, we can potentially remove some of that tying. So we could potentially, supposing like the external API file is supposing the external API of the package doesn't change. We could potentially change or just rebuild the one target package. And that could kind of cut down build time there, because we wouldn't necessarily have to climb back up the tree in terms of rebuilding everything that way. So some interesting stuff we're looking at in improving build times and stuff there. I see there's a question about cloud environments like AWS or Google Firebase. We do have some third party plugins that help you with that directly. We also have some blogs about how you can set that up as well. And some of the, go ahead, Isaac. Also the second day of this workshop, which we're condensing the first day into three hours right now. So the second day of this workshop goes into CI and CD. And I'll send you a link to the other repo that has the second day on it. And you can dig through that. And the second day, so the other workshop repo is an angular specific first day, but the second day is pretty agnostic to whatever framework you're using. So you can just take that second day and with the very slight tweaks, get it working for this workshop. And so you'll get all the ideas you need for how to set up your CI system with that workshop. Very cool. Thought of everything. We try. That's what we're trying. Okay, so let's move on to the next lab. So I'm all done with my slides. Let me share my screen before I forget. All right, so we finished lab 4, moving on to lab 5. So this is... I don't know if we're going to make it through all 11 labs, but we'll see. We'll get as far as we can. Lab 5, we're going to generate another library. This time it's a utility library, just some plain TypeScript functions. So because it's a plain TypeScript and nothing to do with React, we're going to use normal Workspace instead of normal React to create our library. And we also want to put it inside of the store folder. So we're going to create a new library using normal Workspace and put it inside the store folder. So let's do that. Actually, let me commit this. So this is what we went lab for. All right, so I'm going to generate a library. So we've got two different generators here that match the name library. There's a React library and a Workspace library. So we're going to make a Workspace one because it's just plain TypeScripts, and it's utilformatters, I believe. Utilformatters, yep. And then I don't want that. Stop it. So I want this, and then I want that. Okay, and then we want to put it in the store directory. I think that's everything. So libstore utilformatters, yeah, that's what I want. Okay, we've made it, utilformatters, good, and copy that and put it into store utilformatters. So we're going to copy this, so just a very small function here, and we're going to put it into the library, store utilformatters, yeah, we'll just do this, format rating. So the issue is that in our, let's see, our ratings, in our current application, the ratings have this really long number here, which we don't want. We want to have it nicely rounded off. That's what this formatter function is doing for us. Rounding things to the 10th place, I think? Yeah. It's annoying. That's what I want. This is annoying.

Okay. I've copied this over and then I need to use it in the front end project to format the rating for each game. Let's find our app.tsx. Let's find the rating. Let's see. Here. X.rating. So we want to... What format rating, I think, is what it's called? That's not imported anywhere. So let's find it. Import from... There we go. So, if that doesn't come up for you, then you need to restart the TypeScript server. But that came up for me, so I can do that. Let's see, what is the name of it? It's called format rating. That's good. And it looks like that's happy. I'm going to save this. So what's the hint here? Yeah, so this is how you import it. And then that's the line that you're going to change. Rating... Yeah, that looks right. Okay, now let's serve the store app and see what it looks like. Next serve. If you don't specify an application here, after nx serve, it will, you'll use your, whatever your default application is, which is down at the bottom, this workspace JSON. Maybe just not. Where is it? Oh, it's at the top here. Default project is store. So if I, if I don't specify store here, it does, it just finds whatever your default is from here. And nx serve, refresh this. So see our rating has looked bad at first. And now we're formatting it to look nice. And so that's good. And the next thing is, let's launch our dependency graph, an xDepthGraph here, select all. So now you can see that their application is depending on our UI library and our util library. All right. We're just going to keep moving. Well, one thing I'll call out real quick. The workspace libs are very helpful for sharing across front end and back end, especially for sharing interfaces and little utility pieces of functionality between those. So like if you want to do client-side validation and have that logic be in sync with like some back-end validation. You can kind of push that logic down into a function kind of like what I was showing here on the format rating, but like think of something that front-end and the back-end to keep them in sync. This is a great way of actually syncing them via source in my opinion. Yep. And we'll actually do that in a later lab, we'll share some types across the back and in front of it. All right, so I'm going to commit that lab five and let's move on to lab six.

Okay, now we're going to make a library that is a feature library that contains a whole route for us. So, it's going to, by the time we're done with this lab, we're going to have this detail route down here. That's not really fleshed out, but we'll flesh it out later. So, we'll stop the serve command with the Control C and then we're going to create a React library with the name of feature game detail. We want to put it under store and we set up the parent routing app to be store. So, let's see what that generates for us. So, once again, I'm doing this, create a library, I'm pasting in the name that I copied from the directions there and style that CSS, that's fine, directory we want it to be under the store directory. Let's scroll down here at project, the application project to add the library route to. Okay, so that is our store app. I think that's right, let's see what did it change. So, it updated the app.tsx file because I put that in. If I take this out, then the app.tsx file is not modified. So, that's correct there. And let's see, generateDefaultComponent, I think everything else is fine. This routing checkbox is for if you want this particular library itself to have a routing configuration inside of it. So, we don't want this to have a route placeholder. We want it to be routed to in the parent application, so we don't need to check that. Okay. So, I'm going to run this. I think this is right. I've got a clean git history so I can revert if I need to. Okay. It's updated and let's look and see what it created. So, UI share. So, feature game detail is what we just created. And we've got a default component here. That's fine and then we've modified the... That's... Let me refresh git so it notices what's changed. There we go. We got syntax highlighting now. So app.tsx was changed. So, up here, what did it do? It added some React router changes. It imported my default component from feature game detail. And then it's using it down here. So, this is just some boiler plate code to set up the React router. Now, let's see. Change the routing path to pick up the game ID from the URL. So, importing this stuff at the top. That's already done for me. We need to use the use history hook. Oh, I see. So this use history is not, didn't come by default. So, I'm going to use that. Up here, instead of link, I'm going to do use history there. And then, inside of my app, I'm going to invoke that hook. Here, const history is that. Then down here, most of this, I'm going to delete. I'm going to get rid of this. We don't actually want links because we're going to have links up in the cards themselves. Let's see. Feature game detail, that's the one we want to modify. When I was going through it, this was the hardest part. Okay. Just rectifying all these routes and the paths and the links. Okay. I skipped a step. Each card, we need to add this. Yeah. You need to add that into the onClick. OnClick for the cards. Let's see. Here's card. I think that's what I want. We need to modify that. Yeah. We don't need that. Okay. So, history.push, when you click on it, it's updating the browser history to go to slash game slash X.ID. And then down here we need to change our route to be this. I think. I think that's right. Okay, let me just run this without update, without going to the next step, let me run this and see what it looks like. So we're currently on step. We finished step three in here. I haven't gone to step four yet. Oh, and this step five shouldn't be there. That's I need to delete that step. Step five and six we want to delete. Okay. Okay, so now let me, I ran that and now if I click on here, okay, it shows that good and the URL is changing up here. That's correct. Okay, so let's, let me go back and do step four here. So step five and six, we should, should not be there. We should get rid of those, but step four we need to do. So step four, copy the TSX here for our feature game detail. And the CSS, copy over and copy that. Okay. So that link for the CSS is not correct again, so we need to copy this over here. So if the links don't work, all these copy and paste files are inside of examples.

Inside of examples. In the repo examples, and we're on what lab, no lab 6. We're on lab 6. So here is the code inside of examples in lab 6. Okay, so let's go back to CSS, paste that in. Okay, I think that's right. Now let's look at our. Isaac, would you mind throwing the, if you still have that tab open, can you just throw that link into the Discord really quick? Which, this one? Or the SCS apps? Yeah. Yeah. Thank you. Cool, we got it. Sorry, Isaac. Okay, all right, so let's paste it in. And now, when we, now we look back at our served application here, and you can see the details down here changes based on the URL up here. Good. Serve your app again, click on some games. So, skip five and six, they're meaningless. We are, basically that was already combined into step three here. So, step five was basically this here, and step six was basically this here. But we need to update these directions. Okay, serve the app, launch dependency graph and see what has been changed, so let's see. Let me run this dependency graph here. There we go, so now we have a feature game detail library that's depended on by the application. Pause for questions. We only have 50 minutes to get through another, at least three more labs, so we'll move forward unless people have questions. All right, Zach's not stopping me, so I'm going forward. Yeah, no questions at the moment. Oh, okay. Oh, we have a question, how to delete a library which was incorrectly added, wrong name. So Alex, the best way in general is to make sure you commit before you run a generator. That's what I always do. And then just revert back to your previous commit if you went about some things the wrong way. That in general is the best way to handle it. We also have a remove generator, not a remove, a move generator rather that can help you rename a lib in the case where you named it wrong or you want to nest it differently, that can be helpful for some of those use cases as well. And also remove is another generator. So I'll just do that right now. I'll make a library. Well, here, I'll commit this. That's what lab six, commit that. And then so I'll make a library nonsense library and run it. And my nonsense library is here and say my Git history is not where I want it or if it was committed, actually committed and we no longer need it. So we can run nx generate remove, well, there's also move, which we'll do use later, but remove here, and the name of the project is nonsense. And let's double check to make sure that it did what we wanted. So it deleted that and updated all the config files that are related, so there's the global jest-config, the global nxjson, workspacejson, and tsconfig. So I'm gonna run that again, and we should be back to no changes, yeah. So now we're back to exactly a clean Git history because it exactly reverted everything that we added. I learned something today. I think I'll still probably just undo, get undo. Well, right, so if you just made the library, you wanna do a git undo is makes more sense. But if you make a library, and you use it for a month, and then you realize, oh, I don't need this library anymore, then you can do the remove schematic. Nice, yeah, that's definitely helpful. Yeah, okay. Lab seven, so now we get to make a real back end. Ignore that, and get rid of our fake API. I don't think we get rid of the fake API yet. We'll do that in lab eight, but we'll get closer to removing the fake API. So, let's put a back end application into our repo. Okay, so now we need a new plugin. We're gonna use an express plugin to make our back end. And actually, I think we probably want to add it with a dash D flag, but it's not gonna hurt anything if you don't put that, but in general, to keep things cleaner, you undo dash D to make it a dev dependency. So, we're adding express and that gives us access to all of the express generators and executors. So now, when I click on generate, now there's express here and node is a dependency of express so that got brought into. So, we have this express application or node along with the ones that were already there. So, if we go here, we're gonna make a new express app and call it API. And then when we create that application, tell it that the front end store needs to have a proxy created for it. That'll help us later on. So, we're gonna run that. And now we're waiting for NPM. So, we created an application. And then we're gonna copy code from the fake API into the games.repository.ts file. So, this code we already have in the fake API TypeScript file, but we're just gonna copy it over again. So, we're gonna create a new client, it's not in there now, but we're just gonna copy it over again. Oh, oops. I left NXServe running. That's probably slowing things down. All right, I left that. So, it's still installing packages, but the files that we care about are actually here already. So, we're gonna just put things in there and let that run. We've got this main.ts file, and where did I need to put this? I copied it, but I need to see where to put it. Apps, API, source, app. I need to make a games.repository.ts file.

Oh, oops. I left NXServe running. That's probably slowing things down. All right, I left that. So, it's still installing packages, but the files that we care about are actually here already. So, we're gonna just put things in there and let that run. We've got this main.ts file, and where did I need to put this? I copied it, but I need to see where to put it. Apps, API, source, app. I need to make a games.repository.ts file. So new file, games.repository.ts. And I'm gonna paste in our fake API. So you click on this. You can see that that is the same as inside of here this fake API. So this is the same code here. All right. And now we need to go to the next step. So we made our fake API, and then we need to update the express main.ts to use the repository data. So we're going to copy all this. So it sets up an endpoint for a slash games that gives us all the games and a get game by ID endpoint as well. So our main.ts, we just paste over the top of all of this. And I think is that it? Close out of these tabs. Okay. That's it. So we're not actually going to serve this in... Well, it doesn't tell you to serve it, but I can show you what would happen if we served it. I'm gonna commit this from lab seven. And I'm gonna serve the API. So if we do NX serve by itself, it's going to serve the store app. But now if we want to serve the API, we have to specify the API. And you see this. This is getting served under port three, three, three, three, not 4,000. I think, what was the other one? 4,200. The other one was... Yeah, the other one was 4,200. So if we go to this, slash API, so there's nothing here, but if we put in api slash games, that gives us all the games. And then if we did games slash settlers in the can, that gives us just that, just that game. So we have a back end. Hooray. So let's see. It's kinda nice. Huh? Yeah. It is very though. I love that. Yeah, I mean, you spun it up. We got, I mean, all, and all the time that we spent, obviously we did some copy and pasting, which is, you know, fake, a fake speed-up time. You wouldn't actually be copying and pasting when you're doing real coding, but I spent zero time changing any of these config files. I spent zero time making sure Express was set up the way it's supposed to or whatever. So that's the real magic there.

Okay, let's go to the next lab. Lab eight. So now we get to actually use a real API from the front end. So after we finish this lab, it'll look like this. So our game details section will be fleshed out some more and the back end, we'll actually be using the real backend. Okay, so we can delete the fake API. So we can collapse the API, delete this fake API file. And then, inside of app.tsx, it's going to update. Let's see, it's gonna use fetch. So we're adding in some logic here to have loading state, success error and loading. And it's using this use effect hook here to make a call to api slash games to load in our games from the real, actually using the network, rather than just doing an import statement. Now everything else down here is, I guess this part is the same. This part is different. It's checking the loading state and saying, okay, if you're loading, we do this. If it's error, we do this. Otherwise, we do what was there before. So I'm going to copy all of this. But you're all really smart react developers. So you don't need me to explain all that because you know how react code works. Okay, so our fake API was deleted. So that's not gonna work anymore. So we'll paste over the contents here. And you can see where the changes were made. I guess that's just a white space, but everything else here, this part changed and the use effect was added. And then most of this is just getting indented differently. So I'm gonna close this. Okay, we paste that in. Okay, now we're gonna serve the API, an XServe API, to have that running. So we've got that running on port 3333, and in a separate terminal here, we're gonna serve the store. Yeah, in a different tab, run NXServe store. I wanna show you the proxy config JSON file here. Yeah, so this was generated in the last lab. And what this does is it says, when I'm serving locally, the store application, and it tries to make a network call to slash API. Instead of going to the real port, the store local os 4,200 port for that API, do this, go to port 3333 instead. And secure as false, meaning that we don't have to use an SSL certificate. Yeah. So that all happened just because we clicked on the option or we specified that this is a backend specifically for this project. So that's what set up that proxy. So... Right, so when it generated the neural express application, this part, this front end project. That's what you figure the proxy that can pick. Okay, so we've got this terminal is serving up the store and this terminal is serving up the API. And so like here, this is the API that's working. So let's look at the store, and... that is working. Let's see, let's look at our network tab. I didn't, looks like I didn't update the game details. Maybe that's in the next. Maybe my picture is incorrect. I'm gonna refresh this page and see if it actually makes a network call. I want all, not just CSS. Let's see, so games, I'm looking for such games, API such games. So it made a real network call and it's actually loading things in. Does this version of nothing up our sleeves look up to me? Yeah, it makes a real network call. Okay, here we go. Step six is updating the feature game detail. So let's make that, make this board actually look right. So if we go into our store feature game detail we can update that code here. Let's see, so underneath store, so it's library, feature game detail. So one thing that I find really helpful is using VS Codes, command P to jump quickly. If I know the name of the file, I can just type in store feature game details, so I'm not even putting in the dashes and it says, oh, okay, I can find the file that's close to what you've mashed in there. And this is the file that I want. I feel like that feature trains me to be very lazy at typing. It's just a bit of a post-it notes what I want. You know what I mean. Exactly. And update the CSS here as well. Okay, now let's look at our... Hey, there we go. Sweet. So now we got... Now are we making the network requests still each time we route to... Each time we click, do we request the specific or are we just going off with the one at the top level? I think we're getting five ones. We'll just do an individual one. Yeah. So we could obviously... Well, maybe there's some ways we could optimize it to like share data across those components, but it's still cool for purposes of demonstrating. Like, we got that sort of leaf, get requests to get some of that information. So, cool. Let's see. Is there anything else? We're using the format rating function in the routed component as well. So let's look at that code in here. So this format rating here, we're using that cause you can see here, it's not gibberish there. So you can see that this is a library and it's depending on another library here. And we can see that visually if we run the dependency graph. Now we can see that the, there we go. The store depends on you know, these three things that it used to, but also the store feature game detail depends on the util formatters cause it's using that format rating function. Cool. I think this is good. Okay, we've got a half hour.

I bet, I think at the pace we're going we could finish 11 labs and then have 15 minutes of Q&A time. A quick question that came up while we're in the little light. Alex mentioned based on that depth graph we don't know right now that we're depending on the API, which is right, there it is. So there's, yeah. Do you wanna show the implicit dependencies or is that coming up later after that? Yeah, we can do that. Yep. So because there is no, like the store application does not import anything from the API. MX has no way of knowing that they really are related. And I guess the dependency would be the store would depend on the API, not the other way around. And so if you want to manually tell NX that there is a dependency here, you can go in here and add an implicit dependency. What is the syntax for that? No, it's not here. These are global levels, it's in here. So you want to say store. So you can see in our graph here, the end-to-end application for store has an implicit dependency on the store, so it's manually set up here. So store end-to-end implicitly depends on the store here, so it's manually configured. So we want to do the same thing for store here. So we can do implicit dependencies and say that this depends on API. Sorry. Put that in an array. And so now, if we run our dependency graph again, select everything, now store does depend on API. But you have to manually tell NX that that's the case because there's no import statement that, that connects them together with the code. But by setting this, especially if you have like some end to end test set up that actually spin up your API and your client side app as part of the end to end test, by making a change in your API, it will trigger to NX, hey, we better make sure we test everything in the store here as well or in the client app, because there may be, it could let you know about some things that did actually break because of changes in the API to your client. Even though the client code didn't actually change. Yeah, so actually, it might've actually be more useful instead of putting the implicit dependency on the store. You might wanna put it on the store end to end tests and say, hey, whenever we... Oops. Whenever we run the end to end tests, we're actually gonna be hitting the API backend. And so you have something closer to... closer to this. No, but that's a matter of preference.

All right. So I'm going to say this as what was that, Lab8? That's correct, that was Lab8. That was Lab8. And so we're moving on to Lab9 now. Let me close all of these. Okay, so Lab9. So you're right, we were seeing that the, the API and the, and the, and the front-end store were not, were not tied together in our dependency graph. They're also not tied together in terms of the, the models that they're passing back and forth. They're actually using this game object that they're sending back and forth to each other is, is defined in both places. And it's, if that were to change, you would have to change it in both places. And so what would be nice is to make one library that contains everything we know about what a game is and have the both backend and front-end use that, use that library. So that's what we're gonna do in lab nine. So we're gonna make, this is gonna be a pure TypeScript library again. So we're gonna use workspace and we'll make a util interface and put it underneath API because I guess API is more in charge of that model than the front end is. So let's make a workspace library that one. A workspace library, that one. And we're gonna call it util interface and we wanna put it underneath an API directory, is that right? Call it util interface. Put it underneath the API folder. Okay. And I think everything else is fine. Okay, so we're gonna run it. Okay, that was created. API util interface. Good. Now our next step, we're gonna create a game interface inside of this file API util interface. Paste that in. And so index.ts here is just exporting everything from that API util interface file. So we don't have to explicitly take this game and export it here. Okay, next in the API repository here, we're going to use that game interface. So let's look at the hint. So we're going to import it like this in our game repository, repository. Is that repository up here? So this is untyped. So we want to type that. So that and say, games is a array of games. Okay, and now you can see that's the interface there. And if we change this, you know, there's, there's problems there. All right, let's build the API and make sure there are no errors. And we'll do NX build API. All right. Okay, looks like that was happy. And let's look at the dependency graph. Okay, so the API depends on the APIUtil interface. Okay, so API is using it, that's good. Yeah. Now let's keep going with our lab. Okay, so our frontend store has our list of games here, but they're typed as any. Which is probably not what we want. We'd like to. Why are we even using TypeScript? Right, right, just any everything. So we're going to make this a game type here. And let's see, which file was that in? That was in app.tsx, I think. Here it is. So we even have a lit rule that says, wait a second, you shouldn't be using an any. So we're going to call it game. And so that's not imported. So let's import that. Import from at board game horde, Utilt interface. Now. But it's inside the API folder. And we don't really like that we're reaching into the API folder from something that's inside of store. So let's before we use this, let's put that back to any and let's move that library over to a shared folder. So it's more clear that this is actually a library that can be used in multiple different applications. So we're gonna use this move generator here. Okay, we've got multiple hints going on here. Okay, well, that's unreadable. That's better. Use the help command to figure out what's going on. Hint three, library name is this. Okay, all these hints are helpful, but I think the most helpful thing is just to use the VSCode Enix console plugin here and run the move generator. And then we get the dry run happening. So the destination is going to be, we're gonna move it into Shared Util Interface here. And the name of the project. So the name of the project is the name that's specified here in the project list, API-Util-Interface, So when we run it, let's look at it. So this is, we want to be careful about what we're doing here. So we're deleting API Util Interface and then moving it to Shared Util Interface. So that looks, that looks right. API Util Interface and deleting the whole API Util Interface folder and deleting Libs API. Now, if I had done that wrong, say I put a slash here, API slash Util Interface, it's gonna let me know, hey, that doesn't match up with a name of something that I know. So you'll know, okay, wait a second, API Slash, Util Interface is not right. And then the same thing goes for the destination. That's not gonna give me an error, but if you look at the dry run here, we don't want it under, we don't wanna rename it to Shared Util Interface at the top level. We wanna put it inside of a folder called Shared and call it Util Interface. So double check your dry run before you click the run button up here. And it's also good to have a clean Git history, if I were to do that, if I were to revert, I could commit, I guess before I moved it, but I'm just gonna run this. I'm living dangerous. Too dangerous for my blood, Isaac. Yeah, okay. So now underneath, let's see apps, so libs, now we have a shared folder here instead of API and Util Interface is under there. Okay. All right.

And now, we're gonna import it like this. I don't think this is correct, but we'll find out. Yeah. We'll need to reference the shared, I think. Does that exist? Nope. Yep. So that's not a real thing. So it's underneath the shared folder here. There we go. And then instead of this Any, we'll call it game. Are there any other Anys in here? No, no more Anys. Okay. All right. So you need a slash shared in here. The other thing, we can do the same thing inside of the store feature game details. So I'm gonna copy this line because I'm gonna use it again. Game details. And paste that in there. And this is game. And now if we go in here, we'll get some, we should get some, yeah, there we go. Now we get some typing. Is activity monitor for? No dash. That stayed on top of all those threads. Okay, so we ran that. So notice in the API, we didn't actually have to change the API at all. If I go look at the API, the games repository here, this is changed this last year. I didn't change that, the move schematic changed that. So when the move generator ran, it found all the places that were referencing the existing library and updated the import path for it to the correct one. So this is very useful. Without that move generator, moving libraries around or renaming libraries is very tedious. So this makes it very straight forward to do. Okay, so we can build the both. We can do nx build store and in parallel, let's do nx build API. Make sure they both work. I'm tempted to mention run many. Yeah. So one interesting thing you could do and this is maybe more advanced, but if you wanted to set a single command to run both your builds of your client and server in parallel, you can actually do that with one command by using the nx builder called run many and passing in options to then individually run these two builds or these two serves or something like that. And that can be convenient if you're always serving something in a context of your workspace together. Okay. I've got some problems here. It doesn't like that data is assigned to an empty object here. So let's do, we could add it back in. As any. We thought we were done with any, but it keeps creeping back. It's like the, I can't quit you. Just add the ignore. Or you know what we could do? Let's do this. I think this, I think the instructions actually told us to do this. Ah, yeah, yeah. Cause I was smarter when I wrote the instructions than I am now. So if we do partial then this is okay. Partial is a TypeScript built-in type. Yeah. Alex is mentioning it should be an array. I think we're on the detail one. So this should just be a single. Yes, detail is a single one. If I go to app.tsx here. This is an array. Yes. All right. So let me run that again. Build store again. Make sure that works. Yeah, good. That worked. And looking at the dependency graph again. Now we have this shared util interface that the API is using, the store is using in the store feature game detail library. They're all using it. So if I change a model, change something about the model, you'll have to update the API. You have to update the story. You have to update the store feature game detail. So I mean, I can show that real quick. Where is it? All right, I can actually find an interface, this one. So let's name thing. So now, if we run the NX build API, it doesn't like it. And if I build the store, I'm going to need to find a new interface. Hopefully, this breaks, too. Yeah. So, updating in one place. So now, we've got one source of truth for what that model should look like. All right, so this is lab nine. Lab 10 gets into some magic. The magic of generators. Okay, lab 10 and 11 are basically showing off the kinds of cool things you can do with generators. I'm just going to blaze through this quickly because we are very close to time. We're about 13 minutes left at the moment. Yeah, I wanna have a little bit of time at least for questions at the end. So I'm adding the Storybook plugin. And then gonna use the Storybook configuration generator and say yes to everything once it's done.

See if it works. Okay, I'm gonna run the generator. Storybook, that one. And I think it's store UI shared. So this has the header component inside of it. Okay, and then make sure I do yes to everything. Here, let me just... Well fine. Yes to configure Cypress, generate Cypress specs and generate stories. And we'll leave all that the way it is. Run it. And we're gonna have storybook added with... So we're gonna do NX storybook store UI shared. So instead of... So our target name is now storybook here instead of serve. So that's not a default target, but we just made a custom one called storybook that runs storybook for that particular project. Wait for NPM to work. Okay, good. Now if we go down here, store UIShared, it has a storybook option here. So I'm going to run that. Or you can do it from the command line using this. Building do you give me a. There it is. Right. So now it found inside of that library. It found two different components, made stories for them, and show them up here. So we can look into the store UIShared library that is UIShared. So it added a storybook configuration folder and then added some stories, files that just get you you know, get you started and runs it. So, that's pretty cool. You have, you have story book running. The other thing that it did, and this is jumping into Lab 11. So Lab 11 does not have any code changes to it. It's just a running things that just taking advantage of what we did in Lab 10. We can run end-to-end tests against that storybook. So in storybook, we have a, this is an I frame that has our component rendered inside of it. And we can actually, let's see. Not full screen. We can actually, here we go. This is what the I frame is. We can render that I frame just by itself. And it would be nice if we could test these components directly in the, like test these components in isolation like this using an end-to-end tool like Cypress. And so that's exactly what we did when we said yes to the generate Cypress specs. So it created this end-to-end application that runs Cypress and runs some tests against the components there, against those storybook instances. So if I run, stop this, and run this command, end-to-end store UI shared, what it does, it's gonna run storybook first and then run Cypress against that storybook instance. And it's gonna fail because inside of here our header spec file, well, let's see if we can watch it. Oh, I think it's headless by default, oh, there it is. Actually, let me do a test run. So it's pulling up that iFrame, it's looking for welcome store DUI shared but that text doesn't exist. And then there's the other component that got created, that one passed because it has the default text. So we need to fix this spec file here. So in Lab11 it shows you what text to put in there instead. Type in shared here, yep. Should show the title and it checks for the text that actually there. And now if we run that again, it will launch it and everything should pass. But, I mean, this is cool. We did basically no work here and we have some extra ways of running tests. We can get storybook up and running and configure that to work the way we want. And we can use Cypress against that storybook, or I mean, obviously we didn't dig into it, but, in this store ETE file, you can use Cypress in a more like normal way here, which is just running the application itself and using Cypress against the application itself. Okay. Okay. That that is it for day one of the lab. Let me share with you the, the day two, this NX workshop repo is different. So, we've been going through NX React workshop. NX workshop is the same workshop but with Angular. And it has a second day, which should be pretty straightforward to do. But if the day two, which we obviously don't have time for, goes into lots of really useful things, including, so this module boundaries shows you how to set up tags to restrict which kinds of libraries can depend on which other kinds of libraries. 13 and 14, show you how to create workspace generators, which basically allow you to harness the power of generators for your own organization and set up your own, and encode your own workflows in code. And then 15 through, basically 15 through the end, is walking you through setting up a CI system to take advantage of the NX cloud distributed caching to deploy your code to the backend. Also there's part that uses environment variables, I think this Lab20. Somebody's asking about environment variables. Lab20 here is where you want to check out environment variables. Let me see where it is. No, it's not there. There's a different one that, so this is setting up some different settings for how you build it. But there's one, I think this one, the API, you store your API keys in environment variables. And so here, yeah, here's your API key set up in a.local.env file, and then inside of, let's see, where is it? DistApi, executor, run commands. I know I saw it. Somewhere in here, there's an example of how to use these API keys. Maybe it's deploying the front end. Yeah, that could be it. You got search token. Cool. Here we go. Yeah, so this is using your environment variable inside of a script basically that's created. Jenna, this will walk you through how to do your environment variables. And I guess, yeah, here's another page that talks about environment variables, too. Okay, what else did I wanna do talk about? I think that's it, so I'm gonna paste this link in Discord if Zach hasn't already done that. I don't remember how to run this. Okay, Zach, what other questions should we, are there any other questions in Discord? There were some questions around, so try getting the server and the client run at the same time whilst also running Cypress against it. So Aaron and staff are talking through that right now.

So the way, if you look at the Discord stack posted a way of adding an architect target to a certain project, so you can like run them both at the same time. I think there's some ways you can run it so you can adjust the same projects end to end. So it targets this new command now. And I think it will wait until both of those, both of those send their signal that they both started serving and then it will start up Cypress, I believe. Yeah, let me do that. So there's some ways around that.Oh, cool. So run commands is a really powerful executor that basically you can run any terminal command inside of an executor. So we're gonna call this serve API and store and the command that we're gonna run is Nx serve API. Actually, this is not super helpful. So we're gonna have to do this. We're gonna generate this and then we're having to go in and modify it because. And then let's see, underneath, we're gonna put this on the store app, but it's related to the API and the store, so it doesn't really have a particular project that's associated with it, so you just have to pick whether you're gonna put this on the store or the API. These files we're gonna leave the same. So this generates some configuration for you. And here, in your Workspace.json, is what it changed. So look for test. Here, serve API and store. So it created a command that will do Nx serve API, but we want to do more than just that. We wanna put a commands option here that takes an array. And that actually needs to be an object inside of there. And I'm gonna copy this. This and X serve store. Paste that and then, then there's an option for parallel, set that to true. So we don't run them in series, we wanna run them together. And then in order to, if we want our end-to-end, our end-to-end command here launches, let's see, dev server target. So it's doing store serve, it's launching that before it runs the end-to-end test. So instead of doing store serve, we can do store serve API in store. And this, update that. And probably wanna do that under production as well. So if we run that, I think that's right. And also I know that in the Urey's egghead course, he does this exact thing in his egghead course. So now if I do nx run, and then on the store application, we wanna do serve API and store, that runs both of them inside of the same terminal. So this localhost 333. So you got some mixing here of the terminal output, but there's no way around that. So you got the APIs up and the front end is up here. And so then if we did the end to end, store ETE, and then the ETE target, that's gonna run this command and then run it's ETE. So it's doing the same thing here. That's launching the API and launching the store and then running the ETE tests. And when I can, I love being in that developer experience especially. Just like developing a feature, this is like the only time I can really get into TDD where I'm like writing stuff in Cypress. And even if I don't have tests, it's a perfect little sandbox it feels like for doing something. But then if you want to, you can say, I wanna make sure the feature does X, Y and Z. So you can kind of script out some checks on yourself to make sure everything's going as you do it. Yeah. This is a bit confusing cause this UI shared end to end app is being rendered over the top of this arrow. So this does not depend on this one. It goes over to API, but yeah, so our dependency graph is being constantly updated so we're doing some tweaks on the UI here. But if you want to, you can just hide that, check checkboxes to hide and show things and it will rerender up here. So if there are parts you don't care about, cool. We've reached the end of our time. I like talking about this but my voice is going raspy. Is there any other pressing questions we should cover? No, no, no, no, no. Oh, this is important. Inside of the, if you go here to NX community, there is a link here to the NX community Slack. So there's a whole group of friendly people there, not just people who work for Narwhal, although some of us are there, too. And you can ask questions if you're stuck configuring your NX repo. There are friendly people there that'll help you out. And there's other things in here. There's office hours, every other week, we do a YouTube live stream, where you can ask questions and we'll answer questions. And you can subscribe to our newsletter and other things. This also lists out all the bunch of community plugins that people have. Very cool. Yeah, Dries, if you wanna just see the outputs of the dependency graph, you can do, I think, nxprintaffected. And that gives you a JSON object, which is what the dependency graph uses to generate itself. Maybe just projects, dash dash all maybe, to make sure that you have everything in there. So you could write your own if you want to. Or, I mean, it's all open-source. So you can dig into the code itself and see what's going on there. All right. Well thank you everyone. I hope you enjoyed this. I enjoyed giving it. And so I enjoyed it so much I messed up my hair in the last three hours. And I just keep it messy, you know. Yeah, just keep it messy all the time. So. Perfect, Alexa sorry you're having some issues with the storybook piece. But yeah, with our time being up, we'll have to, yeah sorry, but hopefully you can figure it out. If you need some more help with it reach out on the community Slack and maybe we can help you there. Yeah, NX community Slack. Yeah, we don't have a discord but we have a, we have a Slack. Sorry. Where old school enterprise. Well, no, it's not. Not enterprise. It's just that the Slack was created by people who don't work in our role. And so they manage it and maintain it. And so if they wanna go to Slack. So I posted it in the discord.

But here is. I'm gonna go back to it. So the link for Slack, you can find it here. But I can copy that link address directly. So that's for joining Slack. But the NX community page has everything. Has the Slack, has office hours, and also it's the other information where you go to get more help.All right, well, thanks everyone. They'll be recording later this week. And please reach out on the Slack channel or you can raise issues or post PRs on the open source NX repo.All right, bye. Thanks everyone so much, catch you all later.

React Summit Remote Edition

React Summit Remote Edition 2021

React at Scale with Nx

React a gran escala con Nx

NX is a tool for managing monorepos, providing controlled code sharing and consistent coding practices. NX speeds up commands through caching and offers five hours of free computation time per month with NxCloud. The workshop covers topics such as building applications, creating libraries, generating utility functions, and testing with Storybook and Cypress. NX allows for running multiple projects simultaneously and provides a community page for support and resources.

- 00:10 - Intro
- 04:57 - What is Nx slideshow
- 27:30 - Lab 1, exercise
- 36:15 - Lab 2, slides
- 38:30 - Lab 2,  exercise
- 57:12 - Lab 3 - slides
- 01:02:08 - Lab 3, exercise
- 01:12:27 - Lab 4, slides
- 01:23:19 - Lab 4, exercise
- 01:51:20 - Lab 5
- 01:57:30 - Lab 6
- 02:10:40 - Lab 7
- 02:17:17 - Lab 8
- 02:29:25 - Lab 9
- 02:52:10 - Day 2 on your own
- 02:56:10 - Q&A

The larger a codebase grows, the more difficult it becomes to maintain. All the informal processes of a small team need to be systematized and supported with tooling as the team grows. Come learn how Nx allows developers to focus their attention more on application code and less on tooling.We’ll build up a monorepo from scratch, creating a client app and server app that share an API type library. We’ll learn how Nx uses executors and generators to make the developer experience more consistent across projects. We’ll then make our own executors and generators for processes that are unique to our organization. We’ll also explore the growing ecosystem of plugins that allow for the smooth integration of frameworks and libraries. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Isaac Mann

Zack DeRose

React Day Berlin

React Day Berlin 2024

JSNation US

I’m attending JSNation US. Join me there for free with 10k other JS engineers and 50+ great speakers. Just follow this badge.

JSNation US 2024

React Summit US

React Summit US 2024

Productivity Conference for Devs and Tech Leaders

I'm attending Productivity Conf - get your free remote ticket and join me there with 5k professionals and 25+ great speakers

Productivity Conf for Devs and Tech Leaders

Node Congress

I’m attending @NodeCongress, the biggest conf on #JavaScript backends – by clicking the badge you may get a free remote ticket & join me there with 5k other #nodejs devs & 35 great speakers #deno #cloudflare #awscloud

Node Congress 2025

JS Nation

I’m attending JSNation – the main JavaScript conference of the year. You may join me there for free with 10k other JS engineers and 40+ great speakers. Just follow this badge. 

#javascript

JSNation 2025

React Summit

I am attending the biggest #Reactjs conference remotely. You may get a limited free ticket (50% of talks, no workshops) and join me by clicking this badge.

#react #reactjs

React Summit 2025

TechLead Conference

I'm attending TechLead Conference 2024 – get your free remote ticket and join me there

TechLead Conference 2025

C3 Dev Festival

Join me at C3 Dev Fest, a contemporary software engineering festival!

Register to win an all-paid trip to Amsterdam. Elevate your career with industry experts and workshops & rock 3 dance stages at the after-party!

React at Scale with Nx

FAQ

Available in other languages: