feat(rxjs): refactor challenge 11

This commit is contained in:
thomas
2025-01-29 20:25:35 +01:00
parent 2050f7a932
commit 3cea14982e
111 changed files with 31 additions and 2787 deletions

View File

@@ -1,40 +0,0 @@
---
title: 🟠 Effect vs Selector
description: Challenge 2 is about learning the difference between effects and selectors in NgRx
author: thomas-laforge
contributors:
- tomalaforge
- tomer953
- svenson95
- jdegand
- LMFinney
challengeNumber: 2
command: ngrx-effect-vs-selector
blogLink: https://medium.com/@thomas.laforge/ngrx-effect-vs-reducer-vs-selector-58337ab59043
videoLinks:
- link: https://youtu.be/7fr6JBRocQM
alt: Effect vs selector video by Amos Lucian Isaila
flag: ES
sidebar:
order: 113
---
For this exercise, you will have a dashboard of activities displaying the name, the main teacher and a list of possible substitutes.
## Information
In NgRx, **selectors** is a very powerful tool that is 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 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 the map operator), and you shouldn't have to call a selector from a function in your view. The useful logic for preparing data for a component should be done in a **selector**.
## Statement
You will have to refactor this working example of a dashboard of activities.
## Constraints
- Only **one action** should be dispatched from a component (or none, if you can solve the problem with Effect lifecycle hooks).
- Status effect is useless. Using **combineLatest** should be a red flag. Effects are made for side effects, not for transforming data. That's a selector's role.
- Status state might not be useful; it's only a **derived state** of existing state.

View File

@@ -1,46 +0,0 @@
---
title: 🔴 Power of Effect
description: Challenge 7 is about creating an NgRx effect with another Rxjs Hot observable
author: thomas-laforge
contributors:
- tomalaforge
- tomer953
- jdegand
- LMFinney
challengeNumber: 7
command: ngrx-power-of-effect
sidebar:
order: 206
---
## Information
This application exhibits local and global state confusion. Right now, a notification service is used to update the component lists of students and teachers. You need to add schools to this service, but you _cannot_. The school component uses its _own_ local state inside a `ComponentStore`. Thus, you are unable to dispatch an action in the notification service that the school component can respond to (remember, component stores do not have `actions`). So, how can we get around these issues?
Injection tokens and NgRx effects can greatly help.
`NgRx Effects` is a very powerful library developed by the NgRx team. Effects subscribe to a HOT Observable and listen for all events dispatched inside an application. `NgRx Effects` can subscribe to _any_ observable, which means we can wrap a hot observable inside an effect and add logic to it. You don't have to worry about the local or global state. Although you should be mindful of bad practices, when you refactor this application, you should make a determination of what should be a part of the local state and what should be a part of the global state.
In this exercise, we will need to find a way to create a very powerful, scalable, and maintainable push message listener.
### Step 1
Create an injection token to `inject` the push service inside each component. Injection tokens are very powerful. If you are unfamiliar with them, you may want to complete the [Injection token challenge](https://angular-challenges.vercel.app/challenges/angular/39-injection-token) first. This [article](https://netbasal.com/the-hidden-power-of-injectiontoken-factory-functions-in-angular-d42d5575859b) is also a great resource.
_Eliminate_ the notification service. It is not extensible. Testing (not required for this challenge) the notification service would also be overly complicated. You would need to test each branching scenario. Injection tokens can easily be mocked.
Since the notification service is global, all component lists update, even if a user is not on that route. We need to decouple that logic. The notification messages should display only on their respective routes.
### Step 2
Create one NgRx effect or component store effect for each push type, and implement your logic.
### Step 3
Show an [Angular Material snackbar](https://material.angular.io/components/snack-bar/overview) notification when an add event happens. Make each notification distinct.
### Step 4
Load your effect only when necessary.
The application contains a root route, a lazy loaded route, and a component with a local state (implemented with `ComponentStore`).