Bibliothèque Numérique Article Blog

est-ce que tu peux me donner des infos sur la bibliothèque “article blog” ?

Jul 14, 5:00pm

La bibliothèque numérique "article blog" se concentre sur les systèmes de design, l'accessibilité, et le testing web. Elle promeut l'utilisation de solutions HTML/CSS, l'usage pragmatique des frameworks, des pratiques efficaces pour les développeurs principaux, et des localisateurs axés sur l'accessibilité pour des tests robustes avec des outils comme Playwright et Selenium. Elle met également l'accent sur le code de test maintenable et lisible, et une utilisation efficace du shell.

Jul 14, 5:00pm

il s’agit d’article de mon blog, et j’aimerai que tu extraies le style d’écriture pour écrire comme moi

Jul 14, 5:02pm

Pour extraire le style d'écriture de vos articles de blog, je vais commencer par effectuer une recherche dans la bibliothèque "article blog" pour obtenir quelques exemples de vos articles. Ensuite, j'analyserai ces exemples pour identifier les caractéristiques principales de votre style d'écriture. Je vais commencer par la recherche.

Je vais maintenant ouvrir les articles pour en extraire le style d'écriture.

Voici quelques caractéristiques de votre style d'écriture basé sur les articles que vous avez partagés :

Approche Conversationnelle :
- Vous utilisez un ton conversationnel et direct, comme si vous parliez directement au lecteur. Cela rend vos articles accessibles et engageants.
- Exemple : "Vous voyez la différence ? Là on ne parle pas de lire du code, mais d'analyser des résultats de tests."
Utilisation de Questions Rhétoriques :
- Vous posez souvent des questions rhétoriques pour engager le lecteur et les amener à réfléchir sur le sujet.
- Exemple : "Pourquoi ? Quand on dev on factorise le code. Ça tombe bien : les tests automatisés c'est du code, donc on peut faire la même chose !"
Exemples Concrets et Pratiques :
- Vous fournissez des exemples concrets et des extraits de code pour illustrer vos points, ce qui aide les lecteurs à comprendre les concepts techniques.
- Exemple : "Un exemple ? Prenons un cas super simple !" suivi d'un extrait de code.
Humour et Emojis :
- Vous utilisez l'humour et des emojis pour rendre le contenu plus léger et agréable à lire.
- Exemple : "Et bim ça fait des ~~chocapics~~ tests propres !"
Structuration Claire :
- Vos articles sont bien structurés avec des titres et sous-titres clairs, ce qui facilite la lecture et la compréhension.
- Exemple : "## Mais des petits tests, ça veut dire beaucoup se répéter !"
Transparence et Honnêteté :
- Vous êtes transparent sur vos opinions et expériences, et vous encouragez les lecteurs à avoir leurs propres avis.
- Exemple : "Comme je le disais en introduction : je ne suis pas expert en Design System, en création de librairie de composant ou même en design, j'ai acquis des concepts au fil du temps, j'ai une expérience qui fait que je me suis forgé un avis."
Utilisation de Listes et de Mise en Évidence :
- Vous utilisez des listes et des mises en évidence pour organiser l'information et attirer l'attention sur des points importants.
- Exemple : "Il faut prendre en compte 4 points :"
Appel à l'Action et à la Réflexion :
- Vous encouragez souvent les lecteurs à réfléchir et à agir sur les sujets abordés.
- Exemple : "Mon but premier avec cet article est de vous pousser à réfléchir sur votre besoin réel autour du Design System et tout ce qui gravite autour, ainsi qu'au coût impliqué par la création d'un Design System."

En résumé, votre style d'écriture est accessible, engageant, et pratique, avec une bonne dose d'humour et de transparence. Vous utilisez des exemples concrets et une structuration claire pour rendre vos articles informatifs et agréables à lire.

Jul 14, 5:02pm

index.md

Voici la version markdown (écrite avec Marp) de la présentation de mon dernier talk

Jul 14, 5:03pm

Je suis désolé mais je ne peux pas ouvrir ou lire le contenu des fichiers téléversés. Cependant, je peux vous aider à formater ou à structurer une présentation en Markdown si vous me donnez le texte ou les points principaux que vous souhaitez inclure. N'hésitez pas à partager les détails !

Jul 14, 5:04pm

2/2

Voici le support de mon dernier talk en version markdown :

---
marp: true
theme: default
title: Adieu RxJS ! Vive les Signals ! Oh wait… - Anthony PENA - https://k49.fr.nf
html: true
footer: @_Anthony_Pena
---
<style>
/* Global style */
section.main-heading h1 {
font-size: 400%;
position: absolute;
bottom: 0.5em;
right: 1em;
text-shadow: #000 0px 0 10px;
}
section.main-heading-top h1 {
font-size: 300%;
position: absolute;
top: 0.5em;
left: 1em;
text-shadow: #000 0px 0 10px;
}
section.main-heading-top h2 {
position: absolute;
top: 0em;
left: 1em;
}
section.h1-white h1 {
color: white;
}
section:not(.main-heading):not(.main-heading-top) h1 {
background-color: rgba(255,255,255,0.8);
width: fit-content;
padding: .3em 1em;
}
</style>

<style scoped>
h1 {
text-align: center;
}
h6 {
position: absolute;
bottom: 0;
right: 1rem;
color: white;
text-shadow: #000 0px 0 6px;
}
a {
color: white;
}
footer {
display: none;
}
</style>
# Adieu RxJS ! Vive les Signals ! Oh wait…
###### Anthony Pena
![bg](img/king-fight.webp)
---
<style scoped>
h3 {
display: flex;
align-items: end;
}
h4:not(:first-child) {
margin-top: 0;
}
h4 img {
max-width: 2em;
max-height: 0.9em;
display: inline-block;
vertical-align: middle;
}
section {
content: "";
background: url(img/social/axolotl-bg2.png) white no-repeat top -80px left -70px;
background-size: 35%;
}
figure img {
/* Ça marche pas mais c'est le style pour avoir l'image de gauche en biseau plutôt qu'avec un cut vertical droit */
clip-path: polygon(0px 0px, 100% 0px, 80% 100%, 0px 100%);
}
img[alt="angulardevs.fr"], img[alt="naoned.computer-club.fr"] {
max-width: 5rem;
max-height: 5rem;
display: inline;
}
footer {
display: none;
}
</style>
![bg right:33%](img/social/me.jpg)
# Anthony Pena
### Développeur Web Fullstack @ ![center height:2em](img/social/sfeir-rose.png)
![angulardevs.fr](img/social/angular-devs.svg) ![angulardevs.fr](img/social/wow.png) ![naoned.computer-club.fr](img/social/ncc.png)
---
<style scoped>
h1 {
position: absolute;
top: 2em;
left: 2em;
}
</style>
# Avant les frameworks
![bg](./img/prehistoric-tools.jpeg)

---
# La Réactivité ?
![bg](./img/newton-pendulum.jpeg)

---
<style scoped>
blockquote {
font-size: 130%
}
a {
position: absolute;
bottom: 0;
right: 20px;
color: gray;
}
</style>
> "A declarative programming model for updating based on changes to state."
>
> -- Kristen / pzuraq
https://www.pzuraq.com/blog/what-is-reactivity

---
<style scoped>
h1 {
position: absolute;
top: 2em;
right: 2em;
}
</style>
# Angular.JS et ses watchers
![bg](./img/middle-age-farming.jpeg)

---
<style scoped>
h1 {
position: absolute;
bottom: 2em;
left: 2em;
}
</style>
# Angular 2 et Zone.js
![bg](./img/stream-locomotive.jpeg)

---
```TypeScript
@Component({
template: `
<p>{{ text }}</p>
`,
})
export class PlaygroundComponent {
text = "";
ngOnInit() {
setInterval(() => this.text += '!', 1_000)
}
}
```

---
```TypeScript
@Component({
template: `
<input (change)="setText($event)"/>
<p>{{ text }}</p>
`,
})
export class PlaygroundComponent {
text = "";
setText(event: Event) {
this.text = (event.target as HTMLInputElement).value;
}
}
```

---
```TypeScript
@Component({
template: `
<input [(ngModel)]="text"/>
<p>{{ text }}</p>
`,
})
export class PlaygroundComponent {
text = "";
ngOnInit() {
setInterval(() => this.text += '!', 1_000)
}
}
```

---
```TypeScript
@Component({
selector: 'app-root',
standalone: true,
template: `
<p>{{ text }}</p>
`,
})
export class PlaygroundComponent {
text = "waiting...";
ngOnInit() {
this.asyncHello().then(text => this.text = text);
}
private asyncHello(): Promise<string> {
// ...
}
}
```

---
```TypeScript
@Component({
template: `
<p>{{ text | async }}</p>
`,
})
export class PlaygroundComponent {
text = this.asyncHello();
private asyncHello(): Promise<string> {
// ...
}
}
```

---
```TypeScript
@Component({
template: `
<app-alert>Alert</app-alert>
<p>{{ text }}</p>
<app-card />
<app-card />
`,
})
export class PlaygroundComponent {
@Input() text: string;
}
```
---
```TypeScript
@Component({
template: `
<app-alert>Alert</app-alert>
<p>{{ text }}</p>
<app-card />
<app-card />
`,
})
export class PlaygroundComponent {
@Input() text: string;
@Output() textChange = new EventEmitter<string>();
}
```
---
```TypeScript
@Component({
template: `
<app-alert>Alert</app-alert>
<p>{{ text }}</p>
<app-card />
<app-card />
`,
})
export class PlaygroundComponent {
@Input() text: string;
@Output() textChange = new EventEmitter<string>();
@ViewChild(Alert) alerts: Alert;
}
```
---
```TypeScript
@Component({
template: `
<app-alert>Alert</app-alert>
<p>{{ text }}</p>
<app-card />
<app-card />
`,
})
export class PlaygroundComponent {
@Input() text: string;
@Output() textChange = new EventEmitter<string>();
@ViewChild(Alert) alerts: Alert;
@ViewChildren(CustomCard) cards: QueryList<CustomCard>;
}
```
---
<style scoped>
h1 {
position: absolute;
top: 2em;
right: 2em;
}
</style>
# C'est cool tout ça non ?
![bg](./img/cool-stuff.jpeg)

---
# Oui mais Zone.js
![bg](./img/zone_wide.jpeg)

---
<style scoped>
h1 {
position: absolute;
bottom: 2em;
left: 2em;
}
</style>
# Angular 17 et les Signals
![bg](./img/starship.webp)

---
```TypeScript
@Component({
template: ` <p>{{ text() }}</p> `,
})
export class PlaygroundComponent {
text = signal('');
constructor() {
setInterval(() => {
this.text.set(this.text() + '!');
// or
// this.text.update((actual) => actual + '!')
}, 1_000);
}
}
```

---
<style scoped>
img {
width: 20rem;
position: absolute;
bottom: 1rem;
right: 1rem;
}
</style>
```TypeScript
@Component({
template: ` <p>{{ text() }}</p> `,
})
export class PlaygroundComponent {
text = signal('');
constructor() {
setInterval(() => {
this.text.set(this.text() + '!');
// or
// this.text.update((actual) => actual + '!')
}, 1_000);
}
}
```
![](img/what-kind-of-sorcery.jpg)
---
<style scoped>
img {
/* border: 1px solid red; */
margin-top: 0%;
margin-left: 25%;
width: 50%;
height: 220px;
object-fit: cover;
object-position: 0 0;
}
</style>
![](img/signals-explains.drawio.svg)

---
<style scoped>
img {
/* border: 1px solid red; */
margin-top: 0%;
margin-left: 25%;
width: 50%;
height: 220px;
object-fit: cover;
object-position: 0 -300px;
}
</style>
![](img/signals-explains.drawio.svg)

---
<style scoped>
img {
/* border: 1px solid red; */
margin-top: 0%;
margin-left: 25%;
width: 50%;
height: 260px;
object-fit: cover;
object-position: 0 -530px;
}
</style>
![](img/signals-explains.drawio.svg)

---
```TypeScript
@Component({
template: `
<input (change)="setText($event)" />
<p>{{ text() }}</p>
`,
})
export class PlaygroundComponent {
text = signal('');
setText(event: Event) {
this.text.set((event.target as HTMLInputElement).value);
}
}
```

---
```TypeScript
@Component({
template: `<p>{{ text() }}</p> `,
})
export class PlaygroundComponent {
text = signal('waiting...');
constructor() {
this.asyncHello().then((text) => this.text.set(text));
}
private asyncHello(): Promise<string> {
// ...
}
}
```

