miel.truyen/nx
1
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity

docs(angular): add video-links to angular tutorial

Browse Source
This commit is contained in:
Juri 2023-07-28 15:35:18 +02:00 committed by Juri Strumpflohner
parent bd71ce35a4
commit 90574e5a21
1 changed files with 24 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
docs/shared/angular-standalone-tutorial/angular-standalone.md
View File

@ -31,6 +31,8 @@ width="100%" /%}
## Creating a new Angular App ## Creating a new Angular App
{% video-link link="https://youtu.be/ZAO0yXupIIE?t=49" /%}
Create a new Angular application with the following command: Create a new Angular application with the following command:
```shell {% command="npx create-nx-workspace@latest myngapp --preset=angular-standalone" path="~" %} ```shell {% command="npx create-nx-workspace@latest myngapp --preset=angular-standalone" path="~" %}
@ -107,6 +109,8 @@ Compared to the Angular CLI, you might notice the addition of an `nx.json` file
## Serving the App ## Serving the App
{% video-link link="https://youtu.be/ZAO0yXupIIE?t=296" /%}
The most common tasks are already defined in the `package.json` file: The most common tasks are already defined in the `package.json` file:
```json {% fileName="package.json" %} ```json {% fileName="package.json" %}
@ -183,6 +187,8 @@ Learn more about how to [run tasks with Nx](/core-features/run-tasks).
## Testing and Linting - Running Multiple Tasks ## Testing and Linting - Running Multiple Tasks
{% video-link link="https://youtu.be/ZAO0yXupIIE?t=369" /%}
Our current setup not only has targets for serving and building the Angular application, but also has targets for unit testing, e2e testing and linting. Again, these are defined in the `project.json` file. We can use the same syntax as before to run these tasks: Our current setup not only has targets for serving and building the Angular application, but also has targets for unit testing, e2e testing and linting. Again, these are defined in the `project.json` file. We can use the same syntax as before to run these tasks:
```bash ```bash
@ -207,6 +213,8 @@ More conveniently, we can also run them in parallel using the following syntax:
### Caching ### Caching
{% video-link link="https://youtu.be/ZAO0yXupIIE?t=443" /%}
One thing to highlight is that Nx is able to [cache the tasks you run](/core-features/cache-task-results). One thing to highlight is that Nx is able to [cache the tasks you run](/core-features/cache-task-results).
Note that all of these targets are automatically cached by Nx. If you re-run a single one or all of them again, you'll see that the task completes immediately. In addition, (as can be seen in the output example below) there will be a note that a matching cache result was found and therefore the task was not run again. Note that all of these targets are automatically cached by Nx. If you re-run a single one or all of them again, you'll see that the task completes immediately. In addition, (as can be seen in the output example below) there will be a note that a matching cache result was found and therefore the task was not run again.
@ -229,6 +237,8 @@ Not all tasks might be cacheable though. You can configure `cacheableOperations`
## Creating New Components ## Creating New Components
{% video-link link="https://youtu.be/ZAO0yXupIIE?t=500" /%}
Similar to the Angular CLI, Nx comes with code generation abilities. What the Angular CLI calls "Schematics", Nx calls "Generators". Similar to the Angular CLI, Nx comes with code generation abilities. What the Angular CLI calls "Schematics", Nx calls "Generators".
Generators allow you to easily scaffold code, configuration or entire projects. To see what capabilities the `@nx/angular` plugin ships with, run the following command and inspect the output: Generators allow you to easily scaffold code, configuration or entire projects. To see what capabilities the `@nx/angular` plugin ships with, run the following command and inspect the output:
@ -314,6 +324,8 @@ export class HelloWorldComponent {}
## Building the App for Deployment ## Building the App for Deployment
{% video-link link="https://youtu.be/ZAO0yXupIIE?t=680" /%}
If you're ready and want to ship your application, you can build it using If you're ready and want to ship your application, you can build it using
```shell {% command="npx nx build" path="myngapp" %} ```shell {% command="npx nx build" path="myngapp" %}
@ -342,6 +354,8 @@ All the required files will be placed in the `dist/myngapp` folder and can be de
## You're ready to go! ## You're ready to go!
{% video-link link="https://youtu.be/ZAO0yXupIIE?t=723" /%}
In the previous sections you learned about the basics of using Nx, running tasks and navigating an Nx workspace. You're ready to ship features now! In the previous sections you learned about the basics of using Nx, running tasks and navigating an Nx workspace. You're ready to ship features now!
But there's more to learn. You have two possibilities here: But there's more to learn. You have two possibilities here:
@ -351,6 +365,8 @@ But there's more to learn. You have two possibilities here:
## Modularizing your Angular App with Local Libraries ## Modularizing your Angular App with Local Libraries
{% video-link link="https://youtu.be/ZAO0yXupIIE?t=750" /%}
When you develop your Angular application, usually all your logic sits in the `app` folder. Ideally separated by various folder names which represent your "domains". As your app grows, this becomes more and more monolithic though. When you develop your Angular application, usually all your logic sits in the `app` folder. Ideally separated by various folder names which represent your "domains". As your app grows, this becomes more and more monolithic though.
The following structure is a common example of this kind of monolithic code organization: The following structure is a common example of this kind of monolithic code organization:
@ -382,6 +398,8 @@ Nx allows you to separate this logic into "local libraries". The main benefits i
### Creating Local Libraries ### Creating Local Libraries
{% video-link link="https://youtu.be/ZAO0yXupIIE?t=818" /%}
Let's assume our domain areas include `products`, `orders` and some more generic design system components, called `ui`. We can generate a new library for each of these areas using the Angular library generator: Let's assume our domain areas include `products`, `orders` and some more generic design system components, called `ui`. We can generate a new library for each of these areas using the Angular library generator:
``` ```
@ -453,6 +471,8 @@ Each of these libraries
### Importing Libraries into the Angular Application ### Importing Libraries into the Angular Application
{% video-link link="https://youtu.be/ZAO0yXupIIE?t=976" /%}
All libraries that we generate automatically have aliases created in the root-level `tsconfig.base.json`. All libraries that we generate automatically have aliases created in the root-level `tsconfig.base.json`.
```json {% fileName="tsconfig.base.json" %} ```json {% fileName="tsconfig.base.json" %}
@ -557,6 +577,8 @@ A couple of notes:
## Visualizing your Project Structure ## Visualizing your Project Structure
{% video-link link="https://youtu.be/ZAO0yXupIIE?t=958" /%}
Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/core-features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `nx build`, identifying [affected projects](/core-features/run-tasks#run-tasks-affected-by-a-pr) and more. Interestingly you can also visualize it. Nx automatically detects the dependencies between the various parts of your workspace and builds a [project graph](/core-features/explore-graph). This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like `nx build`, identifying [affected projects](/core-features/run-tasks#run-tasks-affected-by-a-pr) and more. Interestingly you can also visualize it.
Just run: Just run:
@ -634,6 +656,8 @@ Exercise for you: change the codebase so that `modules-shared-ui` is used by `mo
## Imposing Constraints with Module Boundary Rules ## Imposing Constraints with Module Boundary Rules
{% video-link link="https://youtu.be/ZAO0yXupIIE?t=1147" /%}
Once you modularize your codebase you want to make sure that the modules are not coupled to each other in an uncontrolled way. Here are some examples of how we might want to guard our small demo workspace: Once you modularize your codebase you want to make sure that the modules are not coupled to each other in an uncontrolled way. Here are some examples of how we might want to guard our small demo workspace:
- we might want to allow `modules-orders` to import from `modules-shared-ui` but not the other way around - we might want to allow `modules-orders` to import from `modules-shared-ui` but not the other way around