"𝗧𝘂 𝗻𝗲 𝗰𝗼𝗺𝗽𝗿𝗲𝗻𝗱𝘀 𝘁𝗼𝘂𝗷𝗼𝘂𝗿𝘀 𝗽𝗮𝘀 𝗹𝗲𝘀 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗹𝗲𝘀 ?" 𝗖’𝗲𝘀𝘁 𝗻𝗼𝗿𝗺𝗮𝗹. 𝗢𝗻 𝘁𝗲 𝗹𝗲𝘀 𝗮 𝘀𝘂𝗿𝗲𝗺𝗲𝗻𝘁 𝗺𝗮𝗹 𝗲𝘅𝗽𝗹𝗶𝗾𝘂𝗲́𝘀. La première fois que j’ai croisé ce concept, j’ai bloqué. Pas parce que c’était trop complexe. Mais parce qu’on me l’expliquait comme si j’étais un robot. Alors j’ai cherché une image. Et j’ai compris qu’un Observable, c’est simplement… un ami qui te raconte une histoire. Il te parle, chapitre après chapitre (next), il te dit quand ça tourne mal (error)… et surtout, il te prévient quand il a fini (complete). Le problème ? On nous explique souvent ça avec des termes froids et abstraits. 👉 Résultat : tu copies-colles du code sans comprendre ce que tu fais. Voici une meilleure façon de voir les choses : 𝗨𝗻 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗹𝗲, 𝗰’𝗲𝘀𝘁 𝘂𝗻 𝗰𝗼𝗻𝘁𝗲𝘂𝗿. 𝗘𝘁 𝘁𝗼𝗶, 𝘁𝘂 𝗲𝘀 𝗹𝗲 𝗹𝗲𝗰𝘁𝗲𝘂𝗿 𝗾𝘂𝗶 𝘀’𝗮𝗯𝗼𝗻𝗻𝗲 𝗽𝗼𝘂𝗿 𝗲́𝗰𝗼𝘂𝘁𝗲𝗿. Et dans Angular, ce conteur s’appuie sur RxJS pour faire sa magie. RxJS, c’est la bibliothèque qui donne à Angular son pouvoir de réaction. Et ses Observables sont partout : → écouter un clic → générer des messages → transformer un appel réseau → fusionner plusieurs sources de données Tu gères aussi bien du réseau que l’UI, avec une logique propre, claire, testable. Bref, 𝗰’𝗲𝘀𝘁 𝗹𝗲 𝗳𝗼𝗻𝗱𝗲𝗺𝗲𝗻𝘁 𝗱𝗲 𝗹𝗮 𝗽𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗮𝘁𝗶𝗼𝗻 𝗿𝗲́𝗮𝗰𝘁𝗶𝘃𝗲. Alors oui, 𝗔𝗻𝗴𝘂𝗹𝗮𝗿 𝗮 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗶𝘁 𝗹𝗲𝘀 𝗦𝗶𝗴𝗻𝗮𝗹𝘀 dans ces dernières version. Et oui, ils sont puissants pour la gestion d’état synchrone dans les composants. Mais non, 𝗶𝗹𝘀 𝗻𝗲 𝗿𝗲𝗺𝗽𝗹𝗮𝗰𝗲𝗻𝘁 𝗽𝗮𝘀 𝗥𝘅𝗝𝗦. Signals et Observables sont 𝗰𝗼𝗺𝗽𝗹𝗲́𝗺𝗲𝗻𝘁𝗮𝗶𝗿𝗲𝘀. Les premiers simplifient l'état local, les seconds brillent dans la gestion des flux asynchrones complexes. Et la bonne nouvelle ? Tu peux même passer de l’un à l’autre avec toSignal() et toObservable(). À partir de 𝗷𝗲𝘂𝗱𝗶 𝗽𝗿𝗼𝗰𝗵𝗮𝗶𝗻, je lance une série de posts pour explorer les 𝗽𝗿𝗶𝗻𝗰𝗶𝗽𝗮𝘂𝘅 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗹𝗲𝘀 𝗥𝘅𝗝𝗦 à connaître quand on code avec Angular. 💬 𝗧𝘂 𝘃𝗲𝘂𝘅 𝗾𝘂𝗲 𝗷𝗲 𝗱𝗲́𝗰𝗼𝗿𝘁𝗶𝗾𝘂𝗲 𝘂𝗻 𝗼𝗽𝗲́𝗿𝗮𝘁𝗲𝘂𝗿 𝗽𝗿𝗲́𝗰𝗶𝘀 𝗼𝘂 𝘂𝗻 𝗰𝗮𝘀 𝗾𝘂𝗲 𝘁𝘂 𝗻𝗲 𝗰𝗼𝗺𝗽𝗿𝗲𝗻𝗱𝘀 𝗽𝗮𝘀 ? Propose-le en commentaire. Je l’intégrerai à la série. Tu vas voir que bien utilisé, RxJS, c’est pas si sorcier. C’est même… presque fun.