---
```TypeScript
@Component({
template: `
<p>{{ text() }}</p>
<p>{{ questionText() }}</p>
`,
})
export class PlaygroundComponent {
text = signal('');
questionText = computed(() => this.text().replaceAll('!', '?'));
constructor() {
setInterval(() => {
this.text.set(this.text() + '!');
}, 1_000);
}
}
```

---
```TypeScript
@Component({
template: ` <p>{{ text() }}</p> `,
})
export class PlaygroundComponent {
text = signal('');
constructor() {
setInterval(() => this.text.set(this.text() + '!'), 1_000);
effect(() => {
console.log('text =', this.text());
});
}
}
```

---
```TypeScript
@Component({
template: `
<app-alert>Alert</app-alert>
<p>{{ text }}</p>
<app-card />
<app-card />
`,
})
export class PlaygroundComponent {
@Input() text: string;
@Output() textChange = new EventEmitter<string>();
@ViewChild(Alert) alerts: Alert;
@ViewChildren(CustomCard) cards: QueryList<CustomCard>;
}
```
---
```TypeScript
@Component({
template: `
<app-alert>Alert</app-alert>
<p>{{ text() }}</p>
<app-card />
<app-card />
`,
})
export class PlaygroundComponent {
text = input('');
@Output() textChange = new EventEmitter<string>();
@ViewChild(Alert) alerts: Alert;
@ViewChildren(CustomCard) cards: QueryList<CustomCard>;
}
```

---
```TypeScript
@Component({
template: `
<app-alert>Alert</app-alert>
<p>{{ text() }}</p>
<app-card />
<app-card />
`,
})
export class PlaygroundComponent {
text = input('');
textChange = output<string>();
@ViewChild(Alert) alerts: Alert;
@ViewChildren(CustomCard) cards: QueryList<CustomCard>;
}
```

---
```TypeScript
@Component({
template: `
<app-alert>Alert</app-alert>
<p>{{ text() }}</p>
<app-card />
<app-card />
`,
})
export class PlaygroundComponent {
text = input('');
textChange = output<string>();
alerts = viewChild(Alert);
cards = viewChildren(CustomCard);
}
```


---
# Signals ❤️
![bg](./img/signals-love.jpeg)

---
<style scoped>
section {
background: url(./img/github-tc39-signals_2.png) top center no-repeat;
background-size: cover
}

h1 {
position: absolute;
bottom: 1rem;
}
a {
position: absolute;
bottom: 0;
right: 20px;
color: gray;
background-color: rgba(255,255,255,0.8);
width: fit-content;
padding: 0;
}
</style>
# Bientôt un standard ?
https://github.com/tc39/proposal-signals

---
# Zone.js c'est fini ?
![bg](./img/cleaning-toxic-zone.jpeg)

---
# Oups j'ai oublié RxJS dans tous ça 🙊 (non)

---
<style scoped>
h1 {
position: absolute;
bottom: 1rem;
}
</style>
# Mais au fait... C'est quoi RxJS ?
![bg](./img/rxjs-what.webp)
---
# RxJS
![bg center](./img/reactivex-bg.png)
---
# ReactiveX for JavaScript
![bg center](./img/reactivex-bg.png)

---
![bg center](./img/reactivex.png)

---
# Parlons Observable
![bg](./img/lazy-observer.jpeg)

---
```TypeScript
import { toObservable, toSignal } from '@angular/core/rxjs-interop';
@Component({})
export class PlaygroundComponent {
text = signal('Hello');
text$ = toObservable(this.text);
textSignal = toSignal(this.text$);
}
```

---
![bg cover](./img/tracy-lee_citation-de-ben-lesh_signals-vs-observable_wide2.jpg)
---
<style scoped>
section {
background: url(./img/broken-heart.jpeg) bottom center no-repeat;
background-size: cover
}
</style>
# Mais du coup les Signals...

---
<style scoped>
section {
background: url(./img/sharing.jpeg) bottom right no-repeat;
background-size: contain;
background-color: white;
}
</style>
# Quelques cas concrets
---
# HttpClient
```TypeScript
@Component({
template: ` <button (click)="clicked()">Get</button> `,
})
export class PlaygroundComponent {
http = inject(HttpClient);
clicked() {
this.http.get('/axolotl').subscribe();
}
}
```

---
# ... et interceptor
```TypeScript
export function authInterceptor(
req: HttpRequest<unknown>,
next: HttpHandlerFn
): Observable<HttpEvent<unknown>> {
return next(
req.clone({
headers: req.headers.set('X-Quiz', 'Axolotl'),
})
);
}
```

---
# resource & rxResource (Angular 19+)
```TypeScript
@Component({
template: `<p>{{axo.value().name}}</p>`,
})
export class PlaygroundComponent {
axo = resource({
loader: async () => (await fetch('/axolotl')).json(),
});
}
```
---
# resource & rxResource (Angular 19+)
```TypeScript
@Component({
template: `<p>{{axo.value().name}}</p>`,
})
export class PlaygroundComponent {
http = inject(HttpClient);
axo = rxResource({ loader: () => this.http.get('/axolotl') });
}
```

---
# État interne des composants
```TypeScript
@Component({
template: ` <p>{{ text() }}</p> `,
})
export class PlaygroundComponent {
text = signal('');
}
```

---
# Reactive Forms
![bg](./img/forms.jpeg)

---
# Services
![bg](./img/buttler.jpeg)

---
<style scoped>
h1 {
max-width: 55%;
text-align: center;
}
</style>
# Global state management<br/>(NgRx, NgXs)
![bg](./img/stone-registry.jpeg)

---
# The NgXs way
![bg left:54%](./img/way.jpeg)

---
# Classic way
```TypeScript
@Component({ ... })
export class ZooComponent {
animals$: Observable<string[]> = this.store.select(ZooState.getAnimals);
constructor(private store: Store) {}
}
```
---
# Signal way
```TypeScript
@Component({ ... })
export class ZooComponent {
animals = select(ZooState.getAnimals);
}
```
---
# The NgRx way
![bg right:54%](./img/way.jpeg)

---
```TypeScript
type BooksState = {
books: Book[];
isLoading: boolean;
filter: { query: string; order: 'asc' | 'desc' };
};
const initialState: BooksState = {
books: [],
isLoading: false,
filter: { query: '', order: 'asc' },
};
export const BooksStore = signalStore(
withState(initialState),
withComputed(/* ... */),
withMethods((store, booksService = inject(BooksService)) => ({/* ... */}}))
);
```
---
```TypeScript
@Component({
providers: [BooksStore],
})
export class BooksComponent {
readonly store = inject(BooksStore);
}
```
---
# The NgRx way
```TypeScript
export const BooksStore = signalStore(
withMethods((store, booksService = inject(BooksService)) => ({
loadByQuery: rxMethod<string>(
pipe(
debounceTime(300),
distinctUntilChanged(),
tap(() => patchState(store, { isLoading: true })),
switchMap((query) => {
/* ... */
})
)
),
}))
);
```
---
# En résumé
![bg](./img/summary.jpeg)
---
# Les Signals c'est pour gérer les états et la réactivité dans les composants
![bg](./img/components_signals.jpeg)
---
# RxJS est là pour gérer tous vos flux de données
![bg](./img/stream_rxjs.jpeg)
---
<style scoped>
a {
position: absolute;
bottom: 0;
right: 20px;
color: gray;
}
</style>
![bg](./img/ben-lesh-signals-vs-observable.png)
https://x.com/BenLesh/status/1775207971410039230
---
# Feedback
![bg right](./img/feedback.png)
---
<style scoped>
h3 {
display: flex;
align-items: end;
}
h4:not(:first-child) {
margin-top: 0;
}
h4 img {
max-width: 2em;
max-height: 0.9em;
display: inline-block;
vertical-align: middle;
}
section {
background: url(img/social/axolotl-bg.png) white no-repeat bottom -60px right -55px;
background-size: 35%;
}
figure img {
/* Ça marche pas mais c'est le style pour avoir l'image de gauche en biseau plutôt qu'avec un cut vertical droit */
clip-path: polygon(0px 0px, 100% 0px, 80% 100%, 0px 100%);
}
img[alt="angulardevs.fr"], img[alt="naoned.computer-club.fr"] {
width: 5rem;
display: inline;
}
footer {
display: none;
}
</style>
![bg left:33%](img/social/me.jpg)
# Anthony Pena
### Développeur Web Fullstack @ ![center height:2em](img/social/sfeir-rose.png)
#### ![](img/social/twitter.png) @\_Anthony\_Pena\_
#### ![](img/social/github.png) @kuroidoruido
#### ![](img/social/linkedin.png) @penaanthony
#### https://k49.fr.nf
#### https://github.com/kuroidoruido/talks
![angulardevs.fr](img/social/angular-devs.svg) ![angulardevs.fr](img/social/wow.png) ![naoned.computer-club.fr](img/social/ncc.png)
---
![bg black](./img/social/thanks.gif)

Jul 14, 5:04pm

Votre présentation Markdown est bien structurée et utilise des fonctionnalités avancées de Marp pour créer des diapositives attrayantes et informatives. Voici quelques points clés et suggestions pour améliorer ou maintenir votre présentation :

Points Forts

Structure Claire :
- Vous avez utilisé des titres et sous-titres pour organiser votre contenu de manière logique.
- Les sections sont bien définies et chaque diapositive a un objectif clair.
Utilisation de Styles et de Mise en Page :
- Vous avez utilisé des styles CSS pour personnaliser l'apparence de vos diapositives, ce qui les rend visuellement attrayantes.
- Les images de fond et les styles appliqués aux titres et au texte aident à maintenir l'attention du public.
Exemples de Code :
- Les extraits de code sont bien intégrés et illustrent clairement les concepts que vous présentez.
- Les commentaires dans le code aident à expliquer ce qui se passe, ce qui est utile pour le public.
Utilisation d'Images et de Graphiques :
- Les images et les graphiques aident à illustrer vos points et à rendre la présentation plus engageante.
- Les images de fond et les icônes ajoutent une touche visuelle agréable.

Suggestions d'Amélioration

Consistance des Styles :
- Assurez-vous que les styles sont cohérents tout au long de la présentation. Par exemple, vérifiez que les tailles de police et les couleurs sont uniformes.
Accessibilité :
- Assurez-vous que le texte est lisible sur tous les arrière-plans. Par exemple, vérifiez le contraste entre le texte et les images de fond.
- Ajoutez des descriptions alternatives pour les images pour les rendre accessibles à tous les publics.
Simplicité :
- Évitez de surcharger les diapositives avec trop d'informations. Essayez de garder chaque diapositive simple et concentrée sur un seul point principal.
- Utilisez des puces pour les listes et évitez les blocs de texte denses.
Interactivité :
- Si possible, ajoutez des éléments interactifs ou des questions pour engager le public et rendre la présentation plus dynamique.

Exemple de Diapositive Améliorée

Voici un exemple de diapositive avec quelques améliorations :

markdown
---
marp: true
theme: default
title: Adieu RxJS ! Vive les Signals ! Oh wait… - Anthony PENA - https://k49.fr.nf
html: true
footer: @_Anthony_Pena
---

<style>
section {
    font-size: 28px;
}
</style>

<!-- _class: main-heading-top h1-white -->

# Adieu RxJS ! Vive les Signals ! Oh wait…

###### Anthony Pena

![bg](img/king-fight.webp)

---

<style scoped>
h3 {
   display: flex;
   align-items: end;
}
h4:not(:first-child) {
    margin-top: 0;
}
h4 img {
    max-width: 2em;
    max-height: 0.9em;
    display: inline-block;
    vertical-align: middle;
}
section {
    background: url(img/social/axolotl-bg2.png) white no-repeat top -80px left -70px;
    background-size: 35%;
}
footer {
  display: none;
}
</style>

![bg right:33%](img/social/me.jpg)

# Anthony Pena

### Développeur Web Fullstack @ ![center height:2em](img/social/sfeir-rose.png)

- ![angulardevs.fr](img/social/angular-devs.svg)
- ![angulardevs.fr](img/social/wow.png)
- ![naoned.computer-club.fr](img/social/ncc.png)

En suivant ces suggestions, vous pouvez rendre votre présentation encore plus efficace et engageante. Bonne chance avec votre talk !

Jul 14, 5:04pm

Voici la transcription de la dernière fois où j’ai joué mon talk :

Bonjour à tous, Merci d'être venu pour cette conf. Je vous présente Anthony, qui nous vient de Cholet, qui va nous présenter un sujet tournant autour d'Angular. Donc merci, Anthony d'être venu. Et la parole est à toi. Pour les 50 prochaines minutes. Je vous encourage juste un petit truc. Il y a sur le site du DeVquest une partie feedback. Je vous encourage à mettre vos commentaires, que ce soit pour le rassemblement en général ou pour la conférence conf, Ça nous est très utile. Les liens vous seront donnés en fin de slide, Pas d'inquiétude. A Toi Anthony. Anthony Bouchard, RXJS Vivre les signals du coup, Adieu, RxJS, vive les Signals, C'est un peu le message qu'on entend depuis deux ans, On va voir si c'est aussi simple que ça. Je vais commencer par me présenter, Du coup, moi, c'est Anthony, je suis développeur web chez Sphere, Si vous êtes curieux de boîte, venez me voir, Je serai là pendant la conf. Surtout sur mes. Activités communautaires. Le premier logo, c'est Angular DEV France, Donc on a principalement deux ou trois grosses activités. Récemment, il y a eu NGBaguette, C'est pour ça que j'ai le t-shirt aujourd'hui. C'est une conf qu'on a organisée 100% angular en France, Ce n'était pas arrivé depuis 2018, c'était super. On le refait l'année prochaine, N'hésitez pas à venir. Et on a un meetup en ligne tous les mois, où on invite des gens incroyables. Franchement, je ne pensais pas arriver à inviter des gens aussi. Ouf pour parler d'angular en ligne sur YouTube. Et on a Wow Women of New Workshop. Qui est l'idée, c'est d'introduire les femmes à la tech, à travers angular, dans un cercle un peu restreint, un peu confidentiel. Si vous êtes curieux, venez me voir, On est toujours intéressés pour faire grossir le mouvement. Et la petite part de pizza, c'est un apéro mensuel que j'organise sur Nantes. Si vous êtes curieux, venez me voir, je vais en parler. Plus que ça, c'est pas le sujet du jour. On rentre dans le vif du sujet et je vous propose qu'on fasse un peu d'histoire. Donc on va venir un peu à la préhistoire du web. C'est pas si vieux que ça, Ne vous inquiétez pas. Pour moi, c'est un peu 2010 et avant. Pour le Web, c'est très loin, mais c'est pas si vieux que ça en vrai. Donc, grosso modo, pourquoi je dis que c'est la préhistoire du web, c'est en gros, c'est l'avant framework. C'est à l'époque où on avait globalement du Vanilla et du Jico. Jquery ou d'autres alternatives. Certains ont peut-être connu des moodtools, par exemple. Passons. Si vous voyez ce que c'est, JQuery, c'est à peu près ça l'idée. Donc, c'est vraiment, On faisait globalement du JS, pas de build, des fois un petit peu de Bundle, mais à peine. On faisait essentiellement du addeventlistener pour essayer de réagir à quelques éléments pour créer un peu d'interactivité qu'on n'arrivait pas à faire autrement. Et on avait tendance à tout mélanger entre ce qu'on voulait faire, comment on voulait le faire, et la réaction, Et un peu tout combiner. Donc, on avait vite fait du code très spaghetti. Je pense que beaucoup de gens détestaient J.S. de cette époque à cause de ça. A l'époque, on ne parlait pas de réactivité. C'est ça qui est un point clé d'aujourd'hui, c'est vraiment la réactivité. C'est ça qui, pour moi, va tout changer. Mais c'est quoi? La réactivité Parce que c'est le truc qu'on... Qu'on bassine continuellement depuis quelques années, mais on définit vraiment ce que c'est. Définition très basique, la réactivité, le fait de réagir. Un peu facile. Prenons une définition un peu plus intéressante. Je vais citer celle-là, parce que je l'aime bien. Déclaratif programming model for updating based on changes to State. En gros, l'idée, c'est qu'on va avoir un état, On va avoir quelque chose qui va réagir à cet état, et le comment on va le faire. Comment ça va réagir, c'est pas notre problème. On va déclarativement dire, on a un état, on veut en faire quelque chose, et la connexion, On s'en occupe pas. C'est ça le côté. réactivité. C'est vraiment le côté déclaratif. Et pour moi, le premier Framework qui a vraiment introduit ça, ça va peut-être Rappeler des cauchemars à certains, c'est AngularJS. AngularJS, C'est pour moi le premier vrai framework du monde moderne. C'est lui qui a créé tous les fondamentaux des Frameworks qu'on a aujourd'hui. De bonne façon ou de mauvaise façon, c'est pas le sujet, mais vraiment, c'est ça qui a tout créé. Et tout fonctionner à base de Watcher. Ça a l'avantage d'être simple, vous déclarez dans un coin vos variables, D'autre côté, vous dites, vos variables vont arriver dans votre template. Et Angular va régulièrement aller regarder vos variables pour savoir s'il faut les mettre à jour. Donc le régulièrement se discute, parce que c'est pas forcément toujours rapide, Le fait qu'il regarde toutes les variables crée quelque chose qui devient assez vite, très lent et très lourd, Mais ça, le mérite de fonctionner, ça le mérite de ça a eu le mérite, à l'époque, de répondre à la problématique qu'ils avaient et qu'ils cherchaient à remplir. Par contre, ça a plein de problèmes, c'est que, comme je disais, c'est pas forcément très perf, c'est lourd, c'est lent. Parce que forcément, si on a une boucle de Watch, ça veut dire qu'on a un tick. Donc c'est à dire qu'à rythme régulier, on a les Watchers qui vont aller regarder. Mais du coup, si entre deux ticks, on peut rien mettre à jour, enfin, y'a rien. Qui va se mettre à jour explicitement dans l'interface. Et du coup, on obtient plein de limitations à droite, à gauche, et plein de trucs assez affreux qui peuvent se produire quand les apps grossissent. Si vous êtes curieux, j'ai des anecdotes à ce sujet après coup. Mais bon, c'est pas le sujet du jour. Après, l'équipe Angular a réfléchi, a vu qu'ils s'apprenaient, et qu'il y avait vraiment moyen de penser les choses autrement, Et c'est là qu'ils ont introduit Angular 2. Donc, Angular 2, c'est vraiment une révolution. C'est vraiment là qu'on a tout changé. Donc tout changer sur des aspects qui n'étaient pas forcément toujours pratiques du fait de la migration, ce n'est pas le sujet. La vraie grosse différence, c'est le passage des Watchers à zone JS. Donc, zone JS, c'est vraiment la brique qui va tout révulsionner. C'est zone qui va s'occuper de gérer la réactivité. Donc, Angular confie à zone l'existence de variables. Zone dit, la variable a changé, donc. Angular sait qu'il doit réagir. Donc, s'il ne se passe rien pendant 5 secondes dans vos variables, Angular ne fait rien parce que Zone ne lui dit rien. Par contre, si vous avez 18 changements par seconde, Zone va le prévenir 18 fois. Et du coup, c'est lui qui gère le truc. Donc vous êtes super réactif. Donc, c'est super cool, Ça a permis plein de choses. Entre autres, en jouant avec les syntaxes typescript. J'espère que tout le monde voit. Donc ça a permis d'écrire des choses comme ça. Donc, là, si je prends un composant très simple, on a une partie template en haut. Du coup, on a un texte, Le texte est déclaré dans la partie code, dans la partie TypeScript, Et on va déclarer que toutes les secondes, on va modifier la chaîne de caractère. Du coup, toutes les secondes, instantanément, On va modifier le template. Donc, là, à aucun moment, c'est ce que je disais par le côté, C'est là qu'on parle de réactivité, c'est qu'à aucun moment je lui dis comment il doit mettre un joueur. Je lui dis, je mets à jour, ma variable, ma variable est utilisée là, débrouille-toi, C'est pas mon problème. De comment c'est fait. C'est ça qui rend confortable, le fait que qu'on peut se faire du web. On peut faire plein de choses du coup, parce qu'on peut aller aussi du template aux variables. Donc, là, par exemple, J'ai un input, à chaque fois qu'il change, j'appelle une méthode, La méthode va modifier la variable, comme la variable est mappée de l'autre côté, J'ai une boucle qui se crée. Et encore une fois, à aucun moment, je lui dis vraiment comment il doit interagir, Comment? Le template est connecté à la Classe et compagnie. C'est Angular qui s'en occupe, ce n'est pas mon problème. On peut faire énormément de choses, Il y a des syntaxes comme le NGModels ou bananaInTheBox. L'idée, c'est du two-way Data mining, c'est une particularité d'Angular, C'est l'idée de se dire qu'on a une variable qui va être connectée dans les deux sens avec le template. Et là encore une fois, j'ai juste dit « map » , ce n'est pas mon problème de comment ça se passe derrière. Et il y a beaucoup de choses qui se passent derrière. On a une gestion de l'asynchronisme, qui est assez pénible à gérer entièrement à la main. Là, je n'ai pas à m'en occuper. Donc, là, j'ai une promesse qui, quand elle est résolue, va éditer le texte. Et du coup, c'est mappé automatiquement. On a une syntaxe simplifiée, qui est encore plus déclarative. Du coup, ce coup-ci. Parce que, du coup, je n'ai même plus besoin de résoudre ma promesse. moi-même. Et je lui dis, tiens, une promesse, débrouille-toi. On peut faire énormément de choses, Comme faire du passage de données de paroles en fond. Parce que, là aussi, on a de la réactivité. Parce qu'on veut qu'à chaque fois que le parent change, les données d'entrée, les enfants se rendent. Donc, on a une syntaxe à base du atInput, donc c'est pas trop verbeux, c'est plutôt explicite. L'output devient un peu plus verbeux, ça demande de prendre des réflexes, On ne comprend pas trop ce qui se cache derrière l'event émetteur, mais soit, ça marche. Donc, l'output, L'idée, c'est de faire du coup de la communication de l'enfant vers le parent. On peut aller chercher à prendre des références vers les composants. enfants. Avec le ViewChild, Donc, là, on voit que c'est déjà très verbeux parce qu'on a de la répétition de type et c'est pas forcément naturel, Surtout quand on se rappelle que normalement, Il y a une partie des types qui sont censés être éliminés, c'est pas toujours évident. On peut faire des queries sur un ensemble de composants. Donc, là, c'est pareil, du coup, Il faut connaître les types et compagnie, parce que sinon, C'est pas toujours clair de ce qu'on fait. C'est plutôt cool, tout ça, mais comme je dis, vous commencez à le sentir, c'est quand même, Il y a quand même un peu de lenteur. On a besoin de s'habituer aux syntaxes et de... Comprendre plein de mécaniques qui ne sont pas forcément claires. Il y a pas mal d'annotations, ce n'est pas toujours très clair, ce qui se passe derrière. Il y a plein de types à mettre de partout et c'est à nous de les connaître. Parce que, sinon, on a des ordres compilés de partout. Ce n'est pas toujours clair. Mais malgré le fait que ce soit verbeux et compagnie, c'est réactif, ça fonctionne et on s'y est habitué. Angular 2, C'est là depuis un certain temps. Mais l'équipe Angular s'est quand même dit qu'il y a quand même une brique qui nous embête, C'est zone. Je pense que la plupart d'entre vous ne savez pas ce que c'est zone. Pourquoi Parce que Angular, ils n'aiment pas zone en fait. Ils l'ont un peu planqué sous le tapis et ils ont essayé le moins possible de vous donner ce qui se passe derrière, Parce que c'est compliqué. Et ils n'ont pas envie que tout le monde réfléchisse à ce qui se passe derrière zone. Pourquoi En fait, zone, le premier truc qu'il fait, Et c'est ça qu'il y a dans le Polyfill.js qu'il y a dans vos Bundles. Angular, c'est qu'il vient Monkey Patch, l'intégralité de l'API JavaScript. Le Monkey Patch En général, on n'aime pas trop. L'idée, c'est que Zone vient ré-écraser la promise de Javascript et, du coup, va fournir la promise de zone. Et la promise de zone va vrapper la promise de J.S. et du coup, va pouvoir créer de l'interaction comme ça. Le setTimeout, Quand vous faites un settimeout en Angular, vous faites un settimeout de zone qui vient vrapper le settimeout de J.S. et ainsi de suite. Et c'est pareil pour les setters, les getters, les proxys, en fait toute l'API JavaScript. Donc vous vous sentez venir du coup. Oui, c'est mieux que les Watcher parce que c'est plus performant, par contre, on Monkey Patch, Énormément de trucs. L'API Javascript est de plus en plus grande, donc c'est de plus en plus d'un taf colossal de maintenir l'API fonctionnelle. C'est super lourd, parce qu'il faut le maintenir et c'est infect à maintenir. Et il y a un système de contexte dont je n'évoquerai pas, parce que c'est hyper dur d'arriver à comprendre comment ça marche, Mais c'est deux, trois optimes, Mais du coup, c'est des optimes de fou qui sont impossibles à comprendre. Et c'est très automagique. Comme j'ai dit, angular le planque sous le tapis, zone. En général, zone, On découvre qu'il existe quand on se tape les premières erreurs avec les gros stacks trace Angular, où on voit toute une couche zone. On ne comprend rien à ce qu'il y a derrière parce que toutes les minifiées et compagnie ne comprennent aucun nom. Et on ne sait pas quoi en faire. Donc, en fait, C'est une brique qui nous facilite la vie, mais la moindre truc, On ne sait pas quoi en faire. Et il y a une limitation forte au combo angular, plus zone.js, c'est que le niveau de réactivité est bloqué à l'échelle du composant. Vous êtes forcément obligé de rendre un composant entier avec zone s'il y a une mise à jour. Vous ne pouvez pas être au niveau de la variable ou d'une balise HTML. C'est impossible. Parce que c'est inhérent au comportement de ce qu'il y a derrière. Ce qui est déjà bien mieux que le Watcher qu'il y avait avant, On ne va pas se mentir. Mais c'est une limitation forte dans le monde moderne qu'on est aujourd'hui, où on a des applications Web qui sont extrêmement complexes et extrêmement grosses. On ne peut pas se le permettre. C'est là qu'arrive. Angular 17. Et qui introduit en version stable les signals. Si on veut être précis, C'est introduit en version 16 en expérimental. Je fais une petite parenthèse sur le côté expérimental qu'il y a aujourd'hui. Si aujourd'hui vous faites une application en V16, activez les signals en expérimental, profitez-en dès aujourd'hui. Le côté expérimental, ce n'est pas que c'est instable, c'est que l'API peut évoluer au fil du temps. L'API des signals n'a pas évolué globalement entre la V16 et la V20, qui aujourd'hui, les signals ne sont pas prêts de mourir. Ce serait très étrange. Donc, utilisez-le. Passez dans le monde moderne, activez le flag, Vous savez que ça ne bougera pas. Donc profitez-en dès aujourd'hui. Ne vous prenez pas la tête à attendre de basculer dans les versions stables. Donc, les signals, c'est quoi, concrètement ? C'est une mécanique pour gérer l'activité, qui est beaucoup plus fine. L'idée, c'est de gérer ce qu'on appelle de la fine-grain reactivity, donc de la granularité fine de la reactivité. Là, on va réagir à l'échelle d'une variable. Donc, on peut réagir que le strict minimum qu'il faut pour mettre à jour la vue quand une variable change de votre appli. Ce qui est vraiment incroyable. Le concept n'est pas nouveau, Angular l'a introduit en stable en V17, il y a un an et demi, deux ans. Si on compte la V16. Mais en vrai, le concept vient de Solidjs, qui a été introduit en 2019. L'auteur de Solidgest ne s'en cache pas, Il s'est complètement inspiré du Pattern Observer, qui existe depuis aussi longtemps que la programmation objet. Clairement, il n'y a pas de nouveautés dans ce truc-là. C'est juste qu'ils ont formalisé les choses d'une certaine façon. Et pour vous donner une petite idée, aussi, l'auteur de Solid a fait un article où il explique comment il a construit les signals. La version naïve du signal de Solid, elle, fait 15 lignes. Zone.js, C'est des centaines de milliers de lignes. Ça vous donne une petite idée de l'écart de complexité. Ce qui change concrètement, un composant en Signals, finalement, Ce n'est pas si différent que ça. Des composants qu'on avait avant. Donc on a toujours notre template, on a toujours notre variable. Bon, maintenant, On ne met plus juste la variable avec une chaîne de caractères vide, on fait Signal, chaîne de caractères, soit, Un truc à apprendre. Vous avez peut-être tiqué sur le fait que maintenant, il y a des parenthèses au niveau du texte, dans le template. En effet, le Signal, C'est un accessoire, ce n'est pas un... Ce n'est pas une variable en direct, donc il faut mettre des parenthèses. Là, ça m'a fait tiquer la première fois que je l'ai vu parce qu'on m'a toujours dit. Surtout, pas d'appel de fonction dans les templates, parce que c'est pas perf. Et là, l'ongular, ils disent c'est la nouvelle norme. Ok, bon. Et ensuite, pour mettre à jour, on ne fait plus de égal, on fait un .set. Ou un .update. En fonction de comment on veut le gérer. Ça, soit, pas bien grave. Mais du coup, c'est un peu de la sorcellerie, tout ça. Parce que là, on n'a quasiment rien changé et on dit que tout change. Alors oui, en fait, tout change. Avant, on était sur un paradigme différent. On se disait, on a une variable qu'on va affecter avec une valeur, et on va s'arrêter là. Donc, il faut forcément quelque chose d'externe pour aller se rendre compte que quelque chose a changé. Donc, c'est pour ça qu'il y a eu les watchers, c'est pour ça qu'il y a eu zone, D'autres frameworks ont eu d'autres idées. Mais en gros, il faut forcément quelque chose d'externe. Vu que Là, une variable. JS, vous pouvez me dire « préviens-moi quand ça change » . Malheureusement, ce n'est pas possible. Donc l'idée, c'est de se dire « on va faire ça » . Un signal, c'est une boîte. Il faut vraiment l'imaginer comme ça. Vous faites signal, vous mettez une valeur dedans. Donc, là, N n'est plus une variable, mais une boîte qui contient une variable. Et cette boîte possède certaines mécaniques. Donc on peut s'y abonner, on peut l'écouter, on peut voir la réactivité, on peut la modifier. Elle porte une valeur, elle contient vraiment la valeur. Et si on change la valeur, il va y avoir une émission d'une information, Du coup, un signal, d'où le nom, Ça ne sort pas nulle part, qui va prévenir le framework que quelque chose a bougé. Et du coup, là, vous voyez bien, là, on sait précisément ce qui a bougé. Là, Le Angular sait que n est devenu 3. Donc, il sait que tout ce qui dépend de cette variable doit bouger. Il n'a pas besoin de chercher, de faire une boucle de 10 gestes pour essayer de comprendre ce qui a changé à droite, à gauche. Parce qu'il y a une partie de l'appli qui a bougé. Non, il le sait, C'est telle variable qui a changé. On peut continuer à dérouler les exemples. Tous les exemples que je faisais tout à l'heure, on peut les écrire avec des signals. Côté template, ça ne change pas, Sauf que les parentes, On appelle toujours des méthodes, et notre méthode, Au lieu de faire un égal, a fait un set. Jusque-là, pas de changement. L'asynchrone, Ça marche, tout pareil, Sauf qu'on fait du set au lieu du égal. Jusque-là, pas de problème. Pour gérer certains cas, Angular introduit... Un concept intéressant qui s'appelle les Computed signals. Donc, si vous avez eu l'habitude de créer des Behaviors Object pour garder une variable, pour dériver une valeur en cas de changement et compagnie, Ou alors de jouer avec les Ngonchange pour qu'il y ait un truc qui reste un enfer à généraliser? Parce que c'est des patterns qui deviennent très vite lourds, très vite complexes, très vite difficiles à suivre. Les computed, c'est simple. Là, je lui dis J'ai une variable qui est calculée, d'où computed, à partir d'un autre signal. Donc, là, le signal, c'est texte. Donc je lui dis « this text replaced » et là automatiquement, Angular a créé un système qui est réactif, où à chaque changement de texte, ma compute va être actualisée et questionText va contenir la nouvelle valeur. Et il va la calculer uniquement à chaque fois que texte change. Pas dans un book de re-rendu ou je ne sais pas quoi, comme on voit dans certains frameworks. Ce qui est quand même très, très fort, parce que là, je ne lui ai pas dit le comment, J'ai vraiment dit le quoi. Je veux qu'il se passe, ça. On a d'autres manières de réagir. Si on ne veut pas changer une variable, mais créer des effets de bord, par exemple, J'ai mis un console.log, Mais on pourrait imaginer faire un appel réseau à chaque fois que l'ID de notre page change ou quelque chose comme ça. On va utiliser les effects. Donc, là, je lui dis, Je veux que tu m'affiches le texte à chaque fois qu'il change. Donc je lui dis, effect, fonction, console.log, texte égale, virgule, l'appel de mon signal, texte. C'est parti. Automatiquement, il sait que la dépendance de l'effet, c'est le texte et qu'il doit le recalculer. À si vous êtes déjà passé par le monde. React, l'Effect. Ici, c'est la même chose que le useEffect. Juste, vous n'avez pas la notion de dépendance. C'est Angular qui la calcule automatiquement. Et vous n'avez pas besoin de compilation pour ça. On peut réécrire tout, comme je disais, à base de signals, parce qu'évidemment, on se projette. Tout doucement, il y a de plus en plus, donc je ne vais pas montrer 100% des signals, parce qu'il y en a beaucoup maintenant. Les Inputs se simplifient. Donc, maintenant, on passe en inputSignals. Les outputs se simplifient aussi, beaucoup moins de redondance. On s'en fiche qu'il y ait un event emitter, ce n'est pas le sujet. Moi, je suis utilisateur du framework Angular, Je m'en fiche de savoir qu'il y a un event emitter sur le cabot. Moi, je veux déclarer qu'il y a un output. Et pour les Queries, c'est pareil, on simplifie. Beaucoup moins de redondance, beaucoup plus simple, beaucoup plus clair. Donc, c'est la vie, les signals. On adore, Franchement, il n'y a pas de raison de ne pas adorer. C'est beaucoup plus simple. La mécanique derrière, je vous l'ai dit, il n'y a rien de très compliqué. Ce sont des patterns qui sont connus. Tout est mieux au niveau de la gestion de l'asynchrone et compagnie. On n'a plus à gérer une mécanique d'asynchrone, comme on faisait dans certains cas, avec des bidouilles quelconques. Parce qu'on n'avait rien de mieux avant. Et j'ai même un bonus, Ça va peut-être bientôt devenir un standard. En effet, il y a un proposal au niveau du TC39, qui est l'organisme qui régit. La norme d'Ecmascript, donc la norme qui définit ce qu'il y a dans JavaScript. Pour que ça devienne une brique native. Donc, si ça devient une brique native, ça veut dire que tous les Frameworks pourront l'utiliser, déjà, Pas que Angular et Solide, Et vous pourrez l'utiliser, par exemple en node. Parce qu'en effet, dans certains cas, Si vous avez une application qui fait du PUSH de données vers vos fronts, ça veut dire que vous pourrez l'utiliser. Des signals aussi. Et aujourd'hui, Ça fait deux ans que je suis la proposal et que je suis abonné à toutes les notifications, des updates, des issues, partout. Les seuls débats, c'est du naming. Le fond, Tout le monde est d'accord pour dire qu'on a besoin de ça, parce qu'on n'a rien aujourd'hui dans Javascript, qui permet de faire ça, alors qu'on en a besoin. Là, le débat les plus fort, C'est des noms de méthodes où on ne se sent pas d'accord sur comment on ferait les noms. Donc autant dire que je suis sûr que ça va arriver. Il va y avoir un peu de temps, parce que c'est toujours un process long pour être sûr que tout fonctionne, Mais c'est sûr que ça va arriver. Pour la petite Anecdote d'ailleurs, pour faire une proposal, il faut venir avec un polyfill, Moquer du coup de l'API qu'on veut faire pour pouvoir qu'il y ait des tests qui soient faits, Le polyfill proposé, c'est l'implémentation des signals angulaires qui a été prise. Alors que c'est pas la plus vieille. Parce que, dans les faits, ils se sont rendu compte que c'était la plus simple. Et à la fois la plus simple et plus perf. Tant mieux, c'est déjà dans le framework. Donc, du coup, on se dit Bah Zone, c'est fini. Bah, alors presque. C'est pas tout à fait fini. Dans le sens où 100% de toute la réactivité d'Angular ne peut pas être remplacée par des signals aujourd'hui. On a quelques Edge cases, Je ne vais pas revenir dessus parce que c'est assez complexe, et les équipes Angular les décriront mieux que moi. Mais aujourd'hui, on en est au point où, depuis la version 19 d'Angular, on a un flac pour la création de projets pour passer en mode zoneless, donc se débarrasser de cette zone pour tester notre appli. Et on peut activer un mode zoneless depuis la V20 pour plein de choses, pour essayer de voir ce que ça donnerait sur notre appli, voir s'il y a des edge case. Ce qui fait qu'on peut déjà commencer à transitionner. Clairement, c'est la vision d'Angular aujourd'hui, c'est d'aller chercher le zoneless le plus vite possible. J'ai pu discuter avec quelqu'un de la Core Team récemment et vraiment, c'est un objectif fort de la Core Team aujourd'hui, C'est de se débarrasser de zone qui pose trop de problèmes et qui a trop de complexité et qui a un vrai problème. aujourd'hui. Donc clairement, ça va venir. Tester votre app dès aujourd'hui, c'est facile, donc profitez-en. Aujourd'hui, on est en développeur. Preview sur la V20, Vraiment? Tous les outils sont là pour essayer et voir ce qui se passe. L'équipe attend vraiment des retours, donc testez vos apps, c'est le moment. Alors, là, on est à peu près à la moitié de la conf, Et en fait, j'ai oublié la moitié du titre, si vous réfléchissez. Parce que le titre, c'était « Adieu RXJS, vive les Signals » , mais je n'ai pas parlé d'RX. J'ai pas parlé d'RX Bah, c'était pas une erreur, parce qu'en fait, on s'en fiche d'Rx. Utiliser RX pour la réactivité, c'est une erreur en fait. C'est pas fait pour ça. Mais du coup, c'est fait. Pour quoi? RX Voilà, reprenons de la base. Donc, on dit toujours RX, mais c'est RxJS, donc acronyme, on va le décomposer, Reactivex for JavaScript. Donc, ReactiveX, c'est une spécification... Qui a été définie initialement chez Netflix et qui était orientée pour les back-end. Pour faire à la fois de la communication réactive de backend à backend, sur des flux, et de backend à Frontend. Dans certains cas. JavaScript, Je ne vous le détaille pas normalement, vous savez ce que c'est. J'espère en tout cas. ReactivX, Ça se décrit comme ça. Sur le site, c'est ça qui est marqué. An api for asynchronous programming with observable streams. Donc, là, si vous suivez bien, il n'y a aucun moment de parler de réactivité. On ne parle pas du AI. On parle de flux, on parle d'event. Et on parle d'asynchrone. Vraiment, RX n'a aucune notion du High à la base. Le fait d'utiliser du RX pour faire de la réactivité dans le front angular, c'était presque un hack. Ce n'était pas fait pour ça. Parce qu'on ne gérait clairement pas ce qu'il faut. On n'utilisait pas le bon outil pour ça. Et pour confirmer ce que je dis, le côté qu'il n'y a aucune notion du high, pour ceux qui en ont déjà fait, du Nest JS, Ou qu'on a entendu parler au moins, C'est un framework 100% back-end. Très inspiré d'Angular, ce sont d'autres problèmes, qui est entièrement basé sur Rx. Et dans Nest, regardez la doc, Il n'y a aucune notion du high. Vraiment zéro. RX se base sur un pattern qui n'a rien à voir, qui se base sur un concept qui s'appelle l'observable. Je vous ai dit les signals, c'est un pattern observer, là, c'est observable, c'est pas la même chose. Un observable, c'est un élément qui est stateless, Qui est lazy. Et qui est purement fonctionnel et immutable. Un observable, Il n'y a pas de données dedans. Parce que le but, c'est de transiter des flux. C'est de définir un flux de données auquel il va y avoir, des événements qui vont passer dedans. C'est Lazy, au sens où, tant qu'il n'y a personne qui l'écoute, aucune donnée ne transitera. Un signal, c'est stateful, comme je le disais tout à l'heure. Il possède une donnée à un instant T. Un observable, Vous ne pouvez pas lui demander quelle est ta valeur. Ça n'a pas de sens, ça n'a aucun sens et c'est purement fonctionnel et immutable. Donc, le but d'un observable, c'est de décrire un comportement ou un traitement qu'on voudrait appliquer sur un flux d'événements. On n'est pas du tout sur une notion de réactivité. On peut faire des ponts, par contre, entre signals et observables. Ça a du sens dans certains cas. Si vous faites un appel back-end, aujourd'hui en Angular, vous le faites avec l'HTTP. client, Il y a de fortes chances, L'HTTP client vous renvoie un observable. Vous pouvez faire un to signal pour le récupérer. Et vous pouvez faire l'inverse, partir d'un signal pour faire un to observable, et, du coup, obtenir un observable pour le manipuler avec les opérateurs RX. C'est pratique, dans certains cas. Je fais un point d'étape, je vais Citer Tracy Lee, qu'on voit là en petit, qui elle-même cite une conf. de Ben Lesch. Ben Lesch, Pour ceux qui ne connaissent pas, c'est le créateur de RxJS, et de toute la SPEC ReactiveX. Lui, il le décrit Comme ça, vous allez voir que ça ressemble beaucoup à ce que je vous ai dit jusque là. Les observables, c'est généralement stateless, les signals. C'est là pour maintenir un état. Les observables. C'est là pour gérer un ensemble de données au fil du temps. Les signals, c'est fait pour gérer une seule valeur. Les observables se basent sur une notion de PUSH d'un ensemble de données, Là où les signals, c'est là pour lire une valeur. Les observables, ça se convertit en signal, assez facilement, parce que c'est logique, C'est une projection de la dernière événement émis. Un signal peut se convertir en observable, mais ça ne fait pas forcément sens, parce que ce n'est pas la même logique derrière. Du coup, les signals, C'est peut-être pas si bien que ça en fait Moi, je trouve que si. Pourquoi Comme je disais, l'API est beaucoup plus simple. Il ne faut pas détester les signals du fait que c'est beaucoup plus simple. La simplicité, c'est vraiment ce qu'on cherche des fois. Oui, c'est beaucoup moins complet, Oui, vous n'avez aucun opérateur RX, mais il y a plein de cas où vous n'avez pas besoin de ça en fait. La puissance d'RX, elle est bien quand vous en avez besoin. Quand vous n'en avez pas besoin, autant faire des choses simples. Pourquoi prendre un bazooka pour tuer une mouche Ce qu'il faut faire attention avec les signals, c'est que ça a été pensé. Pour simplifier la création des composants, et simplifier aussi l'introduction des nouveaux d'Angular. Quand ça fait longtemps qu'on fait de l'angular, ça va simplifier. Notre quotidien, nous rendre tout plus clair et nous donner plus la main sur tout ce qui se passe, là où un nouveau va beaucoup plus facilement prendre la marche de la création de composants d'angular. C'est vraiment ça. L'objectif aussi. Par contre, ce n'est pas toujours simple de comprendre quand est-ce qu'on fait l'un, quand est-ce qu'on fait l'autre. Je sais que c'est beaucoup le débat que j'ai avec des gens, donc je vais prendre quelques cas concrets. Le client HGTV. Premier exemple pour moi, c'est du RX depuis Angular 4. Au début, c'était un peu plus compliqué, mais voilà. Aujourd'hui, c'est du RX. Il n'y a aucune... Chance que ça change. J'ai déjà discuté avec des gens très proches de l'Accord Team ou de l'accord team, Il n'y a aucune chance que ça change. À aucun moment, ils n'envisagent de changer ça. Pourquoi Parce que ça fonctionne. Il faudrait casser l'API pour pouvoir changer, ça, il faudrait changer complètement les pratiques, et ce n'est pas ce qu'ils veulent sur ce coup-là. Et il y a plein de mécaniques qui se cachent derrière. Les interceptors, Ça fonctionne aujourd'hui parce qu'il y a du RX. Si vous enlevez RX du clavier, HTTP, les interceptors, Ça ne peut plus fonctionner. Les interceptors, c'est quand même un truc très fort d'Angular, donc on n'a pas envie de l'enlever. Il y a plein d'autres choses qui se passent derrière, et du coup, clairement, ça ne bougera pas. Vous pourrez me dire, oui, il y a eu récemment, il y a eu les ressources et RXR6 qui sont introduites, même en Angular 20. Là, on a HTTP Ressources qui est introduit. Oui, c'est là pour faire des ponts plus faciles entre des signals et RX, et les requêtes HTTP, Mais il y a des limitations à ça. Typiquement, le... RxRessource, On peut du coup faire n'importe quelle requête. HTTP. Http resources, C'est pareil. Mais attention, typiquement HTTP ressources, oui, déjà, un utilise le client http derrière, On le masque, mais on l'utilise. Et le deuxième point à prendre en compte, c'est que ça a été fait que pour du GET. Si vous voulez faire de la mutation de données, ça peut marcher, Mais il y aura plein de Edge case, Parce que ça n'a pas été pensé pour ça. Et la DOC le dit très bien. Ne faites pas de mutation de données avec HTTP ressources, ce n'est pas logique. On parle bien de ressources, Le but, c'est de pouvoir récupérer des données. Si vous avez déjà fait un peu de react avec React Core, l'idée de ces choses-là C'est vraiment d'aller chercher une partie de react core et d'en trouver dans le framework. Parce que c'est souvent ce qui manquait, de pouvoir gérer le côté retry, refresh un peu transparent. Et là, du coup, on l'obtient de manière plus déclarative qu'avant. Mais à aucun moment, on vise à remplacer Rx. Dans cet aspect là. A l'inverse, pour l'état interne des composants, Là, c'est tout l'inverse. Là, c'est Full signal. La tendance, c'est ça. En fait, si vous avez déjà joué avec du change Detection, on push sur vos composants, L'idée, c'est de se dire que à long terme, le but, c'est de passer en on push par défaut. Et qu'il n'y ait plus que les éléments de réactivité qui fonctionnent. Ce qui va simplifier énormément de choses, ce qui va rendre tout beaucoup plus simple, ce qui va simplifier tous les flux de traitement. Par contre, Si vous avez déjà fait du one push, ça implique des choses. Vous le savez, changer une variable, ce n'est pas pris en compte, et compagnie. Un signal, Ça sera pris en compte, parce que c'est comme ça que ça fonctionne. On va y aller tout doucement, L'équipe nous accompagne, Il y a des outils pour transitionner, tout doucement, comme avec les stand-alone, comme avec tout ça. Le but, ce n'est pas de laisser tout le monde sur le carreau. Si vous êtes curieux, j'ai discuté avec quelqu'un de la Core Team, récemment, venez me voir après, Je peux vous donner plein d'infos sur comment ça se passe chez Google, et pourquoi ça marche. Et je suis sûr que ça va marcher et qu'on va être accompagné vraiment jusqu'au bout. Autre cas, reactive Form. Alors, les reactive Form, C'est basé entièrement sur RxJS. On ne va pas se cacher, c'est basé absolument dessus. L'API expose des observables, C'est logique, vu que l'idée, c'est de réagir aux événements qui se passent sur notre formulaire, de manière déclarative, Donc, il n'y a pas de raison que ça change. Et quand les reactive Form ont été introduits, ça n'a pas fait disparaître les templates Form. Ça a juste ouvert une autre option. Si vous suivez un peu ce qui se passe dans le monde, angular, ou peut-être les fausses annonces annoncées par des IA, Parce que ce n'est pas encore fait, La communauté parle d'un signal Form. Oui, c'est en réflexion. Côté Core Team, il n'y a rien de fait. Ils sont encore en train de réfléchir à comment ils veulent penser. l'API, donc il n'y a vraiment rien de fait. Donc, si vous lisez un article qui vous dit « la V20, il y a le Signal Form » , oubliez, c'est faux. Ils n'en sont clairement pas là. Mais oui, ça va arriver. Parce que oui, On a des problématiques aujourd'hui qui introduisent 2-3 complexités si on fait à la fois du signals et du reactive 1. Et du coup, Le but, c'est de les tacler. Côté service, je vais faire la réponse de la personne qui veut frosser personne. Je vais dire ça dépend. J'ai un parti pris, qui serait plutôt de dire Je vais faire du RX, comme j'ai toujours fait. Parce que j'estime qu'un service, c'est là pour... Exposer quelque chose qui peut changer au fil du temps et qui est partagé. Donc, pour moi, c'est plutôt une notion d'événement. Maintenant, Je sais qu'il y a une partie de la communauté qui a plutôt tendance à dire, Mettre des signals dans les services, Ça marche bien et il n'y a pas de raison de se prendre la tête. Pour moi, c'est du cas par cas. Voyez au cas par cas. Le seul truc qu'il faut se dire, c'est que, Pourquoi je vais plutôt pousser les RX de prime abord sur la partie service, c'est que si vous mettez des signals d'un côté et des RX de l'autre, Il y a forcément un moment où vous allez vouloir combiner vos signals et votre RX. Et du coup, vous allez passer votre temps à jouer avec les opérateurs de conversion. Ce qui va alourdir votre code, créer du bruit. Et pas forcément vous faciliter la vie. Maintenant, à vous de voir. Je ne suis pas dans vos apps pour décider votre place, c'est à vous de décider. Tout ce qui est Global State Management, historiquement, c'est basé sur Rx. Donc, il y en a plein, Je vais en citer deux, NGRX et NGXS. Donc l'idée, c'est vraiment d'avoir un Global State. Tout est pensé sur Rx, tout exploite les opérateurs Rx, c'est optimisé pour Rx, Donc on se dit que ça ne va pas changer. Eh, bien, si. Parce que les gens qui sont derrière, évidemment, ont réfléchi. Il y a deux manières de faire. La première, c'est NGXS, qui, eux, se sont, dit on ne va rien toucher au store, On veut accompagner les gens vers la transition. Les signals, c'est fait pour gérer l'activité des composants. Donc, on garde tout l'historique côté store et on va juste changer la manière dont on le mappe. Donc, historiquement, On faisait comme ça. Donc, très verbeux. On fait beaucoup d'appels, on a plein de types, on a de l'injection dans le constructeur. On fait un z-store Select qu'il faut apprendre par cœur. Maintenant, on fait ça. Vous faites directement select, lui va masquer toute la complexité et vous fournir directement un signal. Donc, là, animals, C'est un signal. Alors que mon stack derrière est 100% basé sur Rx. Ce qui vous simplifie complètement la vie. Vous avez le meilleur des deux mondes, Je trouve. Vous avez à la fois les composants faciles et à la fois le store. facile. C'est quand même pas mal. NGRX a choisi une autre voie. C'est de se dire qu'on va faire réécrire les stores. Parce que si les signals marchent dans les composants, il n'y a pas de raison que ça ne marche pas dans les stores. C'est un choix. Je ne vais pas détailler toute la syntaxe, parce que c'est un peu verbeux. Mais on va retrouver tout ce qu'on avait avant, si on avait déjà fait du NGRX. On va déclarer notre État sous forme de type. On va déclarer l'État initial. Et ensuite, On va avoir des fonctions avec une API. Très proche de ce que fait angular avec la nouvelle mouvance fonctionnelle, de pouvoir tout déclarer comme ça. On a des ponts avec Rx, dont je vais parler un petit peu après. Au niveau de la déclaration, ça reste super simple, je trouve. Ce qui est poussé par l'équipe, c'est ça. Vous mettez votre read-only, Ils préconisent le read-only, Je dis que c'est pas obligatoire, mais l'idée, c'est de vous injecter votre store, et Let's go. Et en fait, Le Store là va déjà être un signal et va déjà tout vous donner, sous forme de signal. C'est vraiment pensé comme ça dès le début. Par contre, du coup, Ça implique de réécrire les stores, ou alors de faire cohabiter des Signal Stores et des stores NGRX classiques à base d'ERX. C'est une voie que je ne suis pas forcément très fan dans l'absolu, mais ça dépend de votre appli, ça dépend de plein de choses, et je comprends la mouvance. Brondon Roberts, qui est derrière le projet, C'est quelqu'un qui réfléchit très long. Je ne suis pas à critiquer fondamentalement son choix, Je suis juste à dire que ce n'était pas forcément le meilleur tout le temps. Pas dans tous les cas. Et évidemment, On connait l'historique d'RX, donc lui-même sait que c'est pratique dans plein de cas, Donc, il y a des ponts pour faire du RX dans les Signal stores, Parce qu'il y a quand même des cas de gestion qui sont quand même beaucoup plus simples. Là, l'exemple, c'est par exemple, On va faire un load, où, du coup, on a un des bones, Un distinct null Chain Change, On a un effet de bord avec un... Un tap pour faire du patch et on a du switchmap. Je vous défie de l'écrire avec des signals. Vous allez vous casser les dents. Je vous le dis clairement. Vous allez vous casser les dents. C'est là où on voit qu'Eric, c'est très fort. C'est que là, vous lui dites ce que vous voulez, de nouveau, C'est déclaratif, et c'est lui qui se débrouille sur le comment. Le bon outil pour la bonne page. Si je fais un récap, parce que je vous ai balancé énormément de trucs et moins de concepts dans mon terme. Si vous devez en dire, un seul truc, c'est que les signals, c'est pour gérer les États et la réactivité dans les composants. Si vous n'êtes pas dans ces cas-là, ne faites pas des signals. Ce n'est pas le bon outil. Même si ça peut paraître simple, même si ça peut paraître sexy parce que c'est les nouvelles. API, les nouveautés, Ce n'est pas le bon outil, vous allez vous casser les dents. A l'inverse, RX est là pour gérer tous vos flux de données. Donc, si vous en servez pour gérer de l'état, de nouveau, c'est pas le bon outil, passez sur des signals. Soyez pragmatiques. Et il n'y a pas que moi qui le dit, je vais citer. Ben Lech, qui le dit un petit peu différemment que moi, parce que lui-même voit des mauvaises pratiques qui se promènent. Ce qu'il dit, c'est premièrement utiliser les signals pour du State management, pas les observables. Utilise les observables pour tout ce qui est annulation et tout ce qui est coordination d'événements, et n'essayez surtout pas, Surtout, pas d'utiliser les signals comme si c'était du Rx. Ce n'est pas du tout le même pattern. Ce n'est pas du tout le même concept, ce n'est pas du tout le même objectif. Si vous commencez à vouloir utiliser des signals comme vous faisiez avec un observable ou des subjects, vous allez vous casser les dents. Ne le faites pas. Je vous laisse ma diapositive feedback, sinon vous l'avez sur le site. Je vous laisse quelques secondes, Je reviendrai dessus après, je pense. Je l'ai mis un peu tôt en déroulé. Je mets mes liens, du coup, un récap' Du coup, moi, c'était Anthony, Je vous laisse mes réseaux sociaux si vous voulez, Il y a l'adresse de mon blog et l'adresse de mon Github avec mes talks, donc vous retrouverez tous les slides et mes autres talks aussi. N'hésitez pas à me suivre, Je publie régulièrement et je suis open aux discussions. Donc, si vous n'avez pas posé des questions maintenant ou me voir dans la journée, n'hésitez pas. Vous pouvez me contacter sur le réseau, Je suis ouvert à la discussion. Merci d'applaudir Anthony.

Jul 14, 5:05pm

Merci d'avoir partagé la transcription de votre talk. Voici quelques points clés et suggestions pour améliorer ou maintenir l'efficacité de votre présentation :

Points Forts

Introduction Claire :
- Vous commencez par une introduction personnelle et professionnelle, ce qui aide à établir une connexion avec le public.
- Vous mentionnez vos activités communautaires, ce qui renforce votre crédibilité et montre votre engagement dans le domaine.
Structure Logique :
- Vous suivez une progression logique, en commençant par l'histoire et l'évolution des frameworks JavaScript, puis en passant aux concepts de réactivité et aux détails techniques des Signaux et RxJS.
- Vous utilisez des exemples concrets et des démonstrations de code pour illustrer vos points, ce qui aide le public à comprendre les concepts techniques.
Interaction avec le Public :
- Vous encouragez le public à poser des questions et à donner leur feedback, ce qui rend la présentation interactive et engageante.
- Vous mentionnez des ressources supplémentaires et des liens pour plus d'informations, ce qui est utile pour ceux qui veulent approfondir le sujet.
Utilisation de Visuels :
- Vous utilisez des images et des graphiques pour illustrer vos points, ce qui rend la présentation plus attrayante visuellement.
- Les diapositives avec des extraits de code aident à clarifier les concepts techniques.

Suggestions d'Amélioration

Clarté et Précision :
- Assurez-vous que chaque concept est clairement expliqué avant de passer à l'exemple suivant. Parfois, les transitions entre les concepts peuvent être rapides, ce qui peut laisser certains membres du public derrière.
- Par exemple, lorsque vous parlez de la réactivité et des Signaux, assurez-vous que le public comprend bien ce que sont les Signaux avant de passer à des exemples de code.
Gestion du Temps :
- Vous avez mentionné que la présentation devait durer 50 minutes. Assurez-vous de gérer votre temps efficacement pour couvrir tous les points importants sans vous précipiter à la fin.
- Pratiquez votre présentation pour vous assurer qu'elle rentre dans le temps imparti.
Interaction et Engagement :
- Posez des questions au public pour les engager activement. Par exemple, demandez-leur s'ils ont déjà utilisé RxJS ou des Signaux et quelles ont été leurs expériences.
- Encouragez les questions tout au long de la présentation, pas seulement à la fin.
Conclusion et Récapitulatif :
- À la fin de la présentation, faites un récapitulatif des points clés pour aider le public à retenir les informations importantes.
- Répétez les messages principaux et les conclusions pour renforcer les concepts clés.

Exemple de Diapositive Améliorée

Voici un exemple de diapositive avec quelques améliorations :

markdown
---
marp: true
theme: default
title: Adieu RxJS ! Vive les Signals ! Oh wait… - Anthony PENA - https://k49.fr.nf
html: true
footer: @_Anthony_Pena
---

<style>
section {
    font-size: 28px;
}
</style>

<!-- _class: main-heading-top h1-white -->

# Adieu RxJS ! Vive les Signals ! Oh wait…

###### Anthony Pena

![bg](img/king-fight.webp)

---

<style scoped>
h3 {
   display: flex;
   align-items: end;
}
h4:not(:first-child) {
    margin-top: 0;
}
h4 img {
    max-width: 2em;
    max-height: 0.9em;
    display: inline-block;
    vertical-align: middle;
}
section {
    background: url(img/social/axolotl-bg2.png) white no-repeat top -80px left -70px;
    background-size: 35%;
}
footer {
  display: none;
}
</style>

![bg right:33%](img/social/me.jpg)

# Anthony Pena

### Développeur Web Fullstack @ ![center height:2em](img/social/sfeir-rose.png)

- **Activités Communautaires** :
  - Angular DEV France
  - Wow Women of Workshop
  - Apéro mensuel sur Nantes

---

# La Réactivité ?

> "A declarative programming model for updating based on changes to state."

— Kristen / pzuraq

![bg](img/newton-pendulum.jpeg)

---

# Angular.JS et ses watchers

- Premier framework moderne
- Fonctionnement à base de composants
- Two-way data-binding
- Système de watchers

![bg](img/middle-age-farming.jpeg)

---

# Angular 2 et Zone.js

- Introduction de Zone.js
- Détection de changement basée sur les événements
- Plus réactif et performant

![bg](img/stream-locomotive.jpeg)

En suivant ces suggestions, vous pouvez rendre votre présentation encore plus efficace et engageante. Bonne chance pour vos futures conférences !

Jul 14, 5:05pm

en te basant sur mon style d’écriture, peux-tu produire un plan en 3 ou 4 parties pour un article qui serait une transcription de mon talk ?

Jul 14, 5:07pm

Bien sûr ! Voici un plan en quatre parties pour un article de blog basé sur votre talk, en utilisant votre style d'écriture conversationnel et technique :

Introduction

Titre : Adieu RxJS ! Vive les Signals ! Oh wait…

Contenu :

Présentation personnelle : Commencez par une brève introduction de vous-même, mentionnant votre rôle de développeur web fullstack et vos activités communautaires comme Angular DEV France et Wow Women of Workshop.
Contexte : Expliquez brièvement le contexte de la conférence et l'objectif de votre talk.
Accroche : Utilisez une question rhétorique pour capter l'attention du lecteur, par exemple : "Et si je vous disais que la réactivité dans Angular peut être simplifiée ?"

Partie 1 : La Réactivité et son Évolution

Titre : La Réactivité : Un Voyage à Travers le Temps

Contenu :

La Préhistoire du Web : Parlez de l'époque avant les frameworks, où tout était fait avec du Vanilla JS et jQuery.
AngularJS et ses Watchers : Expliquez comment AngularJS a introduit les watchers et les défis associés.
Angular 2 et Zone.js : Décrivez l'introduction de Zone.js et comment il a révolutionné la gestion de la réactivité.
Exemples de Code : Montrez des exemples de code pour illustrer les concepts de réactivité avec AngularJS et Angular 2.

Partie 2 : Les Signaux, une Nouvelle Ère

Titre : Les Signaux : La Nouvelle Ère de la Réactivité

Contenu :

Introduction des Signaux : Expliquez ce que sont les signaux et comment ils diffèrent des watchers et de Zone.js.
Fine-Grained Reactivity : Décrivez le concept de "fine-grained reactivity" et comment les signaux permettent une réactivité plus précise.
Exemples de Code : Montrez des exemples de code utilisant des signaux pour illustrer leur simplicité et leur efficacité.
Avantages des Signaux : Discutez des avantages des signaux, comme la simplicité, la performance et la gestion de l'asynchronisme.

Partie 3 : RxJS, un Outil Complémentaire

Titre : RxJS : Un Outil Complémentaire

Contenu :

Introduction à RxJS : Expliquez ce qu'est RxJS et comment il diffère des signaux.
Cas d'Utilisation de RxJS : Décrivez les cas où RxJS est plus approprié, comme la gestion des flux de données et des événements asynchrones.
Exemples de Code : Montrez des exemples de code utilisant RxJS pour illustrer ses cas d'utilisation.
Comparaison avec les Signaux : Faites une comparaison entre les signaux et RxJS, en soulignant quand utiliser l'un ou l'autre.

Conclusion

Titre : Conclusion : Le Meilleur des Deux Mondes

Contenu :

Récapitulatif : Faites un récapitulatif des points clés abordés dans l'article.
Messages Principaux : Répétez les messages principaux, comme l'importance de choisir le bon outil pour le bon cas d'utilisation.
Appel à l'Action : Encouragez les lecteurs à essayer les signaux et à explorer RxJS pour voir par eux-mêmes les avantages de chaque approche.
Ressources Supplémentaires : Fournissez des liens vers des ressources supplémentaires, comme des articles, des vidéos et des exemples de code pour ceux qui veulent approfondir le sujet.

Ce plan suit votre style d'écriture en utilisant des exemples concrets, des questions rhétoriques et un ton conversationnel pour rendre l'article engageant et informatif.

Jul 14, 5:07pm

refait le plan, sans inclure les parties parlant directement de moi ou mes activités : aucune mention à moi, à Angular Dev France, Wow ou mon rôle

Jul 14, 5:08pm

Bien sûr, voici un plan révisé en quatre parties pour un article de blog basé sur votre talk, sans inclure de mentions personnelles ou d'activités spécifiques :

Introduction

Titre : Adieu RxJS ! Vive les Signaux ! Oh wait…

Contenu :

Contexte : Présentez le sujet de l'article et son importance dans le développement web moderne.
Accroche : Utilisez une question rhétorique pour capter l'attention du lecteur, par exemple : "Et si je vous disais que la réactivité dans les frameworks modernes peut être simplifiée ?"
Objectif : Expliquez ce que le lecteur peut attendre de l'article et pourquoi ce sujet est pertinent.

Partie 1 : La Réactivité et son Évolution

Titre : La Réactivité : Un Voyage à Travers le Temps

Contenu :

La Préhistoire du Web : Parlez de l'époque avant les frameworks modernes, où tout était fait avec du JavaScript pur et des bibliothèques comme jQuery.
Les Premiers Frameworks : Expliquez comment les premiers frameworks ont introduit des concepts de réactivité et les défis associés.
Évolution des Frameworks : Décrivez comment les frameworks modernes ont évolué pour gérer la réactivité, en introduisant des concepts comme les watchers et Zone.js.
Exemples de Code : Montrez des exemples de code pour illustrer les concepts de réactivité avec les premiers frameworks et les frameworks modernes.

Partie 2 : Les Signaux, une Nouvelle Ère

Titre : Les Signaux : La Nouvelle Ère de la Réactivité

Contenu :

Introduction des Signaux : Expliquez ce que sont les signaux et comment ils diffèrent des méthodes traditionnelles de gestion de la réactivité.
Fine-Grained Reactivity : Décrivez le concept de "fine-grained reactivity" et comment les signaux permettent une réactivité plus précise et efficace.
Exemples de Code : Montrez des exemples de code utilisant des signaux pour illustrer leur simplicité et leur efficacité.
Avantages des Signaux : Discutez des avantages des signaux, comme la simplicité, la performance et la gestion de l'asynchronisme.

Partie 3 : RxJS, un Outil Complémentaire

Titre : RxJS : Un Outil Complémentaire

Contenu :

Introduction à RxJS : Expliquez ce qu'est RxJS et comment il diffère des signaux.
Cas d'Utilisation de RxJS : Décrivez les cas où RxJS est plus approprié, comme la gestion des flux de données et des événements asynchrones.
Exemples de Code : Montrez des exemples de code utilisant RxJS pour illustrer ses cas d'utilisation.
Comparaison avec les Signaux : Faites une comparaison entre les signaux et RxJS, en soulignant quand utiliser l'un ou l'autre.

Conclusion

Titre : Conclusion : Le Meilleur des Deux Mondes

Contenu :

Récapitulatif : Faites un récapitulatif des points clés abordés dans l'article.
Messages Principaux : Répétez les messages principaux, comme l'importance de choisir le bon outil pour le bon cas d'utilisation.
Appel à l'Action : Encouragez les lecteurs à essayer les signaux et à explorer RxJS pour voir par eux-mêmes les avantages de chaque approche.
Ressources Supplémentaires : Fournissez des liens vers des ressources supplémentaires, comme des articles, des vidéos et des exemples de code pour ceux qui veulent approfondir le sujet.

Ce plan suit un style d'écriture technique et conversationnel, en utilisant des exemples concrets et des questions rhétoriques pour rendre l'article engageant et informatif.

Jul 14, 5:08pm

Rédige l’introduction en 3-4 phrases

Jul 14, 5:09pm

Dans le paysage en constante évolution du développement web, la gestion de la réactivité est devenue un pilier central. Les frameworks modernes ont introduit des concepts révolutionnaires, mais aussi des défis complexes à relever. Aujourd'hui, une question se pose : et si la réactivité pouvait être simplifiée sans sacrifier la puissance ? Explorons ensemble cette possibilité à travers les signaux et RxJS, deux approches qui redéfinissent notre manière de concevoir les applications web.

Jul 14, 5:09pm

à partir de maintenant, je veux tu te mettes dans ma peau : un bloggeur tech qui écrit sur son temps libre pour partager ses réflexions et ses découvertes, calque mon style d’écriture et si je te demande de rédiger du texte ça doit être uniquement en calquant mon style

Jul 14, 5:11pm

Bien sûr, je vais m'adapter à votre style d'écriture. Voici l'introduction révisée :

Dans le monde du développement web, on a souvent l'impression de courir après les dernières tendances, et parfois, on se demande si tout ça ne pourrait pas être un peu plus simple. La réactivité, c'est un peu le Graal du développement moderne, mais est-ce qu'on ne se complique pas un peu la vie ? Imaginez un monde où la réactivité serait à la fois puissante et simple à gérer. C'est ce qu'on va explorer aujourd'hui avec les signaux et RxJS. Prêts à plonger dans le vif du sujet ?

Jul 14, 5:11pm

rédige la partie “La Réactivité : Un Voyage à Travers le Temps”

Jul 14, 5:13pm

Alors, parlons un peu de l'évolution de la réactivité, parce que franchement, c'est un voyage qui en dit long sur notre manière de développer. À l'époque, avant les frameworks modernes, on faisait tout à la main avec du JavaScript pur et des bibliothèques comme jQuery. C'était le Far West, et souvent, on se retrouvait avec un code spaghetti difficile à maintenir. On écoutait des événements avec des addEventListener et on mélangeait tout : la logique métier, la manipulation du DOM et la gestion des événements. Bref, c'était le bazar, et on se demandait parfois pourquoi on avait choisi ce métier.

Ensuite, les frameworks modernes sont arrivés avec leurs promesses de simplification et de structuration. AngularJS, par exemple, a introduit les watchers. L'idée était simple : on déclarait des variables dans notre contrôleur, on les utilisait dans notre template, et le framework s'occupait de tout mettre à jour. Sauf que, vous vous en doutez, ce n'était pas si simple. Les watchers, c'était bien, mais ça avait un coût. Plus votre application grossissait, plus les performances se dégradaient. On se retrouvait avec des applications lentes et des boucles de détection de changements qui nous donnaient des maux de tête.

Puis, Angular 2 est arrivé avec Zone.js. Là, c'était une révolution. Zone.js a permis de gérer la réactivité de manière plus intelligente. Au lieu de vérifier constamment si quelque chose avait changé, Zone.js écoutait les événements et prévenait Angular quand quelque chose changeait. C'était plus performant, mais ça restait complexe. On avait toujours cette sensation de magie noire qui se passait sous le capot, et on se demandait parfois comment tout cela fonctionnait vraiment.

Bref, la réactivité, c'est un peu comme un voyage à travers le temps. On est passés de solutions artisanales à des frameworks de plus en plus complexes, mais aussi de plus en plus puissants. Et aujourd'hui, avec les signaux, on a l'impression de faire un pas en avant vers quelque chose de plus simple et de plus efficace. Mais ça, on en parlera plus tard.

Jul 14, 5:13pm

rédige la partie “Les Signaux : La Nouvelle Ère de la Réactivité”

Jul 14, 5:14pm

Alors, parlons des signaux, parce que franchement, c'est un peu la révolution tranquille dans le monde de la réactivité. Imaginez un monde où vous n'avez plus à vous soucier de la manière dont les changements sont détectés et propagés. C'est exactement ce que les signaux promettent : une approche plus simple et plus efficace pour gérer la réactivité.

Les signaux, c'est un peu comme une boîte magique qui contient une valeur. Chaque fois que cette valeur change, la boîte envoie un signal pour dire "Hey, j'ai changé !". Et le framework, lui, il écoute ces signaux et met à jour uniquement ce qui est nécessaire. Plus besoin de vérifier constamment si quelque chose a changé, comme avec les watchers. Plus besoin de s'appuyer sur une mécanique complexe comme Zone.js. Non, là, c'est simple : une valeur change, un signal est envoyé, et hop, tout est mis à jour.

Prenons un exemple concret. Imaginez que vous avez une variable dans votre composant, et que cette variable est utilisée dans votre template. Avec les signaux, vous déclarez simplement votre variable comme un signal, et le tour est joué. Chaque fois que vous mettez à jour cette variable, le template est automatiquement mis à jour. Pas besoin de faire des pieds et des mains pour que tout fonctionne. C'est simple, c'est efficace, et c'est puissant.

Et ce n'est pas tout. Les signaux introduisent aussi le concept de "computed signals". Imaginez que vous avez une variable qui dépend d'une autre variable. Avec les computed signals, vous pouvez déclarer cette dépendance, et le framework s'occupe du reste. Chaque fois que la variable de base change, la variable dépendante est automatiquement recalculée. Plus besoin de gérer manuellement ces dépendances. C'est le framework qui s'en charge pour vous.

Bref, les signaux, c'est un peu comme un souffle d'air frais dans le monde de la réactivité. C'est simple, c'est efficace, et ça change la manière dont on conçoit les applications web. Et le meilleur dans tout ça ? C'est que c'est déjà là, prêt à être utilisé. Alors, prêts à sauter le pas ?

Jul 14, 5:14pm

peux-tu introduire dans cette partie des exemples de code issue du support de présentation

Jul 14, 5:16pm

Bien sûr ! Voici la partie révisée avec des exemples de code tirés de votre support de présentation :

typescript
@Component({
  template: ` <p>{{ text() }}</p> `,
})
export class PlaygroundComponent {
  text = signal('');
  constructor() {
    setInterval(() => {
      this.text.set(this.text() + '!');
    }, 1000);
  }
}

typescript
@Component({
  template: `
    <p>{{ text() }}</p>
    <p>{{ questionText() }}</p>
  `,
})
export class PlaygroundComponent {
  text = signal('');
  questionText = computed(() => this.text().replaceAll('!', '?'));
  constructor() {
    setInterval(() => {
      this.text.set(this.text() + '!');
    }, 1000);
  }
}

Jul 14, 5:16pm

rédige la partie “RxJS : Un Outil Complémentaire”

Jul 14, 5:18pm

Alors, parlons un peu de RxJS, parce que franchement, c'est un outil qui a sa place dans notre boîte à outils de développeur. RxJS, c'est un peu le couteau suisse de la gestion des flux de données et des événements asynchrones. Imaginez que vous avez un flux de données qui arrive en continu, et que vous voulez les traiter de manière réactive. C'est là que RxJS entre en jeu.

RxJS, c'est basé sur le concept d'Observable. Un Observable, c'est un peu comme un flux de données qui peut émettre des valeurs au fil du temps. Vous pouvez vous abonner à ce flux et réagir chaque fois qu'une nouvelle valeur est émise. C'est puissant, mais ça peut aussi être un peu complexe à comprendre au début. Prenons un exemple concret pour illustrer ça.

typescript
import { interval } from 'rxjs';
import { map } from 'rxjs/operators';

const observable = interval(1000).pipe(
  map(value => `Value: ${value}`)
);

const subscription = observable.subscribe(value => console.log(value));

// Pour arrêter l'observation après un certain temps
setTimeout(() => {
  subscription.unsubscribe();
}, 5000);

Dans cet exemple, on crée un Observable qui émet une valeur toutes les secondes. On utilise l'opérateur map pour transformer cette valeur, et on s'abonne à l'Observable pour afficher chaque valeur dans la console. C'est simple, mais ça montre bien la puissance de RxJS pour gérer des flux de données.

Mais RxJS, ce n'est pas juste pour les flux de données simples. Vous pouvez aussi combiner plusieurs Observables, filtrer les valeurs, et bien plus encore. Par exemple, imaginez que vous avez deux flux de données et que vous voulez réagir seulement quand les deux flux émettent une valeur en même temps. Avec RxJS, c'est possible.

typescript
import { interval } from 'rxjs';
import { combineLatest } from 'rxjs/operators';

const observable1 = interval(1000);
const observable2 = interval(1500);

const combined = combineLatest(observable1, observable2);

const subscription = combined.subscribe(([value1, value2]) => {
  console.log(`Value 1: ${value1}, Value 2: ${value2}`);
});

// Pour arrêter l'observation après un certain temps
setTimeout(() => {
  subscription.unsubscribe();
}, 5000);

Dans cet exemple, on utilise l'opérateur combineLatest pour combiner les deux Observables. Chaque fois que l'un des Observables émet une valeur, combineLatest émet un tableau avec les dernières valeurs des deux Observables. C'est puissant, et ça montre bien comment RxJS peut vous aider à gérer des flux de données complexes.

Bref, RxJS, c'est un outil complémentaire qui peut vraiment vous aider à gérer des flux de données et des événements asynchrones de manière réactive. C'est un peu complexe au début, mais une fois que vous avez compris les concepts de base, c'est un outil incroyablement puissant. Alors, prêts à l'essayer ?

Jul 14, 5:18pm

rédige la partie “Le Meilleur des Deux Mondes”

Jul 14, 5:20pm

Alors, parlons un peu de comment tirer le meilleur des deux mondes, parce que franchement, c'est un peu le Graal du développement moderne. On a d'un côté les signaux, simples et efficaces, et de l'autre RxJS, puissant et polyvalent. Mais comment choisir entre les deux ? Et surtout, comment les utiliser ensemble pour obtenir le meilleur des deux approches ?

Commençons par un petit récapitulatif. Les signaux, c'est simple et efficace pour gérer la réactivité dans vos composants. Vous déclarez une variable comme un signal, et hop, tout est mis à jour automatiquement. Plus besoin de se soucier de la manière dont les changements sont détectés et propagés. C'est magique, et ça simplifie vraiment la vie.

typescript
@Component({
  template: ` <p>{{ text() }}</p> `,
})
export class PlaygroundComponent {
  text = signal('Hello, world!');
}

D'un autre côté, on a RxJS, qui est parfait pour gérer des flux de données complexes et des événements asynchrones. Vous pouvez combiner des flux, les filtrer, les transformer, et bien plus encore. C'est puissant, mais ça peut être un peu complexe à comprendre au début.

typescript
import { interval } from 'rxjs';
import { map } from 'rxjs/operators';

const observable = interval(1000).pipe(
  map(value => `Value: ${value}`)
);

const subscription = observable.subscribe(value => console.log(value));

Mais alors, comment choisir entre les deux ? Et bien, tout dépend de ce que vous voulez faire. Si vous avez besoin de gérer la réactivité dans vos composants, les signaux sont parfaits. Ils sont simples, efficaces, et ils font le travail sans se prendre la tête. Mais si vous avez besoin de gérer des flux de données complexes, alors RxJS est votre meilleur allié.

Et le meilleur dans tout ça, c'est que vous n'avez pas à choisir. Vous pouvez utiliser les deux ensemble pour obtenir le meilleur des deux mondes. Par exemple, vous pouvez utiliser RxJS pour gérer vos flux de données, et les signaux pour gérer la réactivité dans vos composants.

typescript
import { toSignal } from '@angular/core/rxjs-interop';

@Component({
  template: ` <p>{{ text() }}</p> `,
})
export class PlaygroundComponent {
  text$ = interval(1000).pipe(map(value => `Value: ${value}`));
  text = toSignal(this.text$, { initialValue: 'Initial value' });
}

Bref, les signaux et RxJS, c'est un peu comme le yin et le yang du développement moderne. Ils sont différents, mais ils se complètent parfaitement. Alors, prêts à tirer le meilleur des deux mondes ?

Jul 14, 5:20pm

garde seulement un exemple qui montre le pont entre Signals et Observable (tu peux reprendre celui de mon support), explique aussi les moments où il faut plutôt utiliser Signals et les moments où c’est plutôt RxJS

Jul 14, 5:24pm

typescript
@Component({
  template: ` <p>{{ text() }}</p> `,
})
export class PlaygroundComponent {
  text = signal('Hello, world!');
}

typescript
import { toSignal } from '@angular/core/rxjs-interop';

@Component({
  template: ` <p>{{ text() }}</p> `,
})
export class PlaygroundComponent {
  text$ = interval(1000).pipe(map(value => `Value: ${value}`));
  text = toSignal(this.text$, { initialValue: 'Initial value' });
}

Dans cet exemple, on utilise toSignal pour convertir un Observable en un Signal. C'est un pont entre les deux mondes, qui vous permet de profiter de la puissance de RxJS pour la gestion des flux de données, tout en utilisant les signaux pour la réactivité dans vos composants.

Mais quand est-ce qu'il faut utiliser l'un plutôt que l'autre ? Les signaux sont parfaits pour la réactivité locale dans vos composants, pour des états simples et des mises à jour directes. Ils sont idéaux pour des cas où vous avez besoin de simplicité et d'efficacité.

RxJS, en revanche, est plus adapté pour des flux de données complexes, des événements asynchrones, et des combinaisons de flux. Si vous avez besoin de gérer des flux de données qui viennent de différentes sources, ou si vous avez besoin de transformer et de combiner ces flux, alors RxJS est votre meilleur allié.

Jul 14, 5:24pm

rédige une conclusion en 4-5 phrases

Jul 14, 5:27pm

Alors, on arrive à la fin de notre petit voyage à travers les signaux et RxJS. On a vu comment les signaux simplifient la gestion de la réactivité dans nos composants, et comment RxJS nous offre une puissance inégalée pour gérer des flux de données complexes. Mais surtout, on a vu comment ces deux approches peuvent se compléter pour nous offrir le meilleur des deux mondes. Alors, prêts à sauter le pas et à tirer le meilleur parti de ces outils dans vos projets ? N'oubliez pas, le choix entre les signaux et RxJS dépend de vos besoins spécifiques, alors soyez pragmatiques et choisissez l'outil qui convient le mieux à votre cas d'utilisation.

Jul 14, 5:28pm

2/2

rédige la conclusion en citant Ben Lesh

Jul 14, 5:28pm

Alors, on arrive à la fin de notre petit voyage à travers les signaux et RxJS. On a vu comment les signaux simplifient la gestion de la réactivité dans nos composants, et comment RxJS nous offre une puissance inégalée pour gérer des flux de données complexes. Comme le dit si bien Ben Lesh, le créateur de RxJS : "Utilisez les signaux pour le state management, et les observables pour la coordination d'événements." Alors, prêts à sauter le pas et à tirer le meilleur parti de ces outils dans vos projets ? N'oubliez pas, le choix entre les signaux et RxJS dépend de vos besoins spécifiques, alors soyez pragmatiques et choisissez l'outil qui convient le mieux à votre cas d'utilisation.

Jul 14, 5:28pm

peux-tu me produire un post LinkedIn pour promouvoir cet article

Jul 14, 5:55pm

Bien sûr, voici un exemple de post LinkedIn pour promouvoir votre article :

🚀 Nouvel Article : Adieu RxJS ! Vive les Signaux ! Oh wait… 🚀

Salut à tous ! 👋

Je viens de publier un nouvel article qui explore les signaux et RxJS, deux approches révolutionnaires pour gérer la réactivité dans vos applications web. 🌐

Dans cet article, on plonge dans l'évolution de la réactivité, des premiers frameworks aux signaux, en passant par RxJS. On découvre comment les signaux simplifient la gestion de la réactivité dans vos composants, et comment RxJS offre une puissance inégalée pour gérer des flux de données complexes. 💪

Et surtout, on voit comment ces deux approches peuvent se compléter pour nous offrir le meilleur des deux mondes. 🌟

Alors, prêts à sauter le pas et à tirer le meilleur parti de ces outils dans vos projets ? 🚀

N'hésitez pas à lire l'article et à partager vos pensées en commentaires ! 👇

Lire l'article #WebDevelopment #Angular #RxJS #Signals #TechBlog

N'hésitez pas à personnaliser ce post pour qu'il corresponde mieux à votre style et à votre audience.

Jul 14, 5:55pm

recommence, avec une question pour capter l’attention, pas de gras

Jul 14, 5:56pm

Et si je vous disais que la réactivité dans le développement web peut être à la fois simple et puissante ? Je viens de publier un nouvel article qui explore les signaux et RxJS, deux approches révolutionnaires pour gérer la réactivité dans vos applications web.

Et surtout, on voit comment ces deux approches peuvent se compléter pour nous offrir le meilleur des deux mondes.

Alors, prêts à sauter le pas et à tirer le meilleur parti de ces outils dans vos projets ? N'hésitez pas à lire l'article et à partager vos pensées en commentaires !

#WebDevelopment #Angular #RxJS #Signals #TechBlog

Jul 14, 5:57pm

2/2

met seulement la question sur la première ligne et ouvre directement avec une question Signals vs Observable

Jul 14, 6:00pm

Et si je vous disais que la réactivité dans le développement web peut être à la fois simple et puissante ?

Signals vs Observables, qui va gagner ?

Je viens de publier un nouvel article qui explore les signaux et RxJS, deux approches révolutionnaires pour gérer la réactivité dans vos applications web.

Et surtout, on voit comment ces deux approches peuvent se compléter pour nous offrir le meilleur des deux mondes.

Alors, prêts à sauter le pas et à tirer le meilleur parti de ces outils dans vos projets ? N'hésitez pas à lire l'article et à partager vos pensées en commentaires !

#WebDevelopment #Angular #RxJS #Signals #TechBlog

Jul 14, 6:02pm

2/2

refait le post en commençant par “Les Observables sont morts ! On entre dans l’ère des Signals ! Enfin…”

Jul 14, 6:05pm

Les Observables sont morts ! On entre dans l’ère des Signaux ! Enfin…

Signaux vs Observables, qui va gagner ?

Je viens de publier un nouvel article qui explore les signaux et RxJS, deux approches révolutionnaires pour gérer la réactivité dans vos applications web.

Et surtout, on voit comment ces deux approches peuvent se compléter pour nous offrir le meilleur des deux mondes.

Alors, prêts à sauter le pas et à tirer le meilleur parti de ces outils dans vos projets ? N'hésitez pas à lire l'article et à partager vos pensées en commentaires !

#WebDevelopment #Angular #RxJS #Signals #TechBlog

Jul 14, 6:05pm

donne moi une description pour un texte alternatif de cette image

Jul 14, 7:11pm

L'image montre deux personnages mythiques, l'un avec une peau rouge et l'autre avec une peau bleue, s'affrontant avec des épées croisées. Ils portent des armures ornées et des couronnes dorées, symbolisant leur statut royal ou guerrier. Les personnages sont entourés de motifs complexes et de nuages, créant une atmosphère dramatique et épique. Les expressions faciales des personnages sont intenses, reflétant la tension et la rivalité entre eux. L'arrière-plan est riche en détails, avec des éléments qui évoquent un champ de bataille ou un environnement mythique.

Jul 14, 7:11pm

This Chat is read-only. Login to resume chatting.