Tailwind is a utility-first CSS framework for rapidly building custom user interfaces.

tailwind

Next.js is a minimalistic framework for server-rendered React applications.

Hey 👋, glad you're interested in my course about architecting a Digital Garden. Now there are a lot of buzzwords in this course 😅. Digital Garden, Next.js, Tailwind, Nx and more! And yes, we'll cover them all. We're not going to talk about Digital Gardens too much (there's a lot of material on Egghead on that already if you're curious), my goal is to teach you how to set up your own infrastructure to host one. 

That said, even though we're basically building a non-mission-critical personal platform for ourselves, all the technologies and skills you'll learn here, are 100% transferrable to your next professional project!

I really hope you like the course. Feel free to ping me [on Twitter](https://twitter.com/juristr) or on my [personal website](https://juri.dev) with questions and comments 🙂. Also, make sure to leave a review if you like the course!! 😄

egghead

Introduction to Architecting an Extensible Digital Garden with Next.js, Tailwind and Nx

The first step to getting started with Nx is to create a workspace. 

In this lesson, we're going to walk step by step through [generating a new Nx workspace](https://nx.dev/l/r/getting-started/nx-setup) using `npx create-nx-workspace` command. Next, we'll choose a preset during the Nx setup process which allows us to also generate a brand new [Next.js](https://nextjs.org/) application within our Nx workspace as well. Finally, we'll learn about what got generated for us and the anatomy of an Nx workspace.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/create-a-next-js-web-app-with-nx-bcf2ab54613).

Create a Next.js Web Application with Nx

One of the powerful aspects of Nx is its generators that allow to easily scaffold new projects, configuration changes and new components. In this lesson we're exploring how to use a Nx built-in generator to [scaffold a new Next.js page component](https://nx.dev/l/r/next/page) which is the one for our portfolio's About page. We also leverage [Nx Console](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console) to have a visual UI while composing the various options of the generator.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/create-a-next-js-web-app-with-nx-bcf2ab54613).

Create a new Next.js Page Component with Nx Generators

A Next.js page component has two interesting functions `getStaticProps` and `getStaticPaths`. 

In this lesson we're going to look into `getStaticProps` to get a basic understanding of what it does and why it will be useful for our final target of creating a statically rendered portfolio site with Next.js

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/create-a-next-js-web-app-with-nx-bcf2ab54613).

Understanding Next.js GetStaticProps

For our personal portfolio site, we definitely want to have a blog or list of articles. If we want to display articles, we might have a routing like `/articles/some-article`. 

In this lesson, we learn how Next.js uses a folder-based routing system and in particular why `getStaticPaths` is useful for creating a dynamic Next.js page component that renders the article based on what is in the URL `/article/[slug]`.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/create-a-next-js-web-app-with-nx-bcf2ab54613).

Understanding Next.js getStaticPaths

Besides having a performant website, our portfolio site should also have a decent design and UI. Now, either you're a champion in CSS and UI design in general, or you just rely on some existing CSS framework that takes care of 90% of the things for you already. In our case, we use [Tailwind](https://tailwindcss.com/). 

In this lesson, we specifically look into the setup of Tailwind and how we can integrate it into our Nx workspace together with Next.js

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/setup-next-js-to-use-tailwind-with-nx-849b7e21d8d0).

Setup Next.js with Tailwind in a Nx Workspace

In development mode, [Tailwind](https://tailwindcss.com/) might be several hundred Kb large, if not into the megabytes depending on which classes you use. That's definitely not something we want to ship to our production environment. Therefore, Tailwind comes with CSS purging, a build step that analyzes your HTML, components, etc and removes all the unused Tailwind CSS from the overall bundle, shrinking down the Tailwind CSS to the bare minimum. 

Normally you would just set this up for the app you're installing Tailwind for, but in a [Nx](https://nx.dev) workspace, you might have multiple apps and multiple libraries (shared or not). Hence, we don't just want to purge app-specific HTML files, but also those of the libs we use. Nx comes with built-in support to automatically generate glob patterns based on the libraries consumed by a given application.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/setup-next-js-to-use-tailwind-with-nx-849b7e21d8d0).


Configure Tailwind purging in a Nx Workspace

Monorepos might consist of multiple applications and libraries. As such, when we setup Tailwind, we might want to have certain workspace-wide global Tailwind settings which all of our applications should use (e.g. imagine company level branding colors etc). At the same time though, individual applications might have different requirements and thus need to adjust and overwrite the global Tailwind configuration. In this lesson, we learn how to have a global Nx monorepo workspace wide configuration that is imported into the application level individual Tailwind configurations

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/setup-next-js-to-use-tailwind-with-nx-849b7e21d8d0).

Configure Tailwind in a Nx Monorepo With Potentially Multiple Apps and Libs

While still an experimental feature in Tailwind v2, [JIT compilation mode](https://tailwindcss.com/docs/just-in-time-mode) will be the default in v3. JIT mode not only gives faster rebuild times and allows to generate arbitrary styles, but mainly gives browser tools some relief by only shipping what is needed. 
Tailwind purging only happens when you create a production build, which means your browser dev tools have to process the possibly megabytes large Tailwind CSS, which might result in a noticeable slowdown. In this lesson we're configuring JIT mode for our setup and we'll learn how we can leverage it with Nx.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/setup-next-js-to-use-tailwind-with-nx-849b7e21d8d0).

Configure And Use TailwindCSS JIT Mode With Nx

On our portfolio site, we definitely want to have the ability to render a list of articles, which preferably we'd want to write in Markdown. Whenever our user navigates to `/articles/[slug]` they should be presented with an article. In this lesson we learn about how Next.js page routing works and how we can leverage the `getStaticPaths` to read our list of markdown files and generate a new page for every article in the folder.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/read-and-render-md-files-with-next-js-and-nx-89a85c1d9b44).

Use getStaticPaths to Retrieve a List of Markdown Files to Render With Next.js

In a plain normal Next.js application you would place your markdown processing logic somewhere within a folder insider your Next application. We could do the very same in an Nx monorepo, however, we get much more benefits by moving it into a dedicated library in the `libs` folder.

[Nx workspace libraries](https://nx.dev/l/a/structure/grouping-libraries#example-workspace) allow you to nicely encapsulate your functionality as well as to easily share it with other apps that might potentially live in our workspace. In this lesson, we learn how to generate a new library with Nx generators and how to import the library into our Next.js application.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/read-and-render-md-files-with-next-js-and-nx-89a85c1d9b44).

Generate an Nx Library to Implement our Markdown Rendering for our Next.js App

Many markdown documents have a metadata section at the very beginning, which contains information such as the title, author and creation date. This section is the so-called "front matter". 

In order to render our markdown-based blog articles on our portfolio site we want to parse them and separate them into the front-matter and main article part. `gray-matter` is a library that helps us with that.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/read-and-render-md-files-with-next-js-and-nx-89a85c1d9b44).

Parse a Markdown Document With gray-matter

Once we have separated the front-matter from the rest of the markdown document, we can proceed to convert it to HTML, for then finally render it with our Next.js page component. In this lesson we use `next-mdx-remote` to parse the markdown string into HTML and we learn how to leverage the `MDXRemote` component to include it into our page component.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/read-and-render-md-files-with-next-js-and-nx-89a85c1d9b44).

Render Markdown With next-mdx-remote in our Next.js Page Component

When rendering our markdown we might want to enrich the experience with some dynamic content. Many static site generators allow to include dynamic content placeholders for like embedding a Youtube video, generating table of contents, code blocks with interactive functionality and more. One way to achieve this in the React ecosystem is by using MDX. MDX is similar to JSX but for Markdown content, and allows us to directly embed React components within it. This gives an enourmous flexibility to what we can display within a page.

In this lesson we’re going to generate a new Nx library to host our “mdx elements” and learn how to leverage the `MDXRemote` component to embed these React components into our markdown rendering flow.

Embed React Components in our Markdown with MDX in a Next.js App

The markdown rendering includes a lot of native HTML tags as well of course. Assume for instance we want to change the behavior of links within our rendered document. We can definitely create a custom component and include that in our MDX document, but we’d rather not want to have to use a specific `<Link>` component and rather be able to keep the native way of rendering links in Markdown, that is `[some link](https://juri.dev)`.

Turns out that with `next-mdx-remote` we are able to automatically replace all rendered `<a>` tags (or really any other tag we want) with a React Component.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/component-hydration-with-mdx-in-next-js-and-nx-90f46ea0431c).

Use React Components for Native HTML Tags with MDX and Next.js

Next.js is all about creating performant web applications. However, the more React components we pull into our MDX via `next-mdx-remote`, the heavier our JavaScript becomes which drains our site's performance. Also, while we might have quite a few React components to be included in our Markdown rendered content, we might not always use all of them in our articles.

In this lesson, we learn how to leverage Next.js dynamic imports to just pull the minimum necessary components into our final JavaScript bundle. Also, we look into why we might want to do deep imports into our Nx library setup to decrease the size of the bundle even more.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/component-hydration-with-mdx-in-next-js-and-nx-90f46ea0431c).

Dynamically Loading React Components with next-mdx-remote and Next.js Dynamic imports

So far the path to the articles folder, where we host all of the markdown files, is hard-coded into our Next.js page component. In the long run, we wouldn't want to leave it like that. First of all to give greater flexibility in customizing the path if we ever decide to move it to another place, but also to make it more easily accessible by other parts of our Nx workspace libraries and apps.

This is a perfect use case for environment variables. In this lesson, we learn about how Nx, as well as Next.js, is able to read environment variables.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/hot-reload-mdx-changes-in-next-js-and-nx-c05252cf450a).

Using Environment Variables with Next.js and Nx

