fix: update more readmes

docs/src/content/docs/challenges/angular/33-decoupling.md

@@ -17,11 +17,11 @@ WIP: The following documentation will be reviewed and improved. However, you can
 
 ## Information
 
-The goal of this challenge is to separate the behavior of a component from its style. For the purpose of this challenge, we will be working on a button element. When we click on it, we will toggle a _disabled_ property which will change the style of the element. This is quite useless in real life but the challenge aims to demonstate a useful concept.
+The goal of this challenge is to separate the behavior of a component from its style. For the purpose of this challenge, we will be working on a button element. When we click on it, we will toggle a _disabled_ property which will change the style of the element. This is quite useless in real life but the challenge aims to demonstrate a useful concept.
 
-The behavior of the component (referred to as the _brain_ in the Spartan stack) is located in the brain library. The styling part (referred to as the _helmet_) is located inside the helmet library. Both libraries cannot depend on each other because we want to be able to publish them separatly. To help us address the issue, we are using the Nx enforce eslint rule. You can find more details [here](https://nx.dev/core-features/enforce-module-boundaries);
+The behavior of the component (referred to as the _brain_ in the Spartan stack) is located in the brain library. The styling part (referred to as the _helmet_) is located inside the helmet library. Both libraries cannot depend on each other because we want to be able to publish them separately. To help us address the issue, we are using the Nx enforce eslint rule. You can find more details [here](https://nx.dev/core-features/enforce-module-boundaries);
 
-However the button's helmet needs to access the state of the component to style the button differently based on its state. As mention above, we cannot import the `BtnDisabledDirective` directly into the helmet library as done currently. If you go to [`BtnHelmetDirective`](../../libs/decoupling/helmet/src/lib/btn-style.directive.ts), you will encounter a linting error. **A project tagged with "type:hlm" can only depend on libs tagged with "type:core"**.
+However the button's helmet needs to access the state of the component to style the button differently based on its state. As mention above, we cannot import the `BtnDisabledDirective` directly into the helmet library as done currently. If you go to [`BtnHelmetDirective`](../../libs/decoupling/helmet/src/lib/btn-style.directive.ts), you will encounter a linting error. **A project tagged with `type:hlm` can only depend on libs tagged with `type:core`**.
 
 ## Statement
 

docs/src/content/docs/challenges/ngrx/2-effect-selector.md

@@ -19,7 +19,7 @@ For this exercice, you will have a dashboard of activities displaying the name,
 
 In NgRx, **selectors** is a very powerful tool often **misused**. You should use them as soon as you need to transform an already existing data in the store.
 
-- You shouldn't store **derived state**. This is error prone because when your data change, you will have to change it at multiple places => you should have only one place of truth with that data, and every transformation should be done in a **selector**.
+- You shouldn't store **derived state**. This is error prone because when your data changes, you will have to change it at multiple places => you should have only one place of truth with that data, and every transformation should be done in a **selector**.
 
 - Inside a component, you shouldn't transform a selector (using map operator), or you shouldn't have to call a selector from a function in your view. The useful data for a component should be done in a **selector**.
 

docs/src/content/docs/challenges/ngrx/7-power-effect.md

@@ -18,9 +18,9 @@ NgRx Effect is a very powerful library develop by the NgRx team. Effects subscri
 
 But what we often forget is that Effects can subscribe to ANY observables. Which means we can wrap a hot observable inside an effect and had logic in it.
 
-In this exercice, we will find a way to create a very powerful, scalable and maintanable push messages listener. Currently, the code is located inside a single file with a if else condition to send the push data to the right location. This code is not very scalable since we need to add more and more else, and so not very maintanable since the piece of code will become bigger and bigger.
+In this exercice, we will find a way to create a very powerful, scalable and maintanable push messages listener. Currently, the code is located inside a single file with a if else condition to send the push data to the right location. This code is not very scalable since we need to add more and more else, and so not very maintainable since the piece of code will become bigger and bigger.
 
-Also, we load the whole file at startup even if we haven't load some part of the application (lazy loading); and so we don't need to listen or update that part of the store. We need to decouple that logic.
+Also, we load the whole file at startup even if we haven't loaded some part of the application (lazy loading); and so we don't need to listen or update that part of the store. We need to decouple that logic.
 
 ### Step 1
 

docs/src/content/docs/challenges/performance/37-ngfor-biglist.md

@@ -30,6 +30,6 @@ The goal of this challenge is to implement a better alternative to display big l
 <details>
   <summary>Hint 1</summary>
 
-If you're unsure where to begin, I recommend reading the [Angular CDK virtualization documentation](https://material.angular.io/cdk/scrolling/overview)
+If you're unsure where to begin, I recommend reading the [Angular CDK virtualization documentation](https://material.angular.io/cdk/scrolling/overview).
 
 </details>

docs/src/content/docs/challenges/testing/19-input-output.md

@@ -20,7 +20,7 @@ For testing cypress, you will execute your test inside the `child.component.cy.t
 
 # Statement
 
-The goal is to test multiple behaviors of the application describe inside each test files using Testing library and Cypress Component Testing.
+The goal is to test multiple behaviors of the application described inside each test file using Testing library and Cypress Component Testing.
 
 :::note
 I have created some `it` blocks but feel free to add more tests if you want.

docs/src/content/docs/challenges/testing/20-modal.md

@@ -18,13 +18,13 @@ The goal of this challenge is to test the dialogs inside your application. To do
 
 You can play with it by running : `npx nx serve testing-modal`.
 
-The file named `app.component.spec.ts` will let test your application using Testing Library. To run the test suits, you need to run `npx nx test testing-modal`. You can also install [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) to execute your test by clicking on the `Run` button above each `describe` or `it` blocks.
+The file named `app.component.spec.ts` will let you test your application using Testing Library. To run the test suites, you need to run `npx nx test testing-modal`. You can also install [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) to execute your test by clicking on the `Run` button above each `describe` or `it` blocks.
 
-For testing cypress, you will execute your test inside the `app.component.cy.ts` and run `npx nx component-test testing-modal` to execute your test suits. You can add the `--watch` flag to execute your test in watch mode.
+For testing with Cypress, you will execute your test inside `app.component.cy.ts` and run `npx nx component-test testing-modal` to execute your test suites. You can add the `--watch` flag to execute your test in watch mode.
 
 # Statement
 
-The goal is to test multiple behaviors of the application describe inside each test files using Testing library and Cypress Component Testing.
+The goal is to test multiple behaviors of the application described inside each test file using Testing library and Cypress Component Testing.
 
 :::note
 I have created some `it` blocks but feel free to add more tests if you want.

docs/src/content/docs/challenges/testing/24-harness-creation.md

@@ -43,6 +43,6 @@ Additionally, you should create a `HarnessPredicate` with the default predicate
 
 Lastly, you will need to create the test suite for `app.component`. Some default tests have already been written, but feel free to add as many tests as you want and create as many harness methods as you need.
 
-> Angular Material documentation can be found [here](https://material.angular.io/cdk/test-harnesses/overview)
+> Angular Material documentation can be found [here](https://material.angular.io/cdk/test-harnesses/overview).
 
 Good luck !!! 💪