Design & Développement web - Le topic des canards qui mangent des cookies

[Dross]

Ouais, au final c'est ce que j'ai à peu près fait et ça a solutionné le bousin
C'est compliqué de vous exposer le problème, sachant que je ne peux poster le code et que je ne comprends pas moi-même où ça merde.

Là c'est vraiment une façon de coder dont je ne comprends pas l'intérêt, par rapport à des "simples" await/async.

async/await c'est très récent, et c'est utile que si tu veux rester en séquentiel, sinon t'est foutu faut utiliser les promises.

Converti tes observables en promises quand ce sont des taches ("un seul retour possible") c'est plus facile à manipuler et plus proche de la définition théorique. Si tu veux chaîner tes promises, utilise le then(). Si tu veux attendre tout le monde en même temps utilise le Promise.All(). Si tu veux chaîner après plusieurs appels, un Promise.All() suivi de then().

[Orhin]

Converti tes observables en promises quand ce sont des taches ("un seul retour possible") c'est plus facile à manipuler et plus proche de la définition théorique.

Boaf c'est pas vraiment beaucoup plus simple à manipuler :
- then() vs concatMap()
- Promise.all() vs forkJoin()
- catch() vs catchError()

Un gros avantage de rester full observable c'est que tes "taches", tu peux les injecter facilement dans des flux de données ou des traitements multi-étapes.

Un autre avantage est qu'un observable ça s'arrête en cours de route si besoin (unsubscribe, takeUntil, etc).
Du coup tu peux facilement annuler un appel WS du client Http Angular avant qu'il soit terminé.

Les promise de base ne le permettent pas.

[Dross]

Syntaxiquement, "then()" c'est bien plus explicite que "concatMap()".

De plus, comme dis, il restera le problème qu'un "observable" est en général utilisé comme stream d'events (qui est justement le domaine de RxJS), ce qui n'a aucuns sens dans le cas d'un appel REST. Au niveau modélisation ça tiens pas la route. (je sais que c'est un problème historique, mais bon, tant qu'à bien écrire les choses..).

[Orhin]

Syntaxiquement, "then()" c'est bien plus explicite que "concatMap()".

Pour un novice oui.
Pour un utilisateur expérimenté, pas plus que n'importe quel fonction avancée d'une library/framework (voir même pas mal de fonctionnalité de base du JS).

De plus, comme dis, il restera le problème qu'un "observable" est en général utilisé comme stream d'events (qui est justement le domaine de RxJS), ce qui n'a aucuns sens dans le cas d'un appel REST. Au niveau modélisation ça tiens pas la route.

Ça a sa place si par exemple l'appel WS te renvoie une valeur en cache avant de te renvoyer la valeur récupérée.
Ou si ta fonction fait polling avec des appels à intervalle régulier (d'ailleurs ça te permettra de switcher très facilement sur des websocket ou des notifications push sans changer toucher aux consommateurs de ta fonction).

Un autre avantage (que j'ai mis dans l'edit de mon post précédent) est la possibilité d'annuler simplement les requêtes.

[Dross]

Et un code utilisable par un novice est supérieur en qualité qu'un code qui ne l'est pas. Vous avez jamais de juniors/stagiaires chez vous ?

Sinon le WS c'est pas un appel REST, si je wrap ce genre de fonctionnalités (et équivalent) c'est certain que j'utiliserai un stream, mais alors il y a d'autres objets qui peuvent être plus intéressants que l'observable : le Subject, BehaviorSubject, etc.

De plus, si tu viens d'autres langages (comme le C#) garder une meilleure séparation entre les Taches (Task/Promise) et les Observables (Observable/Subject/BehaviorSubject) permet de moins perdre les gens : car rien qu'avec le type ils ont le comportement prévu. Ce qui n'est pas le cas si tu mélange tout et fait tout passer par l'Observable quel que soit le cas d'utilisation.

[Orhin]

Et un code utilisable par un novice est supérieur en qualité qu'un code qui ne l'est pas. Vous avez jamais de juniors/stagiaires chez vous ?

Je dirais plutôt qu'un code utilisable par un novice est qualité.
Mais ce n'est pas la seule.
Si ça se fait au détriment d'autres pratiques (maintenabilité, évolutivité, séparations des concepts, etc), c'est une question d'équilibre.

Puis bon, apprendre qu'un "concatMap" est équivalent à un "then", c'est pas la mer à boire.

Sinon le WS c'est pas un appel REST, si je wrap ce genre de fonctionnalités (et équivalent) c'est certain que j'utiliserai un stream

Sauf que ça veut dire que le consommateur de ton appel WS (un component par exemple) va devenir dépendant de l'implémentation interne de ton service.
Un observable te permet de fournir en quelque sorte une API unifiée pour toutes les données/actions asynchrones.

mais alors il y a d'autres objets qui peuvent être plus intéressants que l'observable : le Subject, BehaviorSubject, etc.

Alors déjà les Subject/BehaviourSubject héritent de l'observable.

Ensuite un subject ne change strictement rien vis à vis du consommateur, c'est un intérêt uniquement pour le producteur de la donnée.

De plus, si tu viens d'autres langages (comme le C#) garder une meilleure séparation entre les Taches (Task/Promise) et les Observables (Observable/Subject/BehaviorSubject) permet de moins perdre les gens : car rien qu'avec le type ils ont le comportement prévu. Ce qui n'est pas le cas si tu mélange tout et fait tout passer par l'Observable quel que soit le cas d'utilisation.

Tout dépend de ta façon de programmer.
Si tu design tes applications autour de boucles action => donnée, au contraire, utiliser des observables prend tout son sens.

Une grande force des observables vient des operator qui viennent avec.
Ça te permet d'implémenter pas mal de logiques complexes qui te prendraient 10 fois plus de ligne de code avec de simple promise.

[Dross]

Je dirais plutôt qu'un code utilisable par un novice est qualité.
Mais ce n'est pas la seule.
Si ça se fait au détriment d'autres pratiques (maintenabilité, évolutivité, séparations des concepts, etc), c'est une question d'équilibre.

Bien sûr, mais chaîner des promises (ce qu'on va faire 99.99% du temps) ne pose pas de soucis de ce coté là.

De l'autre coté, manipuler des observables pour tout les cas de figures ça signifie gérer les subscriptions dans certains cas (pour les désabonner en fin de cycle de vie) et pas dans d'autres. Question séparation des concepts c'est pas super.

Sauf que ça veut dire que le consommateur de ton appel WS (un component par exemple) va devenir dépendant de l'implémentation interne de ton service.
Un observable te permet de fournir en quelque sorte une API unifiée pour toutes les données/actions asynchrones.

Oui, mais tu devrai toujours isoler l'implémentation technique de la technologie, en ayant par exemple un data accès layer qui ne laisse pas sortir l'implémentation spécifique. Donc ce n'est pas un problème mais une bonne pratique d'encapsuler tout ça.

Alors déjà les Subject/BehaviourSubject héritent de l'observable.

Ensuite un subject ne change strictement rien vis à vis du consommateur, c'est un intérêt uniquement pour le producteur de la donnée.

Oui, c'est ce que je dis : quand tu as besoin d'un observable (stream), on utilise un observable ou un de ses dérivés (c'est adapté à ce cas d'utilisation).

Une grande force des observables vient des operator qui viennent avec.
Ça te permet d'implémenter pas mal de logiques complexes qui te prendraient 10 fois plus de ligne de code avec de simple promise.

Les seuls exemples qui me viennent sont dans le cas des streams (ce pour quoi c'est justement adapté), tu aurai des exemples de promises encapsulant des appels REST qui seraient 10x plus complexes à écrire qu'avec des observables ?

[Orhin]

Les seuls exemples qui me viennent sont dans le cas des streams (ce pour quoi c'est justement adapté), tu aurai des exemples de promises encapsulant des appels REST qui seraient 10x plus complexes à écrire qu'avec des observables ?

C'est pas tellement au niveau des appels en eux même mais de leur orchestration.
Genre faire un appel tous les X sec et si un appel dure plus de X, l'annuler et passer au suivant.
Mais d'ailleurs ça na rient de spécifique aux appels REST, c'est pour toute action asynchrone.

C'est juste que gérer ces action avec des observables permet de plus facilement utiliser les opérateurs directement.

[deathdigger]

async/await c'est très récent, et c'est utile que si tu veux rester en séquentiel, sinon t'est foutu faut utiliser les promises.

Converti tes observables en promises quand ce sont des taches ("un seul retour possible") c'est plus facile à manipuler et plus proche de la définition théorique. Si tu veux chaîner tes promises, utilise le then(). Si tu veux attendre tout le monde en même temps utilise le Promise.All(). Si tu veux chaîner après plusieurs appels, un Promise.All() suivi de then().

C'est effectivement du séquentiel dont j'avais besoin (faire plusieurs appels d'api, et une fois qu'ils sont tous réalisés et qu'ils ont répondu, en faire un dernier).
J'ai eu d'autres trucs à gérer, notamment faire du forkjoin, et putain, c'est pas clair pour moi. Je l'ai utilisé bêtement parce que c'est ce que je voulais faire, mais je ne comprends pas ce que je fais (et ça m'agace).

Je développe sur plusieurs langages (dont des trucs improbables), et je m'y retrouve à chaque fois, là, c'est quand même plus obscure. J'ai l'impression de subir le code plus qu'autre chose.

[Orhin]

"Forkjoin" fonctionne comme un "Promise.all()".
Ça te renvoie la dernière valeur émise par chaque observable en argument une fois qu'ils se sont terminés : https://rxjs.dev/api/index/function/forkJoin

[Awake]

Je ne connais pas cette lib mais forkJoin et concatMap semblent des termes bien compliqués pour faire des choses aussi simples.

[deathdigger]

Je ne connais pas cette lib mais forkJoin et concatMap semblent des termes bien compliqués pour faire des choses aussi simples.

En plus tu imbriques tout ça dans une pipe, narmol.
Ça peut vous paraître obvious pour ceux qui l'utilisent au quotidien, mais pour un développeur standard, c'est quand même sacrément abstrait.

[Hideo]

En plus tu imbriques tout ça dans une pipe, narmol.
Ça peut vous paraître obvious pour ceux qui l'utilisent au quotidien, mais pour un développeur standard, c'est quand même sacrément abstrait.

This.

Le premier contact avec RxJS est just WTF et les operateurs sont tous plus obscures les uns que les autres.
J'veux dire a partir du moment ou sans avoir un outil de visualisation de l'operateur je suis complètement paume c'est que c'est quand meme un peu chaud.
T'es quand meme souvent tente de faire un toPromise() et pis basta.

Je suis un dev back, j'avais jamais touche a Angular ca a bien pique.

C'est toujours pas mon cas mais c'est vrai qu'une fois metrise c'est vraiment puissant.
Par contre utilise un peu a la Zeub ca a l'air d'etre un gouffre niveau performance.

[MrBeaner]

Je ris tellement aux vidéos du Monsieur, ça m'a fait remarquer que je suis définitivement passé côté dev

Je suis moins sensible aux jokes PHP, parce que je touche pas, mais je sais qu'il y en a pas mal ici



https://www.youtube.com/watch?v=Of1X-MmvJZ4

[tenshu]

Je pensais qu'il allait faire les évolutions des critiques contre PHP quand il a mis la veste pour parler de Laravel. Mais non.

Du coup 80% de la vidéo tape à côté et reprend juste les bêlements qu'on lit partout et qui datent de php4.

[MrBeaner]

Je pense que c'est l'idée de la vidéo huhu

Mais mes préférées restent celles sur JS :

[Captain_Cowkill]

Oui, ce sont des parodies, pas de vraies critiques.

[Hideo]

Merci pour les videos, je me suis bien marre sur toute la serie

[Awake]

Github est down pour moi Je veux push et aller prendre un thé mais non

[gros_bidule]

D'après githubstatus oui, c'est en mode dégradé presque partout ^^

[Awake]

Du coup j'ai éteint le pc sans push mon boulot. Je me sens sale

[Orhin]

Et c'est là que ton DD crame cette nuit.

[gros_bidule]

Ha nan ha nan, git ce n'est pas un système de sauvegarde
Même si j'ai entendu plus d'une fois "pensez à commiter le soir avant de partir". Grumpffff...

[Orhin]

Certes, mais mieux vaut quand même 2 copies de ton code sur 2 machines distantes que juste en local.
Puis bon, la sauvegarde elle est généralement plutôt côté serveur.
Le backup des PC c'est quand même assez rare.

Du coup faut push dans tous les cas.

[Etheon]

Je sais pas si vous suivez régulièrement l'actualité des frameworks JS (Vous savez, le truc qui accueil un nouveau membre chaque matin), mais j'ai fait quelques tests sur Remix, et ben c'est super intéressant !
Alors le côté rigolo, c'est que c'est comme toujours, on fonctionne en cycle, les dernières années on a fait plein de trucs côté client (hype jamstack etc), et ça y est, on revient côté serveur !

Au delà de l'aspect performance qui va très certainement varié en fonction des situations, ya deux points qui me motive à creuser du côté de Remix:

* L'aspect data mutation, qui se base sur les formulaires HTML (Plus d'information sur leur article VS Next.js)
* Agnostique sur l'hébergement. Par rapport à Next qui est simple à host avec Vercel mais plus complexe avec d'autres, la pour le coup c'est un peu plus ouvert.

Le site officiel pour avoir plus d'info: https://remix.run

Je vais tester un peu plus dans les prochains jours mais de ce que j'ai vu, c'est cool !

J'ai aussi envie d'apprendre un peu Svelte et Sveltekit, mais bon les journées c'est 24h.

[Dross]

Ha nan ha nan, git ce n'est pas un système de sauvegarde
Même si j'ai entendu plus d'une fois "pensez à commiter le soir avant de partir". Grumpffff...

En effet, mais si tu commite, t'a déjà deux copies (ton PC + git) et en général ton repo a une stratégie de backup de son coté aussi.

[Awake]

Ha nan ha nan, git ce n'est pas un système de sauvegarde
Même si j'ai entendu plus d'une fois "pensez à commiter le soir avant de partir". Grumpffff...

Ouais, en théorie c'est vrai et sur un projet open source ou si on était plein de devs je ferais gaffe. Pour l'instant je suis le seul sur le projet et sur un repos privé donc bon... si la branche compile c'est bon

[gros_bidule]

En effet, mais si tu commite, t'a déjà deux copies (ton PC + git) et en général ton repo a une stratégie de backup de son coté aussi.

Oui et non. En effet, on "peut" techniquement utiliser Git comme système de sauvegarde, mais

- tu vas faire des commits qui n'ont pas de sens. Avant de merger ta branche (si tu fais des branches, ho purée je commence à imaginer des trucs dégueulasses ^^), tu vas devoir passer du temps à squasher des commits qui ne veulent rien dire, un meli-melo de "add authentication to canard endpoint" et de 36 "save du soir". Ou bien tu squash tout dans un seul commit. Ou bien tu squashes pas et tu rebase même pas, tu merges ce merdier direct ? Seuls les monstres feraient ça.

- ça ne sauvera pas tout : par exemple ce que tu as en stash. Ou tiens, avant de partir tu étais en train de résoudre un conflit, mais tu n'as pas finit, ta branche est donc dans un état qui ne permet pas de la pusher

Sur un projet crado ce n'est pas embêtant, mais sur un projet pro ou partagé ça devient chaud. Et faut pas que ça serve au patron pour dire que sisi, on a une solution de sauvegarde, vous voyez c'est git (t'as déjà essayé de pusher ta boite outlook sur git ? bah vala ^^)

[Dross]

Non c'est certain, et en général je pousse pour des petits comits réguliers de mon coté (donc la question ne se pose pas), mais j'ai déjà eu des gus qui on perdu des jours de travail aussi, donc bon. A un moment tu prends le moindre de deux maux.

[gros_bidule]

C'est quand triste de ne pas avoir ne serait-ce qu'un hdd externe pour les backups
Content de bosser pour une boite qui me donne les moyens de travailler comme un pro le pro que je suis.