**NOTE:** `workspace.json` is deprecated, you can update to `project.json` [here](https://nx.dev/deprecated/workspace-json).

One cool aspect of Next.js is its [fast refresh](https://nextjs.org/docs/basic-features/fast-refresh) support. Whenever you change some Next.js component it automatically refreshes the page without hard reloading everything. However, you might notice that whenever we change something within our MDX markdown files, fast refresh is not capturing that, hence we need to manually refresh the browser window.

In this lesson, we learn how to leverage a feature of Nx to create a "[custom Next.js development server](https://nx.dev/l/r/next/server#customserverpath)". We are going to use [chokidar](https://www.npmjs.com/package/chokidar) to watch our articles folder and then invoke a private API on the Next.js server instance to trigger a reload command.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/hot-reload-mdx-changes-in-next-js-and-nx-c05252cf450a).

Add Fast Refresh Support to our MDX Files with Nx Support for Custom Next.js Servers

Once we finish our portfolio site, hopefully, one of the main activities we'd be doing with it is to create new content. Thus we want to automate the creation of a new blog article, which includes the creation of a new MDX file in the `_articles` folder as well as initialize the article's front matter with the title, author, and creation date.

Nx has a powerful concept, called [generators](https://nx.dev/l/r/generators/using-schematics). While many of them come already built into the Nx plugins (e.g. `@nrwl/next`, `@nrwl/react`,...), we can also define our own, [Nx Workspace Generators](https://nx.dev/l/r/generators/workspace-generators). This is exactly what we leverage to scaffold new blog articles.

Prefer to read along as well? Here's the [accompanying article](https://juristr.com/blog/2021/08/nextjs-storybook-tailwind-nx/#using-our-react-topic-button-component-in-our-next-js-app)

Scaffold a New Blog Post Article Automatically With Nx Workspace Generators

We can run [Nx Generators](https://nx.dev/l/r/generators/using-schematics) directly from the console. However, if you prefer a more interactive, UI-driven approach, the [Nx Console extension](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console) for VSCode is for you. 

Interestingly, Nx Console not only allows to run built-in generators that come with the various Nx plugins, but it is also possible to directly run local [Nx workspace generators](https://nx.dev/l/r/generators/workspace-generators).

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/using-nx-workspace-generators-to-scaffold-new-blog-posts-8c8162cf857b).

Run an Nx Generator With the Nx Console VSCode Extension

To improve the execution of our [Nx workspace generator](https://nx.dev/l/r/generators/workspace-generators) we can add prompts to our generator configuration. In that way, when users run the workspace generator and some argument is missing, it would prompt the user with a question we can define. This leads to a much-improved experience.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/using-nx-workspace-generators-to-scaffold-new-blog-posts-8c8162cf857b#0f77).

Add prompts to an Nx Workspace Generator

Developing UI components is sometimes a highly visual effort. We continuously want to have feedback on how a particular change affects our component rendering and adjust accordingly. Most often, as a developer, we include these components in their target applications, just to get that visual feedback. This is far from ideal though.

[Storybook](https://storybook.js.org/) solves exactly this! It allows you to develop components in isolation and experiment with the inputs and outputs of a component. Furthermore, once the Storybook story is fully developed, it can serve as documentation for other developers to explore.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/use-storybook-with-tailwind-in-an-nx-workspace-5ceb08edad71).

Configure Storybook for your React Based Nx Workspace Library

We want to have a library where to host our UI components s.t. they can be easily shared within our Nx workspace. In many cases a Nx workspace starts like this, and then over time we add new applications, either because new projects start or even because we split up existing projects into multiple ones for a better scalability. Furthermore, having a shared UI library is a common scenario especially in larger real-world applications to encapsulate the corporate design components

In this lesson, we look into how to configure our Nx React Storybook setup to work with Tailwind CSS.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/use-storybook-with-tailwind-in-an-nx-workspace-5ceb08edad71).

Configure Tailwind for your Storybook Setup in an Nx Workspace

In this lesson, we develop a new React component in an [Nx](https://nx.dev) library with Storybook. We explore how to leverage [Storybook](https://storybook.js.org/) to develop the component in isolation, how to expose the component props s.t. we can then dynamically change them in the Storybook rendering and much more.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/use-storybook-with-tailwind-in-an-nx-workspace-5ceb08edad71).

react

Develop React Components in Isolation with Storybook and Nx

When developing with an Nx monorepo it is highly suggested to develop your main logic inside so-called Nx workspace libraries. That allows you to develop components in isolation (e.g. with Storybook), leads to a better API and decoupling overall and facilitates reuse across various applications.

In this lesson, we learn about how to easily share a component that has been previously developed within an Nx workspace library with our Next.js-based application.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/use-storybook-with-tailwind-in-an-nx-workspace-5ceb08edad71).

Share React Components in Next.js Applications with Nx Workspace Libraries

[Nx](https://nx.dev) promotes best practices by automatically generating [Cypress](https://www.cypress.io/) based e2e tests for all applications inside an Nx monorepo workspace. Not only does Nx take away the burden of configuring Cypress, but it also allows to easily serve Cypress in "watch" or headless mode. The latter is particularly useful to also run in your CI pipeline. When you run Cypress test with Nx, it automatically makes sure to first launch the tested application, then run Cypress and point it to the running application. 

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/use-cypress-with-next-js-and-nx-to-battle-test-your-react-components-da273f664f81).

cypress

Write e2e Tests for our Next.js Application with Nx and Cypress

[Storybook](https://storybook.js.org/) is already powerful for being able to develop components in isolation as well as using those stories as living documentation for others. [Nx](https://nx.dev) goes a step further. It leverages the fact that Storybook exposes an `iframe.html` that allows to access the rendering of the story without the actual Storybook frame. On top of that, Nx generates a Cypress configuration to run tests against the Storybook stories.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/use-cypress-with-next-js-and-nx-to-battle-test-your-react-components-da273f664f81).


Write Cypress Tests for our React Storybook Components with Nx

When it comes to deploying Next.js based applications we have basically two different possibilities: "exporting" our app, or just building it.
The main difference is that "exporting" a Next.js app will generate a set of static files for us which can be hosted by really any static site hosting provider. Building a Next.js app is what you would want to do instead for deployment on [Vercel](https://vercel.com/).

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/publishing-a-next-js-app-to-vercel-with-nx-df81916548f5).



Export a Next.js Application with Nx

When you develop a Next.js based application, [Vercel](https://vercel.com/) is probably the preferred way of deploying the site (although not the only option you have). In this lesson, we're going to have a look at how to set up a Vercel deployment for our developer portfolio site.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/publishing-a-next-js-app-to-vercel-with-nx-df81916548f5).

Setup Vercel to Deploy an Nx Based Next.js Application

If you work in a monorepo you want to make sure to have tooling that supports that. [Nx](https://nx.dev) comes with those baked in, allowing you to grow your monorepo from a single to multiple apps. One way Nx tackles this is by providing so-called [affected commands](https://nx.dev/l/r/core-extended/affected#rebuilding-and-retesting-what-is-affected).

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/publishing-a-next-js-app-to-vercel-with-nx-df81916548f5).

Only Build What Changed with Nx Affected Commands

By leveraging the [dependency graph](https://nx.dev/l/r/structure/dependency-graph), [Nx](https://nx.dev) is able to understand which parts in the monorepo changed and thus trigger actions on those nodes, such as building an app, running tests or linting. This already works out of the box. However, with our portfolio application, all of our markdown articles reside in the root-level `_articles` folder. Those are not captured by the Nx dependency graph and thus Nx would not correctly detect a change to our Next.js site application whenever we change or add a new markdown article.
In this lesson, we learn how to register our `_articles` folder s.t. it appears as a dedicated node in the Nx dependency graph.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/publishing-a-next-js-app-to-vercel-with-nx-df81916548f5).

Register our Markdown Articles with the Nx Dependency Graph

In an Nx monorepo, you typically have multiple applications and lots of libraries. When we configure [Vercel](https://vercel.com) for deployment, we set one Vercel deployment for each app in our monorepo. However, we would want to make sure that not all the apps are being deployed all the time, but only if the app was really affected by the change. [Nx affected commands](https://nx.dev/l/r/core-extended/affected#rebuilding-and-retesting-what-is-affected) can help here.

In this lesson we're going to create a simple script, that leverages the Nx affected commands to determine whether we should cancel or continue a given Vercel deployment.

Prefer to read along as well? Here's the [accompanying article](https://blog.nrwl.io/publishing-a-next-js-app-to-vercel-with-nx-df81916548f5).

Only Deploy to Vercel What has Been Affected Using Nx

Wow, congrats 🎉. You did it! I'm fully aware this was a lot. I really hope you enjoyed the course. From here you can dive into different things:

- keep finishing your own Digital Garden with the knowledge you gained (send me the link once you've deployed it!)
- explore more of Next.js (hint hint, Egghead has some great courses on the topic)
- learn more about [Nx](https://nx.dev). It is probably the most transferrable knowledge item of this course as it can be applied to your next React application, Node app and more. Nx is really made to scale, so your next, huge enterprise project might just be a good moment to hop on!

Also, if you want to learn more about Nx specifically, I have another completely free Egghead course on [Scaling React Development with Nx](https://egghead.io/courses/scale-react-development-with-nx-4038)

Make sure you leave a review comment on the course if you found it useful. And as always, feel free to [ping me on Twitter](https://twitter.com/juristr) or [my website](https://juri.dev) 👋

Course Outro: Where to go from here!

Architect an Extensible Digital Garden with Next.js, Tailwind, and Nx

https://app.egghead.io/api/v1/lessons/egghead-introduction-to-architecting-an-extensible-digital-garden-with-next-js-tailwind-and-nx/subtitles

Juri Strumpflohner: [0:00] Hey and welcome to my course about developing an extensible digital garden. This is a fancy term, but a digital garden is nothing else than your site, your public website, where you share your knowledge.

[0:13] Digital garden encourages you to publish as soon as possible, so your small note, your small experiment, and over time, it encourages you to come back and evolve those notes, those experiments, to maybe a more fully fledged article. Even the small note themselves might be reused for someone else to start and get going.

[0:33] It's really about the knowledge sharing because, during that phase of knowledge sharing, what you obviously need to do is, you need to acquire the knowledge. You need to process it. You need to adjust it for yourself. Then you also need to represent it for others to be enjoyable to read. A digital garden helps you strengthen your knowledge in this process.

[0:53] In this course, we're not focusing too much on the concept of a digital garden itself. What I would like to do is to help you build the technical foundations on how you build your own platform, where you can then host your digital garden.

[1:07] In this course, what we are going to do is, we are going to use a variety of technologies, first of all, Next.js.

[1:13] Next.js is cool because a digital garden or developer portfolio site or blog usually is just a set of static files, which you might want for Markdown to compile to HTML and then serve on some static hosting provider. That's what my current blog is all about.

[1:29] The cool part about Next.js is, first of all, it focuses on performance, but it also doesn't close me the door to further extend it in the future. For instance, Jon Meyers has a very cool course on egghead about building your SaaS with Next.js and Supabase.

[1:43] It will be a breeze to integrate it into the digital garden which we're going to create in this course. You can always extend it in the future. Then there's Tailwind. This is my safety net to make sure my blog platform or my digital garden looks decent.

[2:00] I like very much nice designs, and I have a good feeling about what is a nice and cool-looking design and whatnot, but I'm definitely not a designer. Tailwind helps me there.

[2:11] Finally, there's Nx. Nx is our development tool, which you're going to use to develop this platform. It has powerful mechanism for not only creating new Next.js applications, serving them, but it will also allow us to integrate third-party tools very easily, such as Storybook or Cypress.

[2:30] As we go and develop this platform, finally, at the end, we are obviously also going to preview and ship it. One thing I would like to have you take out of this course by the end is that while we are developing a digital garden, so a personal portfolio site, if you want, which is not mission critical.

[2:51] Over the course, you will see that you will acquire a set of technologies, such as Next.js, Tailwind, Storybook, Cypress, but then also using, for instance, Nx to develop a small mono repo and see the challenges and the kind of thought that goes into structuring such a mono repo.

[3:08] These set of technologies will easily transfer also to your next professional project, even to your Enterprise project. I hope you enjoy this course, and definitely let me know how you like it or if you have questions on Twitter or on my personal site, juri.dev. Enjoy.

https://app.egghead.io/api/v1/lessons/egghead-introduction-to-architecting-an-extensible-digital-garden-with-next-js-tailwind-and-nx/transcript

https://app.egghead.io/api/v1/lessons/next-js-create-a-next-js-web-application-with-nx/subtitles

Instructor: [0:00] To get started, unless you already have an Nx workspace, you definitely want to create one. We can use npx create-nx-workspace.

[0:09] We give it a name and that's the organization name usually. Since I'm rebuilding my web platform or my portfolio page, which is hosted on Yuri.dev, I figured I'm going to ask yuri.dev directly. Then I'm also going to give it my package manager.

[0:26] I'm using yarn here because I prefer it. You could also go with npm or pnpm, which would work just as fine. During the installation process, you will get asked a couple questions. You could start with a default empty workspace or you could choose among one of these presets.

[0:44] This is highly recommended. If you already know what you're going to build mainly within that work space, these presets would already make sure that you're set up property rather than you having to install the plugins individually as you go.

[0:58] We know we're going to build a Next.js middy. This will obviously also come with React built-in so I'm choosing Next.js here. The next question that create-nx-workspace procedure asks me about the name of the first application, which it is going to generate by default.

[1:13] Since what I'm going to build here is my main website, let's just call it site for now, the lack of a better name. We'll go with pure CSS for now. Also, Nx Cloud is totally free so I can go and enable that for now. This will help me get some faster builds later on.

[1:31] Then let's have the installation process going. All right. Once installation finishes, you see a couple of links, which might be useful for exploring some things further. There's also some indication here of the Nx Cloud that has been enabled for this workspace.

[1:45] We could explore this at this URL, but that's something we will do later. For now, let's just open up our newly created Nx workspace. Let me open it up in Visual Studio code. Let's explore what has been created for us here.

[1:58] What might immediately jump to your eyes is that now we have here in apps and libs folder, which is particular to the set up of an Nx workspace. Libs four is currently still empty and we will fill that up as we go ahead in the lessons of building up my personal portfolio page.

[2:14] The apps folder already has a project in there, and that's the project which we mentioned initially during the setup process. This is our site project, our site application, which is a fully functional Next.js app.

[2:25] Furthermore, we have here a set up and a train test setup based on Cyprus, which is already wired in a way that allows me to easily test my site application here. Other things that are particular to Nx is the workspace.json.

[2:40] The workspace.json contains the metadata for our workspace. You can see there is the very top level node where you have basically the project. There's some CLI specific settings. There's some generator settings. We will explore that as well. There's the default project.

[2:56] All the commands that don't have a project will automatically jump to this default project, which allows us to spin it up much more easily. If you open up a one project node, we see it simply describes where that project sits in our workspace.

[3:11] What a source root folder is. What a project type is. In this case, it's an application, but it might be as well as a library which we'll see later. Then we have the targets part here, which contains basically all the different tasks which you might execute for our application.

[3:29] If I would want to serve my Next.js application, what I can do is I can open up the terminal, type yarn. I prefix it with yarn or npx to use basically the local version of the globally installed binary of my Nx workspace.

[3:42] Adding yarn the project name, which in our case here is site: and the target I want to invoke. In this case, serve. What this will do, is it will automatically spin up my Next.js application and launch it at a specific port.

[4:04] If I switch over to web application, you can see on port four tag 200, we have our site application on Next.js based application running. We can also shortcut these and instead of having yarn Nx run project name and the target, we can also put the target directly.

[4:21] I could say, serve site, which is my project name again, or simply just Nxserve, which retrieves the default project which again is my site project up here.

[4:32] If you have Nx console installed in your Visual Studio code workspace here, you see that icon and that also adds those code lens commands direct into my workspace.json. I could simply also just click that button here, which would simply also serve up my site just as we did before.

https://app.egghead.io/api/v1/lessons/next-js-create-a-next-js-web-application-with-nx/transcript

https://app.egghead.io/api/v1/lessons/next-js-create-a-new-next-js-page-component-with-nx-generators/subtitles

Instructor: [0:00] Now that I have my Nx workspace set up here, as well as my Next application generated, let's explore a bit what we got here. We have an app.tsx, which is basically the main wrapper around my Next.js application.

[0:15] We have already an index.tsx file generated, which uses the CSS modules. As you can see it imports it at the top here. Here we have our actual module page and we have a couple of things pre-generated for us. Let's add a new Next.js page here.

[0:32] When I'm going to my/about of my Next.js app, my About page opens up. Nx has so-called generators for us that allow us to easily create such new pages or components or projects. I will use a couple of those during this course.

[0:48] The best way to do it or the easiest way is to use this Nx console plug-in, which allows us to click generate and it will present us with a set of generators for us.

[0:59] For instance, in our case, we want to create a new page so we just select that page generator, which will ask us for a name, which is now let's call it About. The project we want to generate it in is site. The style is CSS. We leave the directory as is. We don't want to export it. All the other things are just as is.

[1:20] The cool part is also what this will give us here is it will immediately prints out what this would generate. However, it's used at the so-called dry run mode, the dry run flag, which means it doesn't have an effect on actual file system.

[1:33] It just shows what would be created whenever we click that run button. Furthermore, it also shows us the command it uses. We could learn these commands as we go and be much faster by just using our terminal window.

[1:47] For now, let's just click here run, which now creates our new page. In fact, if we go here now into the file system, we see now a new About page is being created, as well as the corresponding CSS module. To serve this site, let's use Nx serve site as we have seen before.

[2:07] This will spin up the Next.js builder behind the scenes and on localhost:4200. We should see our site being rendered. This is the default template of the index.tsx. If we go to About, we see now our About page.

https://app.egghead.io/api/v1/lessons/next-js-create-a-new-next-js-page-component-with-nx-generators/transcript

https://app.egghead.io/api/v1/lessons/next-js-understanding-next-js-getstaticprops/subtitles

Instructor: [0:00] Now that we have our About page ready, we definitely want to learn some of the basics of Next.js. I definitely don't want to go into the details of how Next works as there are a lot of courses and other resources around. Definitely check those out.

[0:14] We are going to explore just enough for our course here and for building our portfolio site. There are two main properties or two main functions of a Next.js component. There is the getStaticProps and the getStaticPaths. Let's focus first on the getStaticProps.

[0:32] If you go over to the Next.js docs, there is some good details on how the getStaticProps works. Overall, what it helps us is to define how Next.js would pre-render the page at build time. That's the important point here.

[0:45] GetStartedProps runs at build time, which means that it also allows us at that point to read from the local file system, which is really powerful, and which is also what we will need later on. Basically, it gets a context object.

[0:59] It can potentially get params from some root parameters when pages are being dynamicly rendered. We will have a look at that soon. Then in the end, it should return an optional props object, which will then be passed onto the actual page component or the React component.

[1:14] Let's have a look at a very simple example. What we want to do is first of all, define the function. We have the getStaticProps. I definitely want to type this so we can pass in getStaticProps. Since we're already using TypeScript.

[1:30] I might want to use the about props, which is basically what our component here gets. We can define here that interface and what I would like to pass is something like the name.

[1:43] Then let's define this as an async function, which takes the context object, which you have just seen in the documentation. Here now at this point, we need to return an object.

[1:55] We want to return also the props property and that props property should have some arguments on property called name as we just defined. In this case, let's just hard code it. I'm just returning here name Yuri.

[2:09] What happens is now, this props object is being returned and this will be passed as an input of our component here. What we could do here, let's distract trail. Let's say here name comes in and so here we could then simply change this one here and say, "Welcome, Yuri."

[2:29] If we save this and run through this again, refresh here, you can see now that our page reflects the change by using the property passed on from the getStaticProps.

https://app.egghead.io/api/v1/lessons/next-js-understanding-next-js-getstaticprops/transcript

https://app.egghead.io/api/v1/lessons/next-js-understanding-next-js-getstaticpaths/subtitles

Instructor: [0:00] In our About component, we have now seen the getStaticProps, which we're using here for passing on data to our Page function. The next thing we want to have a look at is the getStaticPaths.

[0:13] If we jump over to the documentation, it clearly states here that this is intended for dynamic routes, so whenever you have dynamic routes, which we might want to have, because in our blog platform or our portfolio site, we definitely also want to have a list of articles which we publish.

[0:29] For instance, this could be yuri.dev, which is the domain, and then I might have a /articles, which is the list of articles, then / and some detail article. This could be Next.js with Nx, which is the ID of one specific article.

[0:44] This last piece here is definitely dynamic. We would have some placeholder, which would then be filled in with the ID of the specific article the user is viewing. This is exactly what the getStaticPaths is about. It states here that you need to define a list of paths that need to be rendered to HTML at build-time. Again, this is important, because we want to pre-render that at build time, and not dynamically.

[1:10] From the structure point of view, you can see here, we return an object. We have that paths array in there which, again, then takes a set of parameters. These would be the ones that we will then pass on to the getStaticProps, which we have seen in our About component.

[1:27] Then, there's also that fallback. The fallback, in general, is a property where you could say, if you set it to false, that means that if Next.js doesn't find that component pre-rendered, it would stop and give you a 404.

[1:42] If you provide true, it would call back to the server and try to dynamically render that ad hoc from the server side. In our case, we want to pre-render all of our articles, so we would go with false here in our case.

[1:56] Let's go back to our application and actually implement this. In terms of the routing, you can see, whenever you have such sub-pieces in your URLs, such sub-paths, these are 1:1 reflected on your file system. Next.js has a conventional-based routing system, which would mean that, here we would have the Pages folder, and under that, we would have our Articles folder, and there, that Slug page component.

[2:23] Let's again use Nx generators to help us generate that component. I use yarn nx generate -- or I can use g for generate -- @nrwl/next, which is the plugin that has the generator, name of the generator's page, and I give it the name, which is in this case, Slug. I use those square brackets. That is the convention to tell Next.js that this is a dynamic one.

[2:46] I don't want to have styles here, so I pass style:none. We also want to make sure to say, directory = Articles, because we want to have that in Articles directory. I'm using the dry run here first to see what would actually happen, to make sure it is the correct one. We can see, we would generate that Articles folder, as we mentioned here.

[3:08] It's also interesting that the page generator, as you can see, already knows it should generate a component under that Pages folder inside our application. That's already handled by us. Then, we have that Slug component.

[3:21] Let me remove the dry run and actually generate this. We see that Articles folder and our Slug page component. We would definitely want to adjust a couple of things here. We want to not call this as Slug properties, but rather articleProps, so it is our article. Similarly, here, a component which we would call Article. That should be it for now.

[3:42] As the first thing, let's implement that getStaticPaths. Let's create the function. We also want to export this one, getStaticPaths. We also want to type it, since we have TypeScript set up. I'm using here the articleProps for now. Definitely, feel free to choose a different interface, and not reuse the same as the actual Page component takes in. That's up to you.

[4:06] Then, this is an async function, doesn't take any params. We can create the scaffold like this. We have seen, we need to return an object, overall, which has that parseArray, and also the fallback property, which, as I mentioned, we set to false for now.

[4:21] This sets us up for the getStaticPaths. We can fill in here the details. For this simple example, let me statically add in here some objects. Each object has a params that it should return. These are the ones that would then be passed on to our getStaticProps, which we'll create in a minute.

[4:41] Here, let me create a slug, and let's call this page 1. This would be the identifier of the page. You can imagine this slug here would replace here this piece, and therefore, render a component per page. Let's repeat this and let's create another object, and return this in our array here. Cool.

[5:03] The next thing would be to go and create the getStaticProps. To be quicker, let me copy that over from our About page and paste it in here. Again, we want to import the typings, and this would be articleProps. I'm reusing again here the interface for now. We would get here that params object from our getStaticPaths.

[5:26] Let me just destructure that. That would be an object where the params property is of type ArticleProps, so they match up. Down here, I would just want to return something. I could definitely take those params and process them. To keep it simple for now, let's just here change this line and return here, slug. This would be params.slug.

[5:51] So far so good. You can see we have some TypeScript issues here. That's, obviously, because we didn't update here our interface. We have here slugString. We should also implement here, the parsedURLQuery. That's something that getStaticPath expects.

[6:12] The TypeScript errors are gone. We should be good. Obviously, we should also reflect the changes in our Articles component. Basically, what you can see now here, we get from the params, the actual slug, and we just forward that for now, we proxy it through in that props object. We learned before, that the props object is being passed to the actual component, then.

[6:33] Here, we could just say something like VisitingProps. This should be then Visiting, here, page 1, if we are on page 1, and page, let's say Two, if you're on page 2.

[6:47] Let's serve the application. If we switch over to our browser and go to localhost:4200, our app renders. The About page still renders. We should also be able to go to articles/page 1. You can see now, Visiting Page 1. If we go to page 2, it would be Visiting Page 2.

https://app.egghead.io/api/v1/lessons/next-js-understanding-next-js-getstaticpaths/transcript

https://app.egghead.io/api/v1/lessons/tailwind-setup-next-js-with-tailwind-in-a-nx-workspace/subtitles

Instructor: [0:00] so to make sure that our portfolio website looks nice and stunning, we want to use Tailwind.

[0:05] Tailwind is a utility-first CSS framework which has a novel approach on styling, in general. Rather than having large CSS files, you annotate the HTML elements with very specific Tailwind classes. Those classes are already set up to make sure you follow best practices in the design of your UI.

[0:25] To get started, we definitely want to install Tailwind first. The documentation has a couple of installation guides, where you can follow along, the things you have to install. We definitely want to install these three libraries, so Tailwind itself, PostCSS, and Autoprefixer.

[0:42] As such, the thing we do at first is just add them to our workspace. This installs the necessary packages for us. Next, we want to add Tailwind support to our Next.js application. Tailwind has a command that sets it up for us. Usually, you would add, npx tailwindcss init -p. That would already take care of generating the initial Tailwind setup and the Tailwind config.

[1:10] We don't want to do that at the root of our workspace, but we want to do that for the specific applications we want to use Tailwind for. We are in a monorepo scenario, where we might, potentially, have multiple applications. We want to add it to our site project here. We just CD into that directory, and then execute, npx tailwindcss init -p. That creates the Tailwind and PostCSS config for us.

[1:37] Let's first open up the PostCSS config and define where we load our config file. In the Tailwind CSS property there, we can specify the config property. We want to dynamically load where that config lies, and so we use the joinFromThePath. We can actually just require this here. We use the path library, and then we join it with the current directory name, tailwind.config.js.

[2:07] That will make sure, even if we move that project around, it would always find the corresponding Tailwind CSS file here. We can leave the Tailwind CSS as is for now.

[2:16] Now, in order to import these styles, we have different possibilities. Either we go into that app.tsx file and we direct the import tailwind in there, so we could do something like, tailwindcss tailwind.css, or we reuse our current styles document here, which we already have set up by NX, and import all the styles in there.

[2:42] Let me first delete everything that is in here, and include the Tailwind-specific classes. We would want to have the base here, we would want to have the components, and we would want to have utilities. These are Tailwind-specific imports, which you can look up on their documentation, to get more info of what each of these is about.

[3:04] With that, this Styles document, this style.css file, basically, gets already imported into our App.tsx file, which is the global one where our application's being bootstrapped. We could go and test this now.

[3:16] Let's also remove here a couple of things which we don't need anymore. We don't need that header, which has been pre-generated for us. We rather want to keep the main and extra components in here.

[3:26] Next, let's test the Tailwind integration, see whether it works. Let's go to the index.tsx file, and let me remove all the part that is in here. This is pre-generated code, which we don't need right now. Rather than that, let me paste in some Tailwind setup, which already uses some Tailwind classes, which will allow us to verify whether Tailwind is properly set up and working.

[3:49] Now that we have done that, let's start the application again. Then, if we go to localhost:4200 and load it up, we should see the site start with Tailwind. You can clearly see here that the font is different, we have some start buttons, we have some hover effects. This is Tailwind in action.

https://app.egghead.io/api/v1/lessons/tailwind-setup-next-js-with-tailwind-in-a-nx-workspace/transcript

https://app.egghead.io/api/v1/lessons/tailwind-configure-tailwind-purging-in-a-nx-workspace/subtitles

Juri Strumpflohner: [0:00] What makes working with Tailwind really nice is that by importing in our global styles.css file, these three things, we are set up to style our page for whatever we need. Basically, we can just apply here these specific classes on top of our DOM elements, and then they will get styled.

[0:20] What does that mean in terms of the bundle size, ultimately, because we used Next.js specifically, to make sure that we have a good Lighthouse score in the end, so a small bundle that loads up fast? Let's have a look.

[0:33] We can use the nx build command, and pass in the name of our project -- which is, in this case, site -- to create a build of our artifact. If we scroll up here, we see the CSS that gets created. That's huge. We just have one index.tsx file with a couple of classes on top of that, and it is 306 kilobytes. This can get even worse, up into the megabytes, if you add things such as typography, dark mode, and things like that.

[1:03] If you go over to the Tailwind docs, there's a specific section for "Optimizing for Production" where in fact they specify that the development build of Tailwind can get up to multiple megabytes uncompressed. We definitely want to make sure that we tear that down to whatever we are just using on our website.

[1:20] Tailwind has that method that is called Purging. That means it would scan your CSS files, your HTML files, your components for unused Tailwind classes and remove them from the overall CSS. You can do that by configuring that purge option and giving it all the globs to potential sources where Tailwind is being used, in our HTML files, even if you use Vue.js, in your Vue files, JSX, or TSX files.

[1:48] If you go back to our application setup, let's find our Tailwind config. Let's have a look what we have in there. Right now, you can see our purge option here is empty. The one thing we definitely want to do is we want to purge everything that is within that pages folder because that's where our components live right now.

[2:07] Again, we can use the join functionality to directly generate that path to those files. We can import that from the path node utility. Then, we go down here. We join basically with the current directory name. Then, we would pass in something like 'pages/**/*.{js, ts, jsx, tsx}' files.

[2:32] Futhermore, the Tailwind docs mention that whenever you compile your CSS, make sure that the 'NODE_ENV' is set to 'production' so Tailwind will automatically purge unused styles from your CSS. That's already taken care of by Nx, so we could just check that out and retry our build now.

[2:50] Once that builds finishes, you can see now that the CSS file is much smaller. It's actually just 1.8 kilobytes compared to the more than 300 kilobytes which we had before. The purging actively works.

[3:02] There's more we might want to do, though, since we live in monitoring per scenario within Nx. In Nx application, you don't just have the things within that pages folder, so structured within that apps folder. Rather what you do is usually split up the logic into different libraries, which are then consumed by some application or by even multiple applications up here in that apps folder.

[3:23] That means the apps folder in theory is really thin. It just combines things out of that libs folder. We could actually create a glob that includes all the libs folders. In our small example, this would actually work perfectly. However, as you scale and as you have a more real-world scenario, that might be a waste of computation power.

[3:42] What we did in Nx is actually create some utilities that allow you to dynamically collect those library glob patterns based on whatever you use within your application. Let's have a look.

[3:52] We can import that from the utility provided from nrwl/next/tailwind, and that exposes a function that is called createGlobPatternsForDependencies. What we can do is we can go up to that purge array here and destructure it by invoking a function directly with the current directory name.

[4:15] You have, then, more options in the sense of providing some custom file glob patterns. Basically, if you don't want to include all the js, ts, jsx, tsx files, you can also provide a custom one that will be attached to the generated glob patterns.

[4:30] Overall, what this function does, it automatically uses the internal Nx dependency graph to understand whatever you import here in that site project from that libs folder down here would also be included in the overall purge patterns here.

[4:44] As a result, you would only really purge whatever you're using. Thus, it would be efficient during the build time but also make sure you actually include everything that should be included.

[4:53] Since we don't have any libs yet, the actual build would be the same. It will still be very small. You can see it's still 1.8 kilobytes. Nothing actually changed. As we evolve in this course and create more content down in that libs folder, we would actually start benefiting from this utility function.

https://app.egghead.io/api/v1/lessons/tailwind-configure-tailwind-purging-in-a-nx-workspace/transcript

https://app.egghead.io/api/v1/lessons/tailwind-configure-tailwind-in-a-nx-monorepo-with-potentially-multiple-apps-and-libs/subtitles

Instructor: [0:00] Apart from the default configuration, Tailwind comes also with a set of plugins. They can be either created by the Tailwind team directly, or by the community. You can just install MS normal npm packages, and then you reference them in your Tailwind config under that plugins section.

[0:17] One plugin from the Tailwind team that might be interesting for us, is the Typography. What that allows you to do is, for instance, at a top-level node, just add a couple classes, and then this package would make sure that all the H1s and P tags within that article, for instance, are styled properly.

[0:34] Let's have a look how we would configure that in our Nx workspace with Next.js. Let me copy this name here. Let's go over to our workspace, and first of all, add that package. Once we have added that, the next step would be to go into the Tailwind config, and add it under our plugins section here and install it. Basically, we would do require, and paste in here this Typography plugin.

[0:59] This works perfectly. Again, since we are in a monorepo scenario, we might want to look a bit ahead of it, and think about what might happen if further applications join our workspace. Right now, we have just this Site Project as an application, but there might be multiple ones.

[1:14] In a more enterprises setting, where you might have different teams joining that workspace and also wanting to use Tailwind, you might come to a situation where you might have a specific Tailwind configuration for an application, like different colors or also different plugins installed.

[1:30] Then again, you might have, at the more corporate level, design guidelines at a more higher level, so at a workspace level. What this means is that we might want to have a more global-level file. Let's call this 'Tailwind Workspace Preset.' You can really name this as you want, and have a more global configuration here.

[1:49] For instance, let's assume that we want to use the typography at a global level. Rather than actually having it in here, we would remove it from here, go to our workspace setup, and paste it in here. Obviously, we also need to extend now our Tailwind config from here. What we could do is just use the according preset property on the Tailwind config, and require our file.

[2:16] We would go up to the workspace root and choose the 'Tailwind Workspace Preset' and just import that. In that way, we connect a global-level Tailwind preset that works for our entire organization, and import it into our local Tailwind config for that specific site project which we're having. Here, we can then further customize things that make sense just for our application, specifically.

https://app.egghead.io/api/v1/lessons/tailwind-configure-tailwind-in-a-nx-monorepo-with-potentially-multiple-apps-and-libs/transcript

https://app.egghead.io/api/v1/lessons/tailwind-configure-and-use-tailwindcss-jit-mode-with-nx/subtitles

Instructor: [0:00] In our Nx workspace, we have Tailwind configured properly. We even configured the purging here, which makes sure that our CSS is as small as possible.

[0:08] One thing to notice here is that the purge mode only works in your final production build. Whenever you execute actual build and you run in the production mode, meaning the mode and variable should be set to production, Tailwind will use this information here to purge our CSS.

[0:25] During development, however, the browser gets the maximum build of Tailwind, whatever you have included in your CSS at the moment you launch the browser.

[0:34] The Tailwind folks have introduced the so-called just-in-time mode. If you scroll a bit down in their docs, there are a set of advantages listed, which are pretty obvious at this point. First of all, you get lightning-fast build times, because Tailwind can incrementally adapt as you change the CSS, and therefore, can be much faster.

[0:51] Another advantage which I see, especially, is that the browser performance will be much better, in the sense that, during development, you might ship lots of megabytes of Tailwind CSS to the browser tools. If you start inspecting the CSS on the document, it might take a bit, because the browser development tools have to process all those megabytes of Tailwind CSS.

[1:13] Obviously, with the just-in-time mode, only what you need right now would be shipped to the browser development tools, and therefore, it would be much more performant. Let's see how we can enable this in our Nx workspace. First of all, what we need to do is enable JIT mode in our Tailwind configuration. We can say mode: 'jit'. With that, we have enabled it.

[1:37] One thing we need to make sure we do, is when we run our process, we don't just serve the application, which is Site in this case, but we also pass an environment variable to it. We want to add here, TAILWIND_MODE=watch, and pass that to our command here, because that will instruct Tailwind to continuously watch as we change the files and rebuild behind the scenes.

[2:01] As you can see in the log, you see that Tailwind CSS is watching for changes, and that you're using the JIT mode. Apart from that, it still works as we expect. If we open up our browser, we can still see all the Tailwind CSS being applied correctly.

https://app.egghead.io/api/v1/lessons/tailwind-configure-and-use-tailwindcss-jit-mode-with-nx/transcript

https://app.egghead.io/api/v1/lessons/tailwind-use-getstaticpaths-to-retrieve-a-list-of-markdown-files-to-render-with-next-js/subtitles

Instructor: [0:00] One thing that we definitely want to have on our portfolio side is a list of articles. Basically, our blog. First of all, let me create at the very root of our workspace, a folder called Articles. Let me create one as a sample, which we call Dynamic Routing. This is a markdown file, and I'm pasting in here some lorem ipsum text.

[0:21] Basically, this is what a potential article might look like. We have some front matter, which has some metadata which we can then use for rendering the author, the date, or the title. Then, we have the actual markdown content which should be rendered on our page.

[0:35] Now, previously, we have already equipped our Next.js application here to be able to dynamically render pages. Here, in that slug, what we see is a page component that renders some static data, which we have to find here in the getStaticPaths. With the getStaticPaths, we define what potential pages need to be rendered. Here, they are static. In fact, if we go to our website and refresh here, we see that we can route to something like article/page 1, and we can go to page 2, while, for instance, page 3 would give us a 404 because we didn't hard code it in here.

[1:11] Obviously, we don't want to have something like this, but we would rather want to read whatever is in this Articles folder, and for every entry, generate such a NewPage component. To get started, what I would want to do first is define a variable that holds the path to that Articles folder. Let's call it Post Path.

[1:32] We can here use the join operator, which we can import from the path, and use the current working directory by the process.cbd, and from there, the Articles folder. The current working directory, since all the processes are being invoked at the root of our workspace, this would be the root, and then the Articles folder, which leads then to that Post Path.

[1:53] Once we have that, we can go down here and generate these path array here dynamically. Again, we can use the file system. We use the readdirSync of that Post Path. That would give us all the paths which are in that directory.

[2:12] We want to map that because we want to get rid of those extensions, the file extension, because in the URL file, we would want something like /articles/dynamic-routing, and not -routing.md. What we do here is, for the path which we get from that readdirSync, we replace the extension.

[2:31] We do replace, and there are different ways, obviously, how we could do that. I'm just using a simple regular expression. I'm replacing the .md or, potentially, .mdx, and we replace it with nothing, so it cleans that out.

[2:44] Then, we also want array to prepare it to the structure that this path's property expects. It expects an array, where there is a params and a slug in there. We want to do that as well. Here, we would get our slug, and we want to return an object that has a params property, and in there, it has our slug.

[3:04] With this, finally, we can replace that entire array here, and just pass in whatever we have up here. We obviously need to assign this also to a variable. We would have something like paths up here. This will be passed along to our getStaticProps, which right now, just passes it ahead. Finally, our article should render this slug, whatever is being found in the Articles folder.

[3:26] Let's go back here. Let's test, for instance, if you go to page 1, this would lead to a 404, because it doesn't exist anymore. If you go to something like Dynamic Routing, we should see our article being rendered.

[3:40] You can see that slug is being rendered out of the name of the file. It is on the file system, and then visualized here.

https://app.egghead.io/api/v1/lessons/tailwind-use-getstaticpaths-to-retrieve-a-list-of-markdown-files-to-render-with-next-js/transcript

https://app.egghead.io/api/v1/lessons/next-js-generate-an-nx-library-to-implement-our-markdown-rendering-for-our-next-js-app/subtitles

Instructor: [0:00] So far, we are able to read all the articles in that Articles folder, pass them out here, take the file name and pass that on to our Page component, which then just visualizes the filename itself.

[0:13] Obviously, the end goal, what we want to do, is actually parse this markdown document, separate it out into the front matter piece and the actual content, and then obviously convert that content into HTML and render it within our Page component.

[0:27] Normally, what you would do is create that logic either inside that Page component, which is probably not a great idea, or add the logic inside your Next.js application, because in a normal setup, that is what you have.

[0:41] In an Nx application, or an Nx workspace or monorepo scenario, you have multiple applications, potentially, and then you might have multiple libraries down here. The suggestion is to put as much logic as possible into that Libs folder, such that the applications are really just a container that links to various libs down in that Libs folder and, basically, binds together a set of functionality, for then being deployed to some production site.

[1:09] Similarly, in our case, the whole logic of parsing the markdown and rendering it as HTML is not really something that is tied to our specific use case of that blog article or portfolio site. Maybe tomorrow, we are adding some other application in here, and we might want to use the very same logic there as well.

[1:27] What I'm going to do here is generate such a library. I'm using Nx console because it's the easiest way to generate that, especially if you don't know the command. If I type in library, I can filter all these generators to just the library generators.

[1:41] Here, you have three different options. The first two are more specific to the actual framework, so either Next or React. What it does is simply preset your library setup, your tsconfig, and babel configuration, such that it best fits either Next or React.

[1:56] The workspace library, on the other hand, is more bare-bones, in the sense that it sets you up with the bare minimum you need for creating TypeScript libraries and TypeScript code. We are going with that because we don't have any components or Next.js-specific things living in there. We're calling this Markdown. I can leave all the other settings as is for now.

[2:16] You can see here, we get a preview of what would be generated when the executor runs. Notice, you can also see the command that is executed here. You could copy that, and later on, reuse that by pasting it into the console. You can also copy it by clicking this button here.

[2:33] Let's click the Run button, which now would actually generate the code for us. If you go back into our file structure here, we see now the library, which is that Markdown library, which has already some pre-generated code for us in here. Let's go to our Page component and look at the implementation. We get the path of our file, which we want to parse in the end from that slug. This is being passed to our getStaticProps.

[2:59] Here, we would want to have two different functionality. First of all, we want to parse the content of our Markdown and separate it into the front matter and content. Then, as the second piece, we want to convert the Markdown content into HTML and then pass everything onto our Page component.

[3:19] Let's create these two methods in our actual library for the Markdown parsing. First of all, we can export here, const getParsedFileContentBySlug. We would get here, the file name, which is a string. Also, we would not need the actual Post Path, which is also a string, to be able to read the file.

[3:41] Once we have that information, we can then implement that and return the result. For now, let's just create a skeleton and return NULL here. Similarly, here, let's call this renderMarkdown, make it a bit more explicit. This one just returns Markdown for now, so we can leave this as is.

[3:57] Both of these functions are being exported directly by that index.ts file. As you can see here, the main libmarkdown file is being exported. This is basically the public API of our library. We can have hidden things within our library, which might be implementation details, which we don't export here, and the export orders, which we might want to reuse outside.

[4:17] The interesting part is also, that once we have generated that library, we also got a new path mapping generated in that tsconfig.base by Nx. You can see here that this namespace, which is basically a composition of our workspace prefix -- which is yuri.dev in my case -- /, an extra library name. That maps, then, to the index.ts file of our library which we've created.

[4:40] This allows us, in our Page component, for instance, to import these methods. I can go ahead here and from yuri.dev.markdown, can now import the actual getParsedFileNameBySlug, and the renderMarkdown function. With both of those imported, we can go ahead and reuse them.

[5:00] Basically, here, I am having then the article, Markdown Content, which I get from that parsedFileContentBySlug, which we just created, which takes the perms.slug, which is basically the file name as an input, and also needs that Post Path. That would return me the content.

[5:19] Then, once I have that content, I can also then render the HTML by invoking the renderMarkdown function and pass in the article, markdown content into this here.

[5:31] Now, obviously we need to see, once we implement a specific function, what the return type of this is. Basically, a return type that just gives us the content, would then be passed on to that renderMarkdown function.

https://app.egghead.io/api/v1/lessons/next-js-generate-an-nx-library-to-implement-our-markdown-rendering-for-our-next-js-app/transcript

https://app.egghead.io/api/v1/lessons/next-js-parse-a-markdown-document-with-gray-matter/subtitles

Instructor: [0:00] Now that we have the skeleton functions that we need for, first of all, parsing the Markdown and then also rendering it as HTML, we can now go ahead and actually implement it.

[0:09] Let's get started with that getParsedFileContentBySlack first. In order to do that, we will need a library. We're going to install gray-matter, which will help us parsing our Markdown and separating that front matter part, which has metadata from the actual Markdown that we need for rendering as HTML later on.

[0:30] Gray-matter imports a function called matter, which you can then use to parse our content in. We can invoke that matter function, which gets the actual content, which is the content of the file, and which would return then the front matter part as well as the actual data.

[0:48] Right now, we don't have the content. Let's use an empty string instead. We can destructure it in data, which is the front matter part, and content, which is the actual Markdown content, which is also what we are going to return, ultimately. Maybe let's use front matter explicitly here so that it is better understandable. Then we have the content, which we then return, finally, to our calling function.

[1:09] Let's get to the actual content that we can pass to that Matter function. For that purpose, we need to read the file, basically, our Markdown file here. We know that we get here the slug from our Page component, which will be dynamic-routing without the extension.

[1:24] We can construct that path, again, joining the Post Path, which we get. Plus, we can generate that extension by using slug and .md, because we know this will be a Markdown file. This is not called slug here, but file name. This would be our post_file_path. We can read the content, and we give it that post_file_path, which is actual content.

[1:47] Now, having the content, we can change this here and pass it to the Matter function, which will then return it parsed to the caller. Going back, then, to our Page component, we already have this wired up. We get here the articleMarkdownContent, which as you can see, gets now the front matter.

[2:04] For now, let's just return here the front matter to our Page component, and let's also render that. Let's add here just a class name and a bit of a margin around our content here. Let's create an article note to get some nicer looking. Then, we'll have our H1, which is the title, which we can now directly read from that front matter that gets passed to our function here.

[2:26] Let me change here the implementation a bit, and destructure directly that front matter which we get from the getStaticProps. Here, inside, I can use now the frontmatter.title as our title. I can also add another div for the author, for instance, which would be then frontmatter.author.name, which is exactly how it should be specified in here. We have the author name, which then is the author, and so we render it out here.

[2:53] If we now start our server, and once this has booted up, we go to localhost:4200, we navigate to the articles and Dynamic Routing, which would lead us to the page which we have just rendered. We can now see the title that is being printed out, based on the front matter as well as the author.

https://app.egghead.io/api/v1/lessons/next-js-parse-a-markdown-document-with-gray-matter/transcript

https://app.egghead.io/api/v1/lessons/mdx-render-markdown-with-next-mdx-remote-in-our-next-js-page-component/subtitles

Instructor: [0:00] The first step is done. We are able now to read the front matter. We passed it on to our Page component, and we render it accordingly in the Page component itself. In fact, if you visualize our website here, we see the title and author being rendered.

[0:15] The next step is to actually render the content, so the Markdown content. For that purpose, we need to first convert it to HTML. We know that this article Markdown content here contains the front matter, as well as the content. The first step will be to pass that ahead to our renderMarkdown function.

[0:32] Let's jump into that and customize it. This now takes the Markdown content. In order to render the actual Markdown, we will again use a library. Let's install here, next-mdx-remote, as our Markdown parsing library, which will allow us to convert it to HTML.

[0:51] The next-mdx-remote has a function called serialize, which is exported from the next-mdx-remote/serialize. This function is quite easy, because it allows us to simply invoke that serialize, pass the Markdown content. We might want maybe to safeguard this in case for some reason Markdown content is not defined with passing an empty string. Then we return everything back to the caller.

[1:15] Since this is an async operation, this would be a promise of type string. Let's remove this for now, and let type string for the type. Now the implementation is done. We can go back again to our Page component.

[1:27] We have already invoked here the random/Markdown, so we already get the rendered HTML back here. We can just go down here and click through the HTML which would be our rendered HTML. As a result, our component now gets the front matter and HTML. We can now render this into our component.

[1:46] For that purpose, the next-mdx-remote also has a component exposed, which is the MDXRemote component, which is export from the next-mdx-remote. Once we have time, we can go down here just below our article, maybe including HR tag in-between. Then we use the MDXRemote where we can directly pass the HTML and render that to our page.

[2:12] Again, let's start our server. If you go to 4200, refresh. We actually get here an error, and it looks like we return a promise somewhere, which we don't await I guess. In fact, the render Markdown is a promise, so we need to await that.

[2:29] The getStaticProps is already marked as an async function, so we're good there. We can just save and refresh again. Finally, we see our content being rendered. We see the title, the author, as well as the HTML that is being rendered out on the page.

https://app.egghead.io/api/v1/lessons/mdx-render-markdown-with-next-mdx-remote-in-our-next-js-page-component/transcript

https://app.egghead.io/api/v1/lessons/next-js-embed-react-components-in-our-markdown-with-mdx-in-a-next-js-app/subtitles

Instructor: [0:00] Our portfolio site is now able to render Markdown on our page, which allows us to publish our articles. We definitely don't want just visual aesthetic content, but also more dynamic content, that makes the whole experience of reading these articles much richer.

[0:14] Many other static site generators have the possibility to include so-called snippets or templates within the actual content. For instance, if we would want to embed here a YouTube video, based on the syntax you're using, you might be able to say something like, YouTube, and give it a URL, and then, this would embed automatically some YouTube video, based on a URL within that content.

[0:36] We want to achieve something very similar. One approach to go here is to use MDX. MDX adds the possibility to embed within your actual Markdown document, also code. As you can see here, for instance, there is some code logic being embedded. It's similar to JSX, but for Markdown.

[0:55] This allows for a very rich experience and gives us great flexibility, as we can import here our React components within our Markdown content and mix and match them together.

[1:05] Let's implement that for our own portfolio site. First of all, I'm going to rename, here, these to MDX. We also need to make sure that in our Markdown rendering logic we use your MDX as our file extension. With that, we are set up.

[1:21] The next thing is we need to import a set of components which we want to be able to render within a Markdown document. The MDXRemote component here already accepts a components property, where we can pass in components that should be detected within a Markdown document.

[1:38] Since in an Nx workspace we would want to host these components in a library down here, I'm using the generator again to generate a new library. This time we're using the console, and we're using nx g for generate now our React, because we want to generate a React library.

[1:54] We call it MDX elements. I want to place it into the directory=shared, because this might be shared across multiple applications. Then I can use the dry run to see what would be generated. I am using CSS for this library. We can see it would create in the libs shared an MDX library with some couple of content or a pre-configured.

[2:17] Let's remove the dry run. Let's, again, confirm the CSS choice here. Now we get a new library created with already some MDX elements in here. These are just empty components that have been pre-configured for us. We probably won't need those. We can actually go and remove these.

[2:34] Rather let's generate a new component in our new library that is called YouTube for embedding YouTube components. Let me pull up here the activity bar again, and use Nx console to generate that component. I'm searching here for component. I'm creating a React component because it just doesn't necessarily have to do with Next.js. Let's call this here, YouTube.

[2:56] The project I want to generate this in, is my shared-mdx-elements. I'm using CSS for the style, so we can leave all our other changes untouched. We click Run, and it generates now a new component within that MDX Library.

[3:08] We can now go in and customize this. Our YouTube component would probably get a title, which you might want to render alongside with the component, and a UUID, which is the ID of the YouTube video which you want to embed.

[3:21] In terms of the implementation, we would have here an iframe, which is what you get from a YouTube video, which has a source. We can construct that source, and use here a props.uuid as identifier of the actual endpoint. Let's add here a width and a height. Obviously, you can configure that as you prefer, in your own setup . Maybe, also let's include here a title, which comes from props.title.

[3:48] With that, we have our YouTube component set up. We also want to export this from our library here. We go to that verify, that index.ts file here, and export everything from libyoutube. With that, we can now go back to our actual page component again. At the very top, we want to import the YouTube component.

[4:06] Now we have a new library which we just created, which is that shared-mdx-elements, which exports that YouTube component. Once we have that in here, we can go ahead and pass that to the MDXRemote component.

[4:18] Now, we might want to group these MDX elements a bit further, to make it easier to pass them to the MDXRemote component. Let's create here an MDX elements object. We pass all these MDX elements to the components properly, of our MDXRemote. With that, we should be able to embed a YouTube video just in our content here.

[4:40] Let me add here some YouTube video from my own channel. Let's restart our server again. If we go to our localhost and refresh, we see our YouTube component being embedded within our page.

https://app.egghead.io/api/v1/lessons/next-js-embed-react-components-in-our-markdown-with-mdx-in-a-next-js-app/transcript

https://app.egghead.io/api/v1/lessons/next-js-use-react-components-for-native-html-tags-with-mdx-and-next-js/subtitles

Instructor: [0:00] MDX is really powerful for making your content interactive, such as like embedding here our YouTube video, and in general, also for writing the articles, because embedding a YouTube video is handy, rather than copy-and-pasting entire iframe HTML pieces into our Markdown document.

[0:15] There's another interesting feature. Assume that we have some links, so my website, which then goes to https://yuri.dev. These are plain links. If we go back to our rendering, this would be rendered out by our Markdown renderer as an HRF.

[0:33] We might not want to also create here a custom link component, all our links needs to be written in a certain manner. Rather, we want to stick to how Markdown defines the links. Also, because most of the tooling would support this way of writing them.

[0:47] The next-mdx-remote allows you to actually override the existing tags as well, with custom components. Let's create a new component into our MDX Elements library. Again, I'm choosing here our React component. Let's call this CustomLink, and the project, mdx-elements.

[1:06] If I go again back to our library down there, we see that new CustomLink being included here. Let me embed here an entire piece of code. Here you can see now, we create a new component that is called CustomLink, which uses here the NextLink component, and wraps basically now HRF around it.

[1:25] Let's maybe also add here some class, so that we can easily distinguish our link later in our Markdown document. Let's add here some background. We also need to make sure this is exported again from our main library here. Finally, if we go back to our page component, we would want to import it here as well.

[1:44] Once you have it in here, we need to include it in this mdx-elements object, which gets parsed to the mdx-remote. What we can do here now, is we can say, whenever there is an tag within our document, use our CustomLink instead.

[1:59] If we go now to our website and refresh, we go to the very bottom, we see our link, which clicking it works. It doesn't have the background set yet, probably due to a conflict with the CSS overrides. We can clearly see that our class has been applied, which means that our custom component is rendered here, rather than the standard HRF link.

https://app.egghead.io/api/v1/lessons/next-js-use-react-components-for-native-html-tags-with-mdx-and-next-js/transcript

https://app.egghead.io/api/v1/lessons/next-js-dynamically-loading-react-components-with-next-mdx-remote-and-next-js-dynamic-imports/subtitles

Instructor: [0:00] When importing these MDX elements to be included within our page dynamically, one thing we might want to pay attention to is the actual performance of our website.

[0:10] Once we have more and more such dynamic components in there, we might want to load them in dynamically, just whenever they are present, because we could totally imagine a situation where we have another article here which does not have a YouTube component.

[0:25] What we can do for that is to use the dynamic import that is offered by Next.js, from next/dynamic. What that allows us -- and let's, for the moment, comment out here that custom link -- is to load this in dynamically.

[0:40] We use that dynamic function, which just doesn't call back, and we then dynamically import our YouTube component from our MDX elements. Once we have those components, we return the Components.YouTube. Obviously, we need to make this async as well. With that, we can then remove the hard-coded import up here.

[1:01] If we start our server again, then let's first here navigate to "Another article," which is our plain, normal article. If we look at the JavaScript that is being pulled now, we see some JavaScript being injected. Pease note that right now, we're running in development mode. Obviously, we see a lot more JavaScript being pulled in here.

[1:20] Once you will see that we navigate through the dynamic routing article, we not only have the traditional JavaScript, but you also now have that separate MDX elements being pulled in. What you see here, this is our chunk that has been split up by webpack, which includes basically YouTube component and the others that are exported by MDX elements.

[1:44] If you want to make high usage of such dynamic imports, we might also think about the strategy of how we want to modularize our MDX elements here. Obviously, if we export all the components from a single MDX elements library here, all of those would be pulled in.

[2:02] In case we want really high dynamic behavior, we might want to split out those components into different libraries or either do deep imports. I normally suggest it to have one single entry point here. You can totally go to your tsconfig.base here.

[2:18] You might want to include another path here and customize it such that everything that comes basically after this path here gets directly pulled out of the src/lib. If you go back to our page component, we can go here now and include the YouTube component directly in here. We can now return this, as we already got the component out of this.

[2:44] If we serve our site again and go back to our website and refresh, we would see the YouTube component still gets pulled in. We also see that dynamic import. We have the YouTube component being pulled in here, but we should not have, for instance, the custom link, which in fact is not present.

[3:03] This allows for a much more fine-grained import based on the configuration of how you set up your tsconfig here.

https://app.egghead.io/api/v1/lessons/next-js-dynamically-loading-react-components-with-next-mdx-remote-and-next-js-dynamic-imports/transcript

https://app.egghead.io/api/v1/lessons/next-js-using-environment-variables-with-next-js-and-nx/subtitles

Instructor: [0:00] Right now, we hard code a path to our Articles folder, which is not ideal. We might want to have it more customizable, especially if we want to reuse it from different parts of our application, or even Nx workspace.

[0:12] If we go to the Nx docs, Nx supports environment variables. It has support for different form of naming schemes which you can use, like basically, have a .local.env file or vice versa, or just an env file.

[0:27] You can have it within an application, or also at the workspace root level. Depending on where you place it, it would be injected just like here, if you start MyApp, while if you have it at the root level of the workspace, it would be injected into all applications.

[0:43] Similarly, also, Next.js has support for environment variables. If you want to have it bundled into your JavaScript, you can just add it to your next.config here with that environment object, and then specify whatever key and value you want to use. Later on, they also started supporting, starting from 9.4 onwards, to have a local env file.

[1:05] Which one you're going to use really depends on your use case. In our case, since that Articles folder is our global thing which different applications might use, and it is not just local for our Next.js application which we have in here, we might want to create here just a .env file. In here, we pass the article Markdown path, and we give it a value.

[1:28] Once we have that, we can then go in here and replace this piece here with process.env.articlemarkdown path. Now, if we start our server, we can go and check whether it still works. If we go to localhost, we see that it still renders the page. It means it probably was able to read the actual location of the folder from the environment variable.

https://app.egghead.io/api/v1/lessons/next-js-using-environment-variables-with-next-js-and-nx/transcript

https://app.egghead.io/api/v1/lessons/mdx-add-fast-refresh-support-to-our-mdx-files-with-nx-support-for-custom-next-js-servers/subtitles

Instructor: [0:01] In order to improve the developer experience, Next.js comes with live reloading. For instance, if I remove this title and save the component, you can see immediately, the changes are reflected on the right-hand side in the browser.

[0:13] However, if we go to our Dynamic Routing page here, and I add some new content here and I save, there's no effect. No live reloading happens on the browser side. We already need to go there, hit the Refresh of the browser, and then we will see our text being rendered.

[0:30] Now, since we are in an Nx workspace, we launch our application with nx serve site. This does nothing else than invoking the serve target on the project site. As we have seen before, this is configured in the workspace.json. If we go in here, we can see the various projects. There are libraries in here, as well as our site project, which is our Next.js project. This is of type, application.

[0:56] This has different targets. In this case, it has a build, it has an export target, a test target, and so on. In our case, we invoke the serve target. Each of those targets has a so-called executor attached. This is the program that is situated within the @nrwl/next Node package. There's a so-called server entry point, which is a program that gets invoked, and all the options are being passed to that, such that that one can handle the actual serving, in this case, of the Next.js app.

[1:24] If we go to the Nx docs, we can actually find that executor. That executor has an interesting property, which is the so-called custom server path. This allows us to pass in a path to some custom script, where we can define how we want to instantiate our Next.js server. This is exactly what we are going to use, in order to implement hot reloading or live refresh, also for our MDX files.

[1:48] As a first step, I'm going to place my logic here in the Tools folder. The Tools folder is usually used for custom scripts and utilities, which you might need in your workspace, in order to work with other libraries.

[2:00] You could also create a library dedicated for this specific piece. That would be particularly useful if we would need to pre-build it. In this case, we can just define a TypeScript or JavaScript file, and that will be picked up automatically by Nx.

[2:14] Let's create here a folder, let's call it "Next Watch Server." Then, let's create a file in here that is called next-watch-server. Let me just paste in the actual code, and let me walk you through what is happening here.

[2:28] First of all, you can see those libraries. We use Chokidar for detecting whether changes happen on our file system. Let's, first of all, install that. The function exposed by Nx is the following. We get a Next server instance, which Nx boots for us, and passes ahead to that custom server if that is specified.

[2:47] We have some custom options here, some settings, that are being passed in here via the configuration in the workspace.json, as well as a proxy config, if that is required. We copy in, more or less, the exact same functionality that the actual Next Nx server includes, which you can find in that package here, @nrwl/next, and then the server file.

[3:09] The only thing we change here is really re-read our article path. We instantiate Chokidar on top of that article path. What that gives us, it gives us a callback. Whenever something in that path changes, this callback is being invoked.

[3:25] The app here is our custom Next server. Notice, that I put a comment on top of here, that we are using a private API. This hot reloader is not exposes a public API, unfortunately, by Next.js. We're directly calling into that and sending it a Building, and then Reload Page command.

[3:46] Finally, we just instantiate an Express server as Next.js does behind the scenes, or better, the Nx-specific implementation of such a Next.js server. Finally, once we have defined these, let's copy here the relative path. We need to go to the workspace.json and configure our Next.js serve target here, and pass the custom server implementation.

[4:08] Here, in the options, I'm adding the custom server path. Let's add in here the Tools folder. This is relative to wherever the application's running. We need to navigate out to the actual root of our workspace, and then into the Tools folder, Next.js and next-watch-server.ts.

[4:29] If we restart our server and then go to our actual Markdown file...and let's remove here the line which we added. If we save, you can see automatically on the right side, the browser refreshes just as it did before.

https://app.egghead.io/api/v1/lessons/mdx-add-fast-refresh-support-to-our-mdx-files-with-nx-support-for-custom-next-js-servers/transcript

https://app.egghead.io/api/v1/lessons/next-js-scaffold-a-new-blog-post-article-automatically-with-nx-workspace-generators/subtitles

Instructor: [0:00] so, one of the strength points of Nx is definitely its generators. When we started creating our Nx workspace right at the very beginning, that was a generator that actually scaffolded out the whole Nx workspaces. It internally launched an auto-generator that created for us the Next.js application with all the setup.

[0:19] We've used a couple of generators to create our various libraries in here. We mostly use them through Nx console. For instance, when we created a library, we choose the library generator. If we want to create a new application, we just can choose application, and we get the options for creating Next, React, and Web applications, based on what we have, basically, installed.

[0:40] The built-in generators is just one way of allowing you to get a lot of automation out of an Nx workspace. It becomes even more interesting if you can create your own generators to automate your local workspace.

[0:54] That is not only useful for our specific scenario here, but also in a bigger enterprise scenario where you might want to generate, for instance, your Next.js components in a specific way. You could totally create your own generator and generate them out as you prefer to have them within your company.

[1:10] In the case of our simple portfolio website what we might want to create is a generator to set up our blog articles. As we create a new blog article, we might want to generate out here, the title, the date, the author, and maybe even some text initially, that gets us very quickly started to write a new article.

[1:29] These generators that are local to workspace are called workspace generators. Let's create a new one. We can go and generate a new workspace generator by using the @nrwl/workspace package, and in there, the workspace-generator. We call it new-article.

[1:46] If we hit Enter, what you will see is, in that Tools folder, it will set up a new generators folder. In there, we get that new-article folder. This comes in two pieces. There's an index.ts file, which is the actual logic of the generator, and then there's the schema file, which defines the metadata of the generator itself.

[2:05] Let's first start with this schema here. The main point here is the properties part. We definitely want to have the name of the article. Let's call it, maybe, title. Here, you can see, by specifying the default here and the argv, which means that the first parameter that is being passed to our generator, on the comment line, would be this title.

[2:28] We also want to make sure that we have a title, so this would be a required property of our generator. Next, we want to create an author. This, again, is of type string. We also might want to add a description. Finally, we also might want to have an excerpt. As a required parameter, we have the title, and we also might want to make sure that we have an author.

[2:52] This is the metadata. Whenever you invoke a generator, Nx uses this metadata to validate the parameters that you to pass to the generator when you invoke it. Whenever you pass, for instance, for a title, a Boolean value, rather than a string, it would complain. If you miss one of the required parameters, it will complain as well.

[3:09] Let's go to the actual implementation of the generator and see what we have here. We have some predefined configuration set up already, that shows an example of invoking an existing library generator within here.

[3:21] This is a useful example if you want to compose different generators together. It shows how you can format the files with [inaudible] within your workspace. Also, if you need, how you can launch and install packages tasks, if, for instance, your generator adds new Node packages.

[3:34] In our case, we don't really need all of this. The only thing we want to keep maybe, is the formatting of the file, since we definitely want to generate new files. That's the first task. Whenever we create a new blog article, we want to generate a new file in here.

[3:50] Let's get started here by creating a Files directory within our new generator, and let's create a new file. If we use two underscores, that denotes a variable name within the file name. Here, let's call this normalizedtitle.mdx, because we want to generate an MDX file.

[4:09] As the content here, let's copy in here some example. Obviously we want to have these placeholders replaced with whatever we pass in as a parameter. Nx generators use AJS as their templating language. It is a simple, yet very powerful language.

[4:25] In order to have placeholders, what we need here is to use the following syntax. We would have here a title, we would have here the excerpt, creation date, and finally, also the author. Below here, we can add some content. With that, we have our template which we want to generate. We need to go back into our generator and actually use that template.

[4:49] Most of the utilities come directly from that @nrwl/devkit package, which comes exported directly from Nrwl. Most of the time, when we compose our generators, we can just use functions from that @nrwl/devkit.

[5:01] For instance, when we are going to generate files, there is a function already handy in there, which is called generateFiles. That takes that tree object. These three object is a special object, which our generators have, which we can use to issue all of our read and write operations against.

[5:20] The reason is that the generators will only really write to the physical file system if we have a successful run. Moreover, when we pass the dry run flag to the generator, it will only simulate the run, which will just happen against this tree object.

[5:33] We give it the path of where the files are in our file system. We want to use the joinPathFragments, and use the current directory and the files folder, where we have based our template. Next, we want to give it a path where we want to have our files generated, which is the Articles folder within our workspace.

[5:54] Finally, we have the variables that we pass, that should be replaced in our template. Variables passed in here would be then, for instance, used to replace the name of our file's name here. Moreover, within a template, it will be used for the title, excerpt, creation date, and so on.

[6:09] The things we have to pass in here is, first of all, a title. We can get that as a parameter. Let's maybe also type our schema options here, which are being passed in here. Let's call these NewArticleSchemaOptions, which gets a title, it gets an author, it gets an excerpt. Excerpt is optional.

[6:28] The schema.title gets passed in here. Then we have the author, we have the excerpt, or just an empty string if that is not defined. Finally, also, we need to have a valid file name that will be replaced here with that normalized title. For that, we need to make sure that the passed-in title is a valid file name.

[6:46] Again, we can use the names function that comes from the @nrwl/devkit where we pass in the schema.title. That has a handy properties attached on it, which has also a file name among them, which you can use in this case. Then, we have the creation date where we can just define new dates. At the moment, we generate this and pass it in this way. With that, we generate our files.

[7:09] Finally, we will run the formatting that will make sure that all the files in our Nx workspace that have been touched are formatted properly. That we have set up everything, let's try and generate a new article. We can now run this by using, nx workspace-generator new-article. We give it a title, my-generated-article.

[7:28] Then, let's hit enter just to test what would happen. Here, you can see it already validates the fact that we forgot the author to pass in. This is based on a schema that we have seen earlier. We need to make sure we pass in the author here, which is Yuri. We can also use the dry run for the first run to see what would get generated.

[7:47] Here, in the dry run, we can see that we got an error in what we pass to our template. It expects an excerpt, but rather, here we specified expect. Let's try again. We can see it would create, inside that article, a new my-generated-article.

[8:02] We can remove the dry run and have this article generated. If you open it up, we can see that we have the title in there. We don't have an excerpt because we didn't pass any. We have a date, which we just generate on-the-fly while generating a new article here, and we have the author set properly.

https://app.egghead.io/api/v1/lessons/next-js-scaffold-a-new-blog-post-article-automatically-with-nx-workspace-generators/transcript

https://app.egghead.io/api/v1/lessons/next-js-run-an-nx-generator-with-the-nx-console-vscode-extension/subtitles

Instructor: [0:00] Workspace generators, such as our new article generator here, can be invoked by using the command line. The cool part is that we can also use Nx Console on Visual Studio Code to invoke them. Whenever such a workspace generator is available, if I click on Generate and write workspace, we can see that it picks up our new article generator.

[0:19] If we click on it, based on a schema that we define, it figures out that we need a title and an author, which is required, and an excerpt, which is optional. Here, we can write, yet-another-article, here is the author. You can see how it already starts generating it behind the scenes. If we run and go here to our Articles folder, we would see the yet-another-article being generated.

https://app.egghead.io/api/v1/lessons/next-js-run-an-nx-generator-with-the-nx-console-vscode-extension/transcript

https://app.egghead.io/api/v1/lessons/next-js-add-prompts-to-an-nx-workspace-generator/subtitles

Instructor: [0:00] Right now, if we invoke our custom workspace generator and we forget to provide some of the required information, for instance, let's say yet-another-article, but we don't provide the author, Nx correctly fails and provides information that the author is missing.

[0:17] Now, we can improve this whole developer experience by providing some prompts for all of these properties. We can go here and add the x-prompt property and add some question, which the user can answer to, "Title of your new article?" Similarly, we can add here, "What's the name of the author?"

[0:36] If we save this now and retry to execute the workspace generator -- we can even remove the title -- we will get a question, "What's the title of your article?" so, Hello Egghead. "What's the name of the author?" Yuri. We go ahead and create my new Hello Egghead article.

https://app.egghead.io/api/v1/lessons/next-js-add-prompts-to-an-nx-workspace-generator/transcript

https://app.egghead.io/api/v1/lessons/next-js-configure-storybook-for-your-react-based-nx-workspace-library/subtitles

Instructor: [0:00] On my current blog on yuri.dev, I have this Collections page. This is nothing else than a collection of all of my categories I've been writing about. You can see here Nx, Next.js, Angular, React, Node, and so on, and many other topics.

[0:13] Now, what I would want to have on my new blog is something similar. To get started, let's create the infrastructure for such a button, so we can use it on a new blog as well. The first step, again, would be to create a new library. I'm going to call it Shared-UI, which would contain all those shared UI components which I might use across my Nx workspace.

[0:36] Let's use, again, nx console, click Generate, and hit Library. I want to create a React library in this case. Let's call it ui. We use CSS. The directory is shared, because I want to place it under this shared directory which we already have for the MDX elements. We can leave all the other parts as they are right now. Let me hit Run and generate this library. We can see under that shared folder, we have our new UI library. It is set up already with Jest and Babel, and all the config which we need for our React library. It also created for me here, such an empty spec module CSS, and also an empty component.

[1:19] Let me create a new topic button in this new library. I'm using the Nx generator again. This time, I'm using the component generator. The name is topic-button. I'm using style.css. The project would be Shared-UI. Then, we can hit Enter.

[1:38] We also want to export the button, to be used outside. We have this new button inside, here inside a specific folder. Right now, it is empty. We can start implementing it here. Let's also clean up here, these React components which you might not need anymore. We also should make sure that we remove them here from the index.ts file.

[2:00] When we start developing our button, we definitely want to do this in an interactive fashion, where we want to see how the UI changes as we add new stuff to our button. One way to do that would be to directly embed it into one of the pages of our Next.js application right now, but we want to do it even in a more elegant fashion. We want to use Storybook for that purpose.

[2:21] Storybook allows you to develop these components independently, by launching it inside so-called Storybook, where we can see all the configuration options the component has, we can test them out interactively, directly while rendering the component, which leads to a very nice developer experience.

[2:37] Furthermore, you can also then use those stories as a documentation for other developers to understand and explore, what components are available within your workspace.

[2:46] Let's add some Storybook support to our library. Luckily, Nx already comes with a generator also for Storybook. We can go here to the Nx console again, invoke a generator now with the Storybook configuration. We give the project name, which is Shared-UI.

[3:04] Then, basically, it allows us to specify a couple of options here. We can give it a directory for our end-to-end tests. We can have here Storybook-e2e to group all the Storybook end-to-end tests in the sub-directory. We can also tell the generator to generate Cypress specs for us. We will do that, we will explore that in a later video.

[3:25] Also, to generate a Story, such that for our current topic Button, it would also generate out a Story. Let's hit Run here. Let's explore what we got from this generator. If we go back here to our explorer, we can see we got a new Storybook folder at the very top level of our workspace, which contains a main.js and a config.

[3:45] Now, this is the Storybook config that will apply to all the Stories that are, potentially, within our Nx workspace. This gives us the opportunity, for instance, to register common Storybook addons and presets, which we want to have at a global level.

[3:58] Furthermore, here in the Apps folder, we got that Storybook-e2e folder with our UI-e2e folder as well. This is a new Cypress project that has already been set up for our Storybook. As I mentioned, we will explore this in a bit.

[4:12] In our library, in our Shared-UI, we also got a Storybook setup with the project-specific Storybook configuration. You can see here, the Stories are being loaded in. There is also a preset register that comes from the @nrwl/react package. This will make sure that it works seamlessly with the Nx workspace. Furthermore, you can then add standard Storybook configurations in here.

[4:35] Another thing that happened, is also the generation of such a Story for us. Here, we can see that generator already created a simple scaffold of a story, which we then can use and expand furthermore, as we need it.

[4:47] Finally, in our workspace.json, which is at the very root of our Nx monorepo, we have a new Storybook target that has been added to our library. Our Shared-UI now has the ESLint and test, but it now also has a Storybook target, as well as this build-storybook target. These allow us, first of all, to add additional configuration, but also to launch our Storybook locally.

[5:11] Let's have a look at how that works. We can now invoke the target just as we would usually, by invoking nx storybook shared-ui. This now bootstraps Storybook for us. We can go to localhost:4400 and then see our Storybook in action. Here, you see now the topic Button which you created, which renders the button in the Storybook.

https://app.egghead.io/api/v1/lessons/next-js-configure-storybook-for-your-react-based-nx-workspace-library/transcript

https://app.egghead.io/api/v1/lessons/tailwind-configure-tailwind-for-your-storybook-setup-in-an-nx-workspace/subtitles

Instructor: [0:00] Now that we have our Storybook running, we want to make sure that it also works nicely with Tailwind, because that's what we ultimately use in our application. To configure Tailwind for our Storybook library, we need to simply go in here and set up Tailwind, just as we did for the application itself.

[0:17] Since this is in a subdirectory, we would CD into the libs/shared-ui folder, and then execute, npx tailwindcss init -p. Now this creates our PostCSS config and Tailwind config, just as we did previously in our application. We can actually go there and copy the configuration. For the PostCSS config, let me just copy this entirely, go to the PostCSS config of our library, and replace the content.

[0:47] Since we already used here the join and dirname, this will still work, because this now will pick up this directory name and find the Tailwind config. We can close the actual PostCSS config. Now, we also need to copy the Tailwind config. I'm going here, again, to my Next.js site project. Then, let's go to our library Tailwind config and also paste in the configuration.

[1:13] We definitely want to make a couple of adjustments here. This is definitely not called pages, but rather, we would just want to process here, the source directory. We can use source, and leave the remaining part the same. The createGlobPatterns would still work. It will now use this library, based on the current directory name, and make sure to purge all the dependencies of this library.

[1:36] We can leave the rest as is. The only thing we also need to adjust here is the path to our main Tailwind workspace preset. Here, one level up, is missing. We don't need to do any further configuration. Also, our main.js can remain as is.

[1:50] We don't need to pull in any specific Storybook, Tailwind, or PostCSS add-on, because most of the stuff is already handled by this preset, which has been configured when we set up Storybook for this library. This will make sure that the PostCSS config is being detected properly and resolved, just as for our application.

[2:09] What we need to do, however, is to load in the basic Tailwind imports. As we have seen here in our application on the main style sheet, we import here the Tailwind base components and utilities. There's some slight duplication here, in that we also want to report that down here.

[2:26] Since these might be more global imports, we could also have a more global-level CSS, which we import both into our application, as well as here in our Storybook. For now, we can just create here Tailwind imports.css, based in here to imports, and then we can go to our preview in CSS and import this new style sheet. This will make sure that once we bootstrapped Storybook, it will pick up the CSS and properly load in all the main basic Tailwind utilities.

[2:56] Now, that we have configured our library, let's launched Storybook again and see whether we got Tailwind set up properly. If we now go over to 4400, you can already see that this font slightly changed. This means Tailwind has been loaded in.

[3:14] Let's maybe go to the actual Story here and modify it slightly by applying a couple of Tailwind classes. Instead of directly returning here to component and return here a div, which wraps our component.

[3:27] On that div, let's add a couple of Tailwind classes to add some background gray. If you go back to our story here and refresh, we should see all the changes being applied properly.

[3:37] Now, one thing to pay attention to is that if you're in your conflict of Tailwind of the Storybook setup, you use the jet mode, make sure to run the stories and watch mode as well.

[3:48] Basically, we should prefix our command with a Tailwind mode=watch and then invoke an X Storybook shared-ui, to make sure that all the Tailwind changes that you make are reflected automatically.

[4:01] Now, note that as of the time of the recording, the jet mode is still an experimental feature, but it might be the the default one in any upcoming Tailwind release.

[4:09] Now, if you refresh, you will see the Tailwind changes are being applied, but also, if we go into our story and say your background equals=300, it rebuilds. If we go here, we see the live changes are being applied.

https://app.egghead.io/api/v1/lessons/tailwind-configure-tailwind-for-your-storybook-setup-in-an-nx-workspace/transcript

https://app.egghead.io/api/v1/lessons/react-develop-react-components-in-isolation-with-storybook-and-nx/subtitles

Instructor: [0:00] Now that we have Storybook as well as Tailwind configured, let's start and implement such a Topic button as we have discussed before.

[0:09] Let's adjust the interface of our React component here. What we want definitely to have here is a topic name, which we can pass in as a string, which then in turn, we can go down here and replace the current default text with a props.topicname rendering. Once we save this, we should see this reflected on our Storybook.

[0:30] Now, right now in the Storybook, it is empty. We can go here, and for the arguments of our component, we can go and specify the topic name, and also give it a default, so let's say Next.js. Once it refreshes, you can see here, we get the value displayed. Also, now the add-ons reflect the changes in our component here.

[0:52] We can also directly manipulate this string and say, ReactJS or egghead, and visualize that dynamically. This is the power of Storybook, such that we can see the changes live, based on what we manipulate down here.

[1:05] We can also go ahead and change this a bit, and add some Tailwind classes to make it look much more like a button. Let's go ahead and add here a couple of classes. You don't have to know the details of all those classes, you can explore this on your own. What we want to achieve here is to have more of such a button look.

[1:25] Let's add here also some of the paddings, and also make it a bit more bold. You can see how slowly this becomes an actual button, just as on my current block. One thing that is missing is, still, an image. Let me paste in here two SVGs, which I'm just placing directly into this Topic Button folder, so one for Next.js and one for React.

[1:46] Obviously, we might want to have multiple of these and, potentially, stored not inside this library, but from some external asset resource. Again, let me paste in here some code that allows us to dynamically load this icon in. Finally, also, to import the icon directly in here in our component.

[2:06] As you can see, what happened here now, based on the topic name, we are going to search for an icon, which in this case is Next.js. We do some cleanup on the actual name to exclude all the dots and stuff. This, here, now nicely visualized the icon, based on our file system SVG icon.

[2:22] Finally, what we also might definitely want to have is some possibility of capturing click events. Let's add some OnClick event directly to our typing. Let's also go down here and paste in some code for that click handler, which we then invoke directly on our div.

[2:39] To test this out in our Storybook, we would add such an argument which we can directly do up here, just below the title. This allows us to add some arg types, and here we add OnClick. With that, Storybook now knows that there is also an action defined on the button. We can refresh here. Let's add here Next.js, to get also some logo visualized.

[3:04] Then, if we click on this button here, you can see here in the actions, you would get here, "OnClick action executed -- Next.js," which is the current value. We might even want to have in our story, a bit more visual way of showing the click event has been clicked, by directly showing a message, for instance, just below the Topic button. We have all the freedom to add some code in here.

[3:25] What I do here is, for instance, I just use the onState hook to store some value, whether something has been clicked or not. Then, inside of our button here, let's add the click handler and implement it.

[3:38] What we do is, we grab here the topic name, we set it onto that state hook. Then, we have the clicked topic here, which allows us then, just below here, to add something like, if the clicked topic is visualized, then let's render out some text that allows us to see what has been clicked.

[3:57] Let's save this again. Let me refresh here the Story. If we click on top of here, you can see the text gets printed out below. If you now go and change, for instance, and say, "This is React," you will see the logo gets reflected, with the new logo of React. When I click, it would say, "Button has been clicked with React."

[4:15] You can now see how we can nicely, in an interactive fashion, develop our component here, and make it ready for then later being embedded into our application.

https://app.egghead.io/api/v1/lessons/react-develop-react-components-in-isolation-with-storybook-and-nx/transcript

https://app.egghead.io/api/v1/lessons/react-share-react-components-in-next-js-applications-with-nx-workspace-libraries/subtitles

Instructor: [0:00] With Storybook set up on our shared-ui library, we can develop all of our components independently and in isolation. Which gives us a very nice developer experience, in the sense that we can here go and change the properties of our component, and explore different variations of it as we develop, but also as a documentation afterwards.

[0:20] Ultimately, what we want to do is embed these components in our various applications. Right now, we only have our Site application, which is the Next.js base application up here. We can go ahead and create a new page here and actually use the component.

[0:34] Let me use an Nx generator from the Next package. Let me call a new page component, with the name, Topics. The project here where I want to add it, is our site project, which is the one here. We want to use CSS for that component. We get a new page here, which now we should be able to serve. Let's serve our Next.js application. We, again, want to use the TAILWIND_MODE=watch, to make sure that JIT mode works properly. By going to localhost:4200/topics, we should see our new Topics page.

[1:11] Let's import our new shared component there. First of all, at the very top, we can import the component from that new yuri/dev, which is the main npm scope of our Nx workspace here. We have the shared-ui, and that should expose now such a Topic button, which I can now just include. Let's give it a topic-name = nextjs. Let's also add some class dup here to make it look a bit nicer.

[1:40] If you then go to our application, we see that Topic button nicely renders. The image, for some reason, doesn't display. If we look here, it looks like there is an error loading some resource. The main reason for that is that in the Next.js config here, in Nx, the SVGR support is disabled by default. Let's enable this here. There's some more details here if you want to look that up.

[2:07] Once we save this and set this to true, let's restart our application, and now if you go to application, we see the Topic button nicely visualized, also with according logo. You can see how easy it was to actually first develop the component independently, and then import it into our Topics page, by directly using this npm scope here and pulling in the button.

[2:31] Just as easy, we could use the same button in a different application that might live in the future, here in our apps folders, say, a React application, where we also want to use that Topic button.

https://app.egghead.io/api/v1/lessons/react-share-react-components-in-next-js-applications-with-nx-workspace-libraries/transcript

https://app.egghead.io/api/v1/lessons/cypress-write-e2e-tests-for-our-next-js-application-with-nx-and-cypress/subtitles

Instructor: [0:00] Clearly, Nx is very helpful if we have a large monorepo scenario. Even if we don't, for instance, by setting up my blog here with Nx, I get already a lot of value out of it, for instance, by having a pre-configured setup for Jest, which you can see here in our project. We have a Jest config for the project as well as the libraries, but also end-to-end tests with Cypress.

[0:23] As you might have noticed, this site-e2e test had got generated at the very beginning when we created our workspace and our Next.js application.

[0:32] Let's explore a bit more, what this has set up for us. We can see here, there's the Cypress config already set up to work properly. We have already an integration test here created, which does nothing else than basically visit the root of the application and check for some predefined values there.

[0:52] These are just example setups of a potential spec file, which obviously don't work anymore, because we have changed our application, meanwhile.

[1:00] Similarly, how we are able to serve the site project, our Next.js app, or Storybook in our library folder, also for Cypress here, we got such a target setup. There's this site-e2e project generated, which is exactly the application which we see up here. That has an end-to-end target that we can invoke.

[1:21] If we go and execute, yarn nx e2e site-e2e, it will launch Cypress for us on top of our application. What happens here, is that Nx understands that it needs to bootstrap, first, the application itself, which is our Next.js-based site project, then launch Cypress and connect it to the actual application.

[1:44] Here, we will run it in headless mode and verify whether everything works. I expect a failure, because as mentioned, we changed the application. You can see here now the output, and as expected, one of our spec fails. Let's go and implement a passing test.

[1:59] What we want to do is launch this in watch mode, such that we can interactively see how the Cypress test passes after some time, and based on our modifications. By using the watch mode, behind the scenes, the Cypress test runner got instantiated. We can click that directly and see how the test runs in a much more visual way, and understand better, what failed.

[2:19] Let's go back and implement our app spec now. What we want to do, is to go to our articles dynamic routing article. We would visit articles/routing, and then we would want to verify whether that renders the title of the article. We could change this one here to, "Should Render the Title." In here, we would simply do a ci.get of the H1 title. Let's see what the title of our article is. As you clean exactly this title at the very top.

[2:51] Let's save this. We can clean up here the imports, which you don't need at the moment. Now, if we go over again, you can now see that Cypress's test run already refreshed the page. It basically opens up our article, it verifies the H1 expects our expectation here, such that it has dynamic routing and static site generation. Therefore, the test passes.

[3:14] Similarly, we could add another one to verify that our YouTube component renders. That would verify that our MDX embedded component worked properly. Here we can, again, use the Cypress get(iframe), which should be rendered by our YouTube component, and that should be visible. Again, let's jump over here. You can now see the second test also got probably recognize and executed, and it passed.

[3:38] This is a very easy way of testing our personal portfolio site. Given, that Nx already converted the whole Cypress setup and made sure that I can code here in TypeScript, and it also instantiates behind the scenes, the application for me, this is really easy. While otherwise, I wouldn't probably set up a testing environment for my own portfolio site.

https://app.egghead.io/api/v1/lessons/cypress-write-e2e-tests-for-our-next-js-application-with-nx-and-cypress/transcript

https://app.egghead.io/api/v1/lessons/cypress-write-cypress-tests-for-our-react-storybook-components-with-nx/subtitles

Instructor: [0:00] When we used Nx to generate the Storybook setup for our UI Library here, we also got some end-to-end tests, based on Cypress, generated for that Storybook.

[0:11] If we go and look into that integration test which also got generated, what you can see here is that the test basically launches behind the scenes, Storybook. Then, it directly accesses our page that Storybook exposes, which is this iframe HTML, which is directly the visualization of the Story itself. Based on the page, it then renders tests against it.

[0:35] To launch these Storybook tests, in our workspace.json file, we should have a project called ui-e2e. That should have an actual end-to-end target that allows us to execute end-to-end tests for the specific application.

[0:53] If we run nx e2e storybook-e2e ui-e2e, so this is basically the project name, which is based here, of that workspace.json configuration. Let's also run this immediately into watch mode. This will now launch Storybook behind the scenes, as you can see here, and then it will run Cypress and point to the Storybook port.

[1:16] Once Storybook and Cypress has been started, we can see the Cypress test runner. If you click here on that spec file, we see the test runner opens up that iframe page, which just visualizes the story itself, without the sidebar and anything that usually you have when you run Storybook, and then it executes test against it.

[1:36] This still fails because we need to implement the test based on the changes to our TopicButton component. Let's do that. If you go to our TopicButton spec, what we will want to test is, if we pass in a TopicButton topic name to this button here, it should visualize that name properly.

[1:57] Storybook allows to provide the inputs to a button with the so-called args property. Here in the URL, we can directly specify, args = topic-name, which is the input property of our button, :enter value, let's say, React. Once this renders, let's rename here this test that it should render the topic name. We can go ahead and verify whether the name matches our expectation.

[2:24] As a best practice, we should have a hook point in our HTML of the component. Let's open up the topicbutton.tsx file here. What we want to have here is, for the specific rendering of our button, we would want to have a hook point. That is usually done via data test ID property. Let's call this topic-name. This would allow us to use this property in our tests to identify the specific H2 tag here.

[2:52] In our tests we can then go and say, ci.get. We would now try to reference that test ID property that should contain topic-name. That specific element should then contain React, if that's what we specified.

[3:06] Let's now go to the Cypress runner. Let's refresh. We can see here, it opens up the button, it passes in the actual argument correctly, as we expected, so this is React. Then, it verifies whether this specific element contains React, what we passed in as an argument.

[3:23] The next thing that we want to verify, is that whenever we click on the button, that then gets fired properly, and it passes out the name of the topic that previously has been given to the actual component. We can just add another test down here. We would want to identify the button first. We can, again, use a test ID, which we need to specify afterwards.

[3:46] Let's say here, we have here the Topic button itself. If we click that, then we would want to have another such a hook point, such a test ID property, which has the name click-result. That should then, in turn, contain React, because that's what we passed in.

[4:05] We need to define these hook points. The first one is test ID Topic button. We would want to have that directly here on the main button, so this is the Topic button. Click-result is not in here, but it's, rather, in our Story rendering. On this div in our Story rendering, we would want to have the test ID, click-result.

[4:27] Let's go back again to our rendering. Let's refresh. You can see that it passes properly. It first visits, again, that endpoint, it grabs the actual button, it clicks on top of that button, grabs that element, and verifies it against what we have specified in our expectation.

[4:46] Again, this is a very powerful way, because now we can use Storybook, not only to develop our components in isolation, have them documented, but also to run Cypress tests against them, and therefore, test all of our Storybook components in our shared-UI library, in a very visual way, with Cypress.

https://app.egghead.io/api/v1/lessons/cypress-write-cypress-tests-for-our-react-storybook-components-with-nx/transcript

https://app.egghead.io/api/v1/lessons/next-js-export-a-next-js-application-with-nx/subtitles

Instructor: [0:00] Once you're done developing all of the functionality of our blog or portfolio site, we definitely want to go and deploy it somewhere.

[0:08] In Next.js, we have the so-called export functionality. If I go into the workspace.json and I go to the actual site project, which is the one we're currently developing on, you can see that, in fact, further down here, apart from the serving which we have used during development, we have the so-called Export Target.

[0:26] Now, exporting here uses the build target site, build production. Basically, it executes first the so-called build, which uses this target with the production configuration, and then we are ready to actually export it.

[0:40] To invoke this target, we can simply run Nx export as usually, and then giving it the name of the application we want to export, which is Site, in this case. You could also just click here if you have Nx console installed. Now, whenever you run export, it will undergo a much more stricter control, also in terms of type checking. What you can see here is, it reveals a couple of typing issues which we haven't seen before when in development mode.

[1:05] Let's go to the Slug page, which is exactly where this typing issue happens. We can see that Visual Studio Code also underlines the error for us. The problem here is that we expect a return type of ArticleProps from this getStaticProps function, while now we return a front matter and HTML.

[1:23] What we can do is we can get rid of this entirely, have the type inferred. We could even go up here and use here as the typing, the so-called InferGetStaticPropsType, type of getStaticProps. By using this InferGetStaticPropsType, we automatically infer whatever getStaticProps returns, and therefore, have a nice and type-safe environment here.

[1:48] Once we have solved this TypeScript issue, we can go and re-export our Site project. This now creates a new folder here in dist/app/Site with the exported content. We can cd into dist/app/Site project and into the exported folder, and we could just launch a static HTTP server in that directory.

[2:12] Once that is launching, we can open up localhost:8080 and see our exported site. We can also, obviously, navigate to the article's dynamic routing. This would open up the article which we wrote. The reason is, basically, to export just individual HTML files for all of the various sites which we have created within our Next.js application.

[2:32] Obviously, this is fully static. You can just copy and paste this folder to any static hosting provider.

https://app.egghead.io/api/v1/lessons/next-js-export-a-next-js-application-with-nx/transcript

https://app.egghead.io/api/v1/lessons/next-js-setup-vercel-to-deploy-an-nx-based-next-js-application/subtitles

Instructor: [0:00] To deploy our portfolio site, we have two options. We can either use the export command, which is already baked into this target here of our generated Next.js application. It's especially useful if you want to generate a set of static files to host on any provider.

[0:16] If you want to host it on Vercel, for instance, then you might just use the build target. We can just use Nx build site. We might want to pass the production flag, which you can do by either passing the --prod, or --configuration=production. What this would do is use the configuration production here, which would, internally, also set a couple of Node flags in a different way.

[0:39] Obviously, right now, here this production configuration is empty. You could open this up and configure different options in here.

[0:48] Running a production build, again, produces on the output path, which is in this case, is this app site, our production bundle to be deployed to Vercel. If we go up here in the disc folder, you can see here the public, you can see that .next file, which contains useful information for Vercel to host our website, as well as the next.config and package.json. There is no exported folder, as we have seen with the export command, because that one is only useful for statically hosting it.

[1:15] To deploy to Vercel, let's go over to vercel.com dashboard. Then, you create a new project there. We can import a project from git. In my case, I'll use the blog series repository which I have created. If we hit that Import, it will open up the configuration page.

[1:33] You can optionally create a team, especially if you plan to work in a bigger team within a corporate environment. Otherwise, you can continue and skip that step, and configure the project straight away.

[1:43] In our case the project name is blog-series-nextjs-nx. We can leave it as is. The thing we want to customize is, here, the build output settings. We want to override the command here to use the actual nx command, which will be, npx nx build site, which is the name of our application, in configuration mode, production.

[2:02] We also want to override the actual output directory, which as we have seen, would be dist/app/site, and then the .next directory. We can specify the very same here. With that, we are ready to go, so you can hit the Deploy button.

[2:17] Once the build succeeds, you will get redirected to the main Vercel page of your dashboard. If we click here, we see the current production deployment. Hitting this URL here opens up the deployed block. By default, Vercel creates deployments from your main branch, which is either main or master, depending on how you configured it.

[2:49] However, if you go to Deployments, it will also show up so-called preview deployments, which means, whenever you create a PR on your connected GitHub repository, it will run a so-called pre-deployment for what it would look like to deploy these changes into your main production line.

[3:05] This is a really useful feature. Let's have a look. If we go to our own repository and create a new branch, test-vercel-deployment, and let's go into our article and actually create here some new text, "Hello, egghead folks." Let's add this to our comments.

[3:27] Now, let's create a new PR to our GitHub repository. This will open up our GitHub repository. Let's create a new pull request. Once that launches, you already see that Vercel bot kicking in here, which should soon, here, post a new comment on that pull request. This comment now shows us that there is a deployment in progress.

[3:55] In fact, if we go over to the blog series Vercel deployments page, we can see there, a new deployment is currently running. Once the deployment is successful, we can see here the Visit button. We can either just use this temporary URL, or you can see it has such a unique identifier of the build.

[4:12] Also, if we go back to our actual pull request, we see now the Preview button here, or the Preview line, does no more show, "Build in progress," but rather, it shows us the URL. We can just hit that one and it will open up, again, our temporary preview deployment, which obviously also has, for instance, our article's dynamic routing.

https://app.egghead.io/api/v1/lessons/next-js-setup-vercel-to-deploy-an-nx-based-next-js-application/transcript

https://app.egghead.io/api/v1/lessons/nx-only-build-what-changed-with-nx-affected-commands/subtitles

Instructor: [0:00] Once our Nx workspace grows with, potentially, multiple applications in here, as well as hundreds of libraries, we definitely want to make sure to not waste any computation power, and also optimize for speed. Behind the scenes, Nx has the so-called dep graph, which you can invoke by nx dep-graph. That, basically, has a visualization of everything that is inside our workspace.

[0:23] For instance, Nx knows about the end-to-end projects that have been generated for our libraries and applications. It knows about our site project, it knows about the shared-ui, as well as the libraries here, shared-mdx-elements and Markdown.

[0:36] Based on this dependency graph, Nx makes decisions behind the scenes on what to execute via the so-called Effect commands. Let's explore this by, first of all, creating a new React application. I'm creating here a new React application with the generator again. Now we have such a React application. Again, if we execute the dependency graph, we can now see that Nx is also aware about that React application, which it hasn't connected yet to any library.

[1:07] Let's see what happens if React app also imports shared-ui. Let's go into our App.tsx component, and just for the sake of this example, import from yuri/dev/shared-ui, and let me import here the Topic button, for instance. Let's include the Topic button somewhere here, and then let's again show the dependency graph.

[1:33] If we now have a look, it clearly understands that the React application has such a shared-ui dependency, as well as our site. Shared-ui becomes a shared dependency between both of these applications. Let's assume this is the current state. Let's comment this, and then let's create a new branch, My Feature.

[1:54] Assuming this feature branch, we are actually just going to make a change in our Markdown library. Let me open up that Markdown file, and let's do nothing else than adding here a console.log. Let me add this change. Let's, again, use the dependency graph, but this time, let's use the so-called Affected command for it. We use, affected dep-graph, and as the base, we give it the previous branch.

[2:21] The previous branch, in our case, is not the master or main one, which would be a normal development scenario. Since we are developing this course repository, the previous branch is 25-export-nextjs-site.

[2:34] Let me just link that as the previous branch, and now hit Enter. This will give us now the visualization of what nodes have been affected by the changes in this branch, compared to its base.

[2:46] Now, since the base is basically our 25-export-nextjs-site, in the meantime, the only thing we changed was that console.log in a Markdown library.

[2:56] As a matter of the results, since Nx has the complete vision of the entire dependency graph in our workspace, it is able to figure out that the only things that are affected by this change is the Site project, which is our Next.js application, as well as its end-to-end tests.

[3:11] In fact, if we Select All, we can see that this path here is colored in a different way than all the other applications and libraries in our repository. As such, what we can do, is we can not only visualize this as a dependency graph, but we can execute the targets against these affected commands. We can use, for instance, the Build command, and only build what has been affected.

[3:35] Nx correctly figures out that the only build targets within our workspace is the React application, as well as the Site Next.js application, and so it only builds those two. In this case, the React application has not been affected by the change, and so only Site would be rebuilt.

[3:51] This can dramatically speed up, obviously, the build times or test execution times you might have within a monorepo, because we only build or test or lint, a subset of the changes that would otherwise be necessary.

https://app.egghead.io/api/v1/lessons/nx-only-build-what-changed-with-nx-affected-commands/transcript

https://app.egghead.io/api/v1/lessons/mdx-register-our-markdown-articles-with-the-nx-dependency-graph/subtitles

Juri Strumpflohner: [0:00] Right now in our current setup of our portfolio page, we just have one application. If we run, nx dep-graph, we can see there is just this site app and its various libraries which we have so far.

[0:14] In our real scenario, we definitely would want to make use of the nx affected:build command, such that we can only build, and then consecutively deploy, our site application, whenever something relevant changes to it. Right now, we always would want to have that. Once we have more application, we want to only deploy site whenever it's some relevant changes.

[0:35] One of the main changes we want to hit is our article changes. Whenever we change some MDX content in here, we want our site to be redeployed, because we need to generate the static output for our Next.js application.

[0:49] The problem right now is that the dependency graph doesn't track the _articles folder at all. The reason is, this _articles folder here is really just a folder, and is not a project registered within the Nx workspace.

[1:02] For triggering changes to the dependency graph, we have various possibilities. First of all, we can go to the nx.json. At the very top, there is some "implicitDependencies" configuration object. What this allows us is it allows us to specify entries such as like this one here which translates to whenever there is a change to the ESLintrc.json, build everything.

[1:24] Everything would be affected by that. The reason is simply because if this is a global configuration files on which all of our libs and apps will depend on. This is quite different from our changes in the _articles folder where we would really only want to build our site application instead of invalidating everything.

[1:43] The best approach to do that is by simply registering this as a project. Projects are registered in that workspace.json at the very root of our app. If we close here all project that are already in here, we can just create a new one, which is an empty one mostly.

[2:01] We can create a new one. Let's call it "site-articles". We only need a couple of nodes here. First of all, we need the "root" which would be "_articles". We need the "sourceRoute" which is, in this case, "_articles" as well because it's just really a flat directory.

[2:16] We need a "projectType". This can be either application or library. It doesn't really matter in this case. Let's just use "application". Finally, we have "targets", those are usually the build targets Nx is able to execute. Since this is really just a collection of markdown files, there is not really a target we want to run against this.

[2:33] However, if you might have any future some cleanup tasks or things to do, we could definitely register targets in here and run them against our _articles folder. Now that we have registered the site-articles in here, we also need to make sure to register it in the nx.json. In here, we just add another entry, "site-articles". If we launched nx dep-graph, we can see that our site-articles appears on the dependency graph. It's now actively being tracked by Nx.

[3:04] It is square because we specified the projectType of type application. If we specify this as library, it would be a rounded node in this dependency graph. There's one issue though. Since we're not importing anything from this graph or reading it via its string path, there's no connection between the site and the site-articles in this case.

[3:25] Nx is unable to figure that out automatically. We need to help it a little bit by specifying it in implicitDependencies. What we can do is go to our site and add such an "implicitDependencies" entry and say that site implicitly depends on the "site-articles".

[3:45] If we now again start our dependency graph, we can now see that site has an implicit dependency on this site-articles down here. As a result, whenever we invoke things such as an affected build, site would be affected based on just changes within our site-articles.

[4:04] Meaning, whenever we go inside our _articles folder, create a new entry, or modify an existing one, this would trigger a build of our Next.js application, which is definitely what we want.

https://app.egghead.io/api/v1/lessons/mdx-register-our-markdown-articles-with-the-nx-dependency-graph/transcript

https://app.egghead.io/api/v1/lessons/nx-only-deploy-to-vercel-what-has-been-affected-using-nx/transcript

https://app.egghead.io/api/v1/lessons/egghead-course-outro-where-to-go-from-here/subtitles

Juri Strumpflohner: [0:00] Cool, you made it. Congrats

[0:03] I'm fully aware this was a lot of stuff. Full two hours of tooling setup, frameworks which you might not have been aware of, such as Next.js. Then also, Tailwind, Storybook cybers. There has been a lot of things here.

[0:17] When I create these courses, my main objective is to give you something transferable. So, while we built that digital garden, you might continue in that part and extend it. We really just scratched the surface, right?

[0:29] There are pieces that are missing, such as a list page that lists all your articles, and things like that, adding more icons. I think that you have now the technical foundation to continue working on that.

[0:39] Then there's obviously the Next.js part. There's a lot more stuff to explore on that side. If you want to add authentication to your site, if you want to have more interactive content, but even then, you can go and easily explore that.

[0:54] Finally there's an Nx. I think Nx is really a powerful technology, in this case, and probably the most...

[0:59] Then, finally, there's Nx. I think that Nx is really a powerful technology in this case and probably the most transferable one, as you can retake it from your Next.js project to your next React project. If you happen to do Angular, you can even put it onto an Angular project or Node.js. There's a lot of things to explore there.

[1:13] I would highly encourage you to continue taking a look at that and go to the Nrwl YouTube channel, to the developer docs, which has more and more content on these things. Nx is designed to scale, as you might actually use it on your next large-scale Enterprise project, which is exactly what it has been made for.

[1:32] I really hope this course was helpful. Feel free to leave a comment or ping me on Twitter @juristr or juri.dev on my personal portfolio site. Thanks for watching.

https://app.egghead.io/api/v1/lessons/egghead-course-outro-where-to-go-from-here/transcript

Architect an Extensible Digital Garden with Next.js, Tailwind, and Nx

Juri Strumpflohner

Free Community Resource

Free Community Resource

Course Content