Cas pratiques RxJS

Contexte : Deux flux doivent être exécutés l'un après l'autre. Le Problème : Les flux sont exécutés indépendamment sans contrôle d'ordre. Contraintes : Utiliser concat pour séquencer les Observables. Livrable attendu : Implémenter une concaténation garantissant l'exécution séquentielle des flux.

Contexte : Un flux est défini mais ne produit aucun résultat visible. Le Problème : Aucun subscribe n'est appelé. Code actuel : const stream = of(1,2,3); Livrable attendu : Ajouter la souscription appropriée afin de déclencher l'exécution du flux.

Contexte : Un flux doit s'arrêter après un certain nombre d'émissions. Le Problème : Le flux continue indéfiniment. Contraintes : Utiliser l'opérateur take. Livrable attendu : Implémenter un flux utilisant take pour limiter le nombre d'émissions.

Contexte : Une interface doit afficher un compteur incrémenté chaque seconde. Le Problème : Aucun mécanisme d'arrêt n'est prévu. Contraintes : Utiliser interval et subscription.unsubscribe(). Livrable attendu : Créer un Observable utilisant interval et implémenter un mécanisme permettant d'arrêter le flux après un certain nombre d'émissions.

Contexte : Vous développez une interface web qui doit réagir aux clics sur un bouton. Le Problème : La logique actuelle utilise des addEventListener dispersés sans structure claire de flux. Contraintes : Utiliser RxJS natif avec fromEvent. Aucun framework supplémentaire. Livrable attendu : Créer un Observable basé sur fromEvent pour écouter les clics d'un bouton et afficher un message dans la console à chaque événement.

Contexte : Une application doit traiter uniquement les nombres pairs d'un flux. Le Problème : Tous les éléments sont actuellement traités sans condition. Contraintes : Utiliser l'opérateur filter. Livrable attendu : Implémenter un Observable filtrant uniquement les valeurs paires avant affichage.

Contexte : Une application doit intégrer une promesse existante dans un flux RxJS. Le Problème : La promesse est utilisée séparément du système Observable. Contraintes : Utiliser l'opérateur from pour convertir la promesse. Livrable attendu : Transformer une promesse en Observable et traiter la réponse via subscribe.

Contexte : Une application reçoit un tableau de données statique. Le Problème : Les données sont traitées en dehors du paradigme réactif. Contraintes : Utiliser from pour convertir un tableau en Observable. Livrable attendu : Transformer le tableau en flux RxJS et traiter les éléments via subscribe.

Contexte : Une application reçoit une série de nombres et doit les transformer avant affichage. Le Problème : La transformation est actuellement faite en dehors du flux, rendant la logique moins lisible. Contraintes : Utiliser l'opérateur map de RxJS. Code actuel : of(1,2,3).subscribe(value => { console.log(value * 2); }); Livrable attendu : Refactoriser le flux afin d'utiliser l'opérateur map pour transformer les valeurs avant la souscription.

Contexte : Vous devez inspecter les valeurs d'un flux sans modifier les données. Le Problème : Les logs actuels sont mélangés à la logique métier. Contraintes : Utiliser l'opérateur tap. Livrable attendu : Ajouter un tap dans le pipeline afin de logger les valeurs sans altérer le flux.

Contexte : Une application crée plusieurs souscriptions sans les nettoyer. Le Problème : Des fuites mémoire apparaissent après navigation répétée. Code actuel : const sub = interval(1000).subscribe(console.log); Contraintes : Mettre en place un mécanisme de désinscription propre. Livrable attendu : Implémenter une stratégie de gestion des subscriptions permettant d'éviter toute fuite mémoire.

Contexte : Plusieurs composants consomment les mêmes données API. Le Problème : Chaque souscription déclenche un nouvel appel réseau. Contraintes : Utiliser shareReplay pour mutualiser le résultat. Livrable attendu : Implémenter un Observable partagé évitant les appels API redondants tout en conservant la valeur en cache.

Contexte : Une interface doit réagir à plusieurs sources d'événements (clics, scroll, clavier). Le Problème : Les événements sont gérés séparément, compliquant la logique globale. Contraintes : Utiliser l'opérateur merge. Livrable attendu : Combiner plusieurs Observables en un seul flux unifié permettant une gestion centralisée des événements.

Contexte : Une application doit effectuer deux appels API où le second dépend du résultat du premier. Le Problème : Les appels sont exécutés en parallèle, causant des incohérences. Contraintes : Utiliser concatMap pour forcer l'exécution séquentielle. Livrable attendu : Mettre en place un pipeline garantissant que le second appel s'exécute uniquement après le premier.

Contexte : Une application interroge une API distante via RxJS. Le Problème : En cas d'erreur réseau, le flux s'arrête définitivement. Contraintes : Utiliser catchError pour intercepter les erreurs sans casser le flux principal. Livrable attendu : Implémenter une gestion d'erreur permettant d'afficher un message et de continuer le flux sans interruption totale.

Contexte : Un flux doit continuer tant qu'une condition métier reste vraie. Le Problème : Le flux actuel continue indéfiniment. Contraintes : Utiliser takeWhile pour arrêter le flux dynamiquement. Livrable attendu : Implémenter un Observable qui s'arrête automatiquement lorsque la condition n'est plus remplie.

Contexte : Une application doit interroger une API toutes les 5 secondes. Le Problème : Le polling continue même lorsque l'utilisateur quitte la page. Contraintes : Utiliser interval, switchMap et takeUntil. Livrable attendu : Mettre en place un polling propre pouvant être arrêté via un Observable de destruction.

Contexte : Vous développez un champ de recherche qui déclenche un appel API à chaque saisie utilisateur. Le Problème : Chaque frappe déclenche une requête, saturant le backend et provoquant des réponses désynchronisées. Contraintes : Utiliser fromEvent, debounceTime, distinctUntilChanged et switchMap. Aucun framework supplémentaire. Livrable attendu : Construire un pipeline RxJS permettant de limiter les appels API via debounce, ignorer les valeurs identiques et annuler automatiquement les requêtes précédentes grâce à switchMap.

Contexte : Une application écoute des événements scroll très fréquents. Le Problème : Les événements sont trop nombreux et impactent les performances. Contraintes : Utiliser throttleTime pour limiter la fréquence d'émission. Livrable attendu : Implémenter un flux scroll optimisé réduisant la fréquence des traitements.

Contexte : Une application calcule un résultat basé sur deux champs de formulaire distincts. Le Problème : Les calculs sont déclenchés indépendamment et manquent de synchronisation. Contraintes : Utiliser combineLatest. Livrable attendu : Combiner deux flux d'entrée afin de produire dynamiquement un résultat basé sur leurs valeurs respectives.

Contexte : Une page doit charger plusieurs ressources indépendantes avant affichage. Le Problème : Si une requête échoue, l'ensemble du flux est interrompu. Contraintes : Utiliser forkJoin combiné à catchError local. Livrable attendu : Implémenter une composition permettant de récupérer les données disponibles même si certaines requêtes échouent.

Contexte : Une application métier nécessite un enchaînement d'étapes conditionnelles dépendantes. Le Problème : La logique actuelle est impérative et difficile à maintenir. Contraintes : Utiliser concatMap, filter et mergeMap selon les cas. Livrable attendu : Concevoir un workflow entièrement réactif permettant d'orchestrer dynamiquement plusieurs étapes conditionnelles dans un flux RxJS.

Contexte : Vous devez créer un système de state management léger sans utiliser Redux ou Zustand. Le Problème : Les composants doivent partager un état réactif centralisé. Contraintes : Utiliser BehaviorSubject et opérateurs RxJS natifs uniquement. Livrable attendu : Concevoir un mini store réactif basé sur BehaviorSubject permettant mise à jour, sélection et abonnement aux changements d'état.

Contexte : Plusieurs composants consomment des données API identiques à différents moments. Le Problème : Les appels redondants dégradent les performances et la cohérence des données. Contraintes : Utiliser shareReplay et implémenter une logique d'invalidation basée sur un flux externe. Livrable attendu : Mettre en place un Observable partagé avec cache interne et mécanisme d'invalidation dynamique contrôlé par un second flux.

Contexte : Une application SPA crée de nombreuses souscriptions lors de la navigation. Le Problème : Des Observables continuent d'émettre après destruction des composants. Contraintes : Implémenter un pattern takeUntil centralisé. Livrable attendu : Mettre en place une stratégie globale permettant d'annuler automatiquement les souscriptions lors de la destruction d'un composant.

Contexte : Une application nécessite un contrôle précis du timing d'exécution des flux. Le Problème : Les émissions actuelles ne respectent pas les contraintes temporelles métier. Contraintes : Utiliser les schedulers RxJS (asyncScheduler, queueScheduler). Livrable attendu : Mettre en place un pipeline utilisant un scheduler spécifique pour contrôler précisément le moment d'exécution des tâches.

Contexte : Une application doit regrouper des événements utilisateur rapides avant traitement. Le Problème : Chaque événement est traité individuellement, entraînant une surcharge. Contraintes : Utiliser buffer ou bufferWhen pour regrouper dynamiquement les événements. Livrable attendu : Concevoir un pipeline capable de collecter les événements sur une période donnée ou jusqu'à un déclencheur spécifique avant traitement.

Contexte : Une application critique dépend d'une API externe instable. Le Problème : Les erreurs réseau provoquent l'arrêt du flux sans tentative de récupération. Contraintes : Implémenter une stratégie de retry exponentiel avec retryWhen et delay. Livrable attendu : Concevoir un pipeline capable de retenter automatiquement les requêtes échouées avec backoff exponentiel et limite de tentatives.

Contexte : Vous développez une interface de recherche avancée avec filtres multiples et mise à jour en temps réel. Le Problème : Plusieurs flux asynchrones (saisie, filtres, pagination) déclenchent des appels API concurrents pouvant produire des résultats incohérents. Contraintes : Utiliser combineLatest, debounceTime, distinctUntilChanged et switchMap. Aucun framework supplémentaire. Livrable attendu : Concevoir un pipeline RxJS capable d'orchestrer proprement ces flux, d'annuler les requêtes obsolètes et de garantir que seuls les résultats les plus récents soient affichés.

Contexte : Une application doit empêcher l'utilisateur de déclencher plusieurs requêtes critiques simultanément. Le Problème : Les clics rapides génèrent des appels API parallèles non souhaités. Contraintes : Utiliser exhaustMap pour ignorer les nouvelles émissions tant qu'une requête est en cours. Livrable attendu : Implémenter un pipeline empêchant les appels concurrents et garantissant un traitement séquentiel sécurisé.