docs(react): add video-link sections for the React standalone docs

docs/shared/react-standalone-tutorial/react-standalone.md

@@ -36,6 +36,8 @@ width="100%" /%}
 
 ## Creating a new React App
 
+{% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=64" /%}
+
 Create a new standalone React application with the following command:
 
 ```shell {% command="npx create-nx-workspace@latest myreactapp --preset=react-standalone" path="~" %}
@@ -90,6 +92,8 @@ Let me explain a couple of things that might be new to you.
 
 ## Serving the App
 
+{% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=207" /%}
+
 The most common tasks are already mapped in the `package.json` file:
 
 ```json {% fileName="package.json" %}
@@ -177,6 +181,8 @@ Learn more about how to [run tasks with Nx](/core-features/run-tasks).
 
 ## Testing and Linting - Running Multiple Tasks
 
+{% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=410" /%}
+
 Our current setup doesn't just come with targets for serving and building the React 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
@@ -223,6 +229,8 @@ Not all tasks might be cacheable though. You can configure `cacheableOperations`
 
 ## Nx Plugins? Why?
 
+{% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=598" /%}
+
 One thing you might be curious about is the project.json. You may wonder why we define tasks inside the `project.json` file instead of using the `package.json` file with scripts that directly launch Vite.
 
 Nx understands and supports both approaches, allowing you to define targets either in your `package.json` or `project.json` files. While both serve a similar purpose, the `project.json` file can be seen as an advanced form of `package.json` scripts, providing additional metadata and capabilities. In this tutorial, we utilize the `project.json` approach primarily because we take advantage of Nx Plugins.
@@ -233,6 +241,8 @@ So, what are Nx Plugins? Nx Plugins are optional packages that extend the capabi
 
 ## Creating New Components
 
+{% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=706" /%}
+
 You can just create new React components as you normally would. However, Nx plugins usually also ship [generators](/core-features/plugin-features/use-code-generators). They allow you to easily scaffold code, configuration or entire projects. To see what capabilities the `@nx/react` plugin ships, run the following command and inspect the output:
 
 ```shell {% command="npx nx list @nx/react" path="myreactapp" %}
@@ -306,6 +316,8 @@ export default HelloWorld;
 
 ## Building the App for Deployment
 
+{% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=856" /%}
+
 If you're ready and want to ship your application, you can build it using
 
 ```shell {% command="npx nx build" path="myreactapp" %}
@@ -325,6 +337,8 @@ All the required files will be placed in the `dist/myreactapp` folder and can be
 
 ## You're ready to go!
 
+{% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=906" /%}
+
 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:
@@ -334,6 +348,8 @@ But there's more to learn. You have two possibilities here:
 
 ## Modularizing your React App with Local Libraries
 
+{% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=986" /%}
+
 When you develop your React 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.
 
 ```
@@ -363,6 +379,8 @@ Nx allows you to separate this logic into "local libraries". The main benefits i
 
 ### Creating Local Libraries
 
+{% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=1041" /%}
+
 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 React library generator:
 
 ```
@@ -427,6 +445,8 @@ Each of these libraries
 
 ### Importing Libraries into the React Application
 
+{% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=1245" /%}
+
 All libraries that we generate automatically have aliases created in the root-level `tsconfig.base.json`.
 
 ```json {% fileName="tsconfig.base.json" %}
@@ -561,6 +581,8 @@ export default App;
 
 ## Visualizing your Project Structure
 
+{% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=1416" /%}
+
 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:
@@ -638,6 +660,8 @@ Exercise for you: change the codebase such that `modules-shared-ui` is used by `
 
 ## Imposing Constraints with Module Boundary Rules
 
+{% video-link link="https://youtu.be/OQ-Zc5tcxJE?t=1456" /%}
+
 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