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

**raaaahman** · 13/02/2023, 19h56

Je ne connais pas bien l'atomique design, mais je ne pense pas que tu puisse l'implémenter avec Redux...

Attention à la doc de Redux, tu as deux parties différentes; Redux (core), et le Redux Toolkit (RTK), et aussi le RTK Query mais normalement c'est une sous partie du RTK...

Si tu veux comprendre ce que c'est et comment ça marche, il faut commencer par Redux (core) évidemment. Note que si c'est pour l'utiliser dans des applis qui utilisent React, tu peux le considérer comme une version avancée du hook useReducer, combiné à un Context (à une vache près).

**Awake** · 13/02/2023, 20h16

Merci pour les infos sur Redux, je comprend mieux.

Ça à l'air intéressant pour une app qui transforme beaucoup ses données elle même, un jeu mobile par exemple.

Par contre en regardant la doc officiel sur useReducer, il y a ce bout de code :

Code:

function reducer(state, action) {
  switch (action.type) {
    case 'incremented_age': {
      return {
        name: state.name,
        age: state.age + 1
      };
    }
    case 'changed_name': {
      return {
        name: action.nextName,
        age: state.age
      };
    }
  }
  throw Error('Unknown action: ' + action.type);
}

Je trouve ça vraiment pas super, on a une espèce de boîte noire qui gère toutes les actions avec leurs arguments au lieu d'avoir des vraies méthodes.

**Orhin** · 13/02/2023, 20h33

Envoyé par Awake

Ça à l'air intéressant pour une app qui transforme beaucoup ses données elle même, un jeu mobile par exemple.

Pas que, c'est aussi utile si t'as des actions globales à faire dans ton application.
Genre t'as un player vidéo dont le statut play/pause peut être interrompu par plein d'actions utilisateurs, ben c'est très pratique de mettre ça dans un store ou un contexte.

Envoyé par Awake

Par contre en regardant la doc officiel sur useReducer, il y a ce bout de code :

Code:

function reducer(state, action) {
  switch (action.type) {
    case 'incremented_age': {
      return {
        name: state.name,
        age: state.age + 1
      };
    }
    case 'changed_name': {
      return {
        name: action.nextName,
        age: state.age
      };
    }
  }
  throw Error('Unknown action: ' + action.type);
}

Je trouve ça vraiment pas super, on a une espèce de boîte noire qui gère toutes les actions avec leurs arguments au lieu d'avoir des vraies méthodes.

Alors le côté "boite noire", ça vient un peu avec le système pour le coup.
Mais rien ne t'empêche d'avoir des fonctions appelées dans les différents case de ton switch.

D'ailleurs, faut pas croire que c'est fouillis pour autant.
Si t'es actions sont bien typées, alors dans chaque case le compilo typescript aura les bons types pour les arguments/payload de tes actions.

Un autre avantage que j'ai pas précisé, c'est que c'est très facile de faire des tests unitaires pour ce genre de reducer.

**Sangoon** · 13/02/2023, 20h40

Envoyé par Awake

Merci pour les infos sur Redux, je comprend mieux.

Ça à l'air intéressant pour une app qui transforme beaucoup ses données elle même, un jeu mobile par exemple.

Par contre en regardant la doc officiel sur useReducer, il y a ce bout de code :

Code:

function reducer(state, action) {
  switch (action.type) {
    case 'incremented_age': {
      return {
        name: state.name,
        age: state.age + 1
      };
    }
    case 'changed_name': {
      return {
        name: action.nextName,
        age: state.age
      };
    }
  }
  throw Error('Unknown action: ' + action.type);
}

Je trouve ça vraiment pas super, on a une espèce de boîte noire qui gère toutes les actions avec leurs arguments au lieu d'avoir des vraies méthodes.

En vrai on ne s'en sert pas comme ça, en gros la plus part des libs (comme redux toolkit par exemple) font le switch sur les actions pour toi, et ensuite chaque reducer de chaque action est implémenté dans une fonction propre, par exemple :

Code:

function incrementAge(state, payload) {
  return {...state, age: state.age + 1};
}

Un autre avantage d'avoir un store redux est l'imutabilité de ce store, ca empêche d'avoir un bout de state muté par un bout de code obscur par erreur

**Dross** · 13/02/2023, 21h32

Le store redux je trouvais ça bien sur le papier, je l'ai testé dans un de mes projets, et je trouve qu'il y a énormément de boilerplate pour un avantage discutable au final. Y'a des lib (notamment sous Angular) pour réduire ce boilerplate mais même avec ça, ça reste assez massif et verbeux.

Ça me donne vraiment cette impression du "code qui semble bien rangé car on a écrit 4x plus de choses autour" mais pas si facile à maintenir ensuite à cause du boileplate et des 36 niveaux d'abstraction. L'isolation c'est bien mais y'a un moment où avoir trop de niveaux ne t'aide plus et viens se mettre au travers de ton chemin.

Bref vraiment pas convaincu, après je l'ai utilisé sur un truc relativement simple, y'a certainement des cas d'usage qui s'y prêtent d'avantage, mais ça me semble un outil très situationnel et j'en mettrai pas par défaut dans mes projets les yeux fermés.

**raaaahman** · 13/02/2023, 21h57

Envoyé par Awake

Ça à l'air intéressant pour une app qui transforme beaucoup ses données elle même, un jeu mobile par exemple.

Pour le coup j'ai testé, et je ne suis pas convaincu. La logique de Redux c'est celle d'un flux uni-directionnel: les données déclenchent un rafraichissement de l'interface. Sauf que dans le jeu, j'avais besoin d'attendre la fin des animations avant de rendre le contrôle au joueur, et ça m'a fait faire pas mal de détours. Le code est en ligne: https://github.com/raaaahman/slime-the-floor

Envoyé par Orhin

Pas que, c'est aussi utile si t'as des actions globales à faire dans ton application.
Genre t'as un player vidéo dont le statut play/pause peut être interrompu par plein d'actions utilisateurs, ben c'est très pratique de mettre ça dans un store ou un contexte.

Je n'aurais pas utilisé cet exemple pour des actions globales. Un lecteur vidéo, pour moi c'est un morceau d'UI, un gros morceau certes, mais un morceau qui n'influe pas sur les données globales de l'appli (encore que ça dépend des applis tu vas me dire).

EDIT: Okay, je vois ce que tu veux dire: genre la vidéo youtube qui se met dans le lecteur miniature quand tu changes de "page"... Oui c'est plus simple de l'avoir dans le store.

Envoyé par Sangoon

En vrai on ne s'en sert pas comme ça, en gros la plus part des libs (comme redux toolkit par exemple) font le switch sur les actions pour toi,

Vrai. Là, c'est la tuyauterie à l'intérieur, c'est intéressant pour apprendre à l'utiliser, mais c'est pas le plus rapide à mettre en place. Bon après le RTK ça fait encore plus "boîte noire" pour le coup.

**Fastela** · 13/02/2023, 22h16

Envoyé par raaaahman

Pour le coup j'ai testé, et je ne suis pas convaincu.

Tu devrais retester alors. La gestion de l'état global (le « state management » en angliche) est super important. C'est ce qui te permet de gérer de la data de manière transverse dans ton application sans avoir à faire des trains de communication sans fin entre tes composants (ou un « event bus »). Dans le monde Vue on utilisait vuex et maintenant Pinia.

**raaaahman** · 13/02/2023, 22h42

Je parlais spécifiquement pour un jeu mobile (voir citation d'Awake).

**Charmide** · 13/02/2023, 23h07

Redux a mal vieilli je trouve, c'était le premier à dominer l'écosystème React pour la gestion de l'état et ça a toujours été un peu boilerplatey, notamment ça date d'avant que les hooks existent et maintenant elles sont universellement partout dans l'écosystème React, mais du coup ça a pas exactement été pensé pour en terme d'ergonomie (même si je sais que c'est pas incompatible et j'imagine que ça a dû être amélioré).
Le truc à en retenir c'est juste l'idée général d'un store qui représente l'intégralité de l'état de ton app, d'une vue en React qui est une fonction qui transforme le store en rendu, et de la codification d'actions qui sont émises par des actions utilisateurs ou d'autres evènement genre le serveur qui répond, qui déclenchent une autre fonction qui transforme un état en un nouvel état. Y'a une barrière basse à la complexité que ça peut avoir tout ce chemin là, il est parfois plus ou moins obfusqué avec les hooks et de la magie, mais comme ça a été dit si t'arrives à penser/implémenter comme ça, ça donne du code plus clean et plus testable le fait d'avoir tout ton code qui n'est qu'une série de fonctions qui transforment un truc en un autre.

Pour une lib pour l'état par défaut j'aime bien les libs que font Poimandres perso (zustand = même archi que redux, jotai = paradigme différent). C'est plus petit, moins de features, et plus simple; le genre d'outils que je préfère en général. Et dans l'esprit de React.

**Orhin** · 13/02/2023, 23h08

Envoyé par Dross

Le store redux je trouvais ça bien sur le papier, je l'ai testé dans un de mes projets, et je trouve qu'il y a énormément de boilerplate pour un avantage discutable au final. Y'a des lib (notamment sous Angular) pour réduire ce boilerplate mais même avec ça, ça reste assez massif et verbeux.

T'as essayé redux-toolkit ?
Ça allège quand même pas mal le boiletplate.

Envoyé par Dross

Bref vraiment pas convaincu, après je l'ai utilisé sur un truc relativement simple, y'a certainement des cas d'usage qui s'y prêtent d'avantage, mais ça me semble un outil très situationnel et j'en mettrai pas par défaut dans mes projets les yeux fermés.

Alors c'est pas nécessaire dans tous les projets clairement.
Et il ne faut pas non plus partir du principe que tout doit être dans Redux.
Les composants peuvent très bien avoir des state locaux pour leur logique interne.

Envoyé par raaaahman

Pour le coup j'ai testé, et je ne suis pas convaincu. La logique de Redux c'est celle d'un flux uni-directionnel: les données déclenchent un rafraichissement de l'interface. Sauf que dans le jeu, j'avais besoin d'attendre la fin des animations avant de rendre le contrôle au joueur, et ça m'a fait faire pas mal de détours. Le code est en ligne: https://github.com/raaaahman/slime-the-floor

Page not found.

Mais pour ce genre de cas, la gestion des animations je la ferais purement en local dans les components.
Après ça va dépendre du type de jeu aussi (tour par tour, temps réel, etc)

Envoyé par raaaahman

EDIT: Okay, je vois ce que tu veux dire: genre la vidéo youtube qui se met dans le lecteur miniature quand tu changes de "page"... Oui c'est plus simple de l'avoir dans le store.

Y'a ça, mais ça peut aussi être une interface de contrôle déportée.
Ou si tu veux centraliser la gestion des raccourcis clavier.
Ou si t'as des outils pour éditer ta vidéo dans des panneaux annexes.

**Dross** · 13/02/2023, 23h21

Envoyé par Orhin

T'as essayé redux-toolkit ?
Ça allège quand même pas mal le boiletplate.

J'avais utilisé ngxs de mon coté qui réduisait déjà pas mal de boilerplate avec l'usage de décorateurs, mais bon, ça restait verbeux quand même.

Après c'est vrai que les state-machine en général ça deviens vite usine à gaz, c'est pas uniquement le soucis de Redux.

**Charmide** · 13/02/2023, 23h27

Envoyé par Orhin

Alors c'est pas nécessaire dans tous les projets clairement.
Et il ne faut pas non plus partir du principe que tout doit être dans Redux.
Les composants peuvent très bien avoir des state locaux pour leur logique interne.

[...]

Mais pour ce genre de cas, la gestion des animations je la ferais purement en local dans les components.
Après ça va dépendre du type de jeu aussi (tour par tour, temps réel, etc)

C'est un des trucs éternellement piégeux quand tu fais du React je trouve. Quand tu bouges une sous-sous-partie d'un gros store centralisé immutable et que tu peux le diff avec son état précédent, et que derrière ça va rerendre un shadow DOM qui de la même façon va être comparé à son état précédent pour pas refaire tout le DOM à chaque fois... Tu pourrais t'imaginer que y'a suffisamment de couches d'opti pour faire un peu ce que tu veux et que ça finisse bien.
En pratique et notamment si tu t'amuses à y mettre des données qui bougent beaucoup (genre des coordonnées de souris, mais une game loop à la sauce jeux vidéos pareil), tu vas vite te rendre compte que ça n'a rien de magique. Et globalement pour n'importe quelle app t'as besoin de comprendre les mécaniques de quand et comment les composant sont rerender, et de réfléchir activement à l'opti, et de creuser un petit peu derrière la peinture.
Svelte & co (tous les frameworks qui se vendent comme "vraiment réactifs") ont un peu pris cet angle d'attaque en virant l'idée du shadow DOM et en proposant des architectures où globalement c'est juste pas possible de refaire/redessiner trop de morceaux d'interfaces et de se mettre dans le caca comme ça.

**Orhin** · 13/02/2023, 23h28

Envoyé par Dross

J'avais utilisé ngxs de mon coté qui réduisait déjà pas mal de boilerplate avec l'usage de décorateurs, mais bon, ça restait verbeux quand même.

NGXS est pas mal dans l'univers Angular en effet.
Mais RTK est encore moins verbeux justement (c'est dire la différence avec du Redux "vanilla").

**Orhin** · 13/02/2023, 23h49

Envoyé par Charmide

C'est un des trucs éternellement piégeux quand tu fais du React je trouve. Quand tu bouges une sous-sous-partie d'un gros store centralisé immutable et que tu peux le diff avec son état précédent, et que derrière ça va rerendre un shadow DOM qui de la même façon va être comparé à son état précédent pour pas refaire tout le DOM à chaque fois... Tu pourrais t'imaginer que y'a suffisamment de couches d'opti pour faire un peu ce que tu veux et que ça finisse bien.
En pratique et notamment si tu t'amuses à y mettre des données qui bougent beaucoup (genre des coordonnées de souris, mais une game loop à la sauce jeux vidéos pareil), tu vas vite te rendre compte que ça n'a rien de magique. Et globalement pour n'importe quelle app t'as besoin de comprendre les mécaniques de quand et comment les composant sont rerender, et de réfléchir activement à l'opti, et de creuser un petit peu derrière la peinture.
Svelte & co (tous les frameworks qui se vendent comme "vraiment réactifs") ont un peu pris cet angle d'attaque en virant l'idée du shadow DOM et en proposant des architectures où globalement c'est juste pas possible de refaire/redessiner trop de morceaux d'interfaces et de se mettre dans le caca comme ça.

Ah oui clairement il faut faire gaffe à ce genre de truc.
Et c'est là où connaitre un minimum le fonctionnement interne des framework est utile.
Après, on peut faire la même chose en Angular.

M'enfin, typiquement dans ton exemple, la position de la souris n'a rien à faire dans le store global et devrait avoir son propre contexte.

Et ne pas oublier d'avoir du React.memo sur les descendants des composants qui utiliseront ce contexte.

**Charmide** · 14/02/2023, 01h00

Yes, c'est ça que j'appelais "réfléchir activement à l'opti".
Les React.memo c'est le summum de la chose, avoir à en écrire c'est souvent un déplacement de la charge et du boulot à l'utilisateur/dev final d'un truc que t'espèrerait définitivement qu'il soit géré plus intelligemment en amont par de l'outillage.
Et angular j'en sais trop rien, mais c'est pas incompatible avec react non plus, y'a des libs de gestion d'état où tu peux très bien coller ta position de souris sans tuer ton framerate (comme celle que je citais plus haut). Idéalement je préfère ne pas avoir à réfléchir à quels bouts de l'état global je dois sortir de ma lib d'état global, ou avoir à faire des optis à la main.

M'enfin, c'était surtout un avertissement à ceux qui commencent à en faire: prenez le temps de comprendre comment ça marche, c'est en général moins magique ça pourrait l'être dans un monde idéal(réactif), c'est un des trucs les plus relous.

**raaaahman** · 14/02/2023, 12h15

Envoyé par Orhin

Page not found.

Mais pour ce genre de cas, la gestion des animations je la ferais purement en local dans les components.
Après ça va dépendre du type de jeu aussi (tour par tour, temps réel, etc)

Ah mince, c'est vrai qu'il est toujours en privé le temps que je me décide sur la license... Je peux filer des accès aux intéressés (envoyez votre pseudo GitHub en MP).

Pour info c'est du puzzle game (~tour-par-tour), mais quand même, l'état des animations doit définir si le joueur a le contrôle ou non (pas possible de déclencher un nouveau mouvement si l'animation n'est pas terminée), et ça se mixe difficilement avec le flux de Redux. (Et je n'ai pas utilisé React, heureusement!)

**Coin-coin le Canapin** · 14/02/2023, 14h27

There has been an immense amount of enthusiasm for the upcoming changes with Twitter API.

**Charmide** · 14/02/2023, 14h31

On avait pas remarqué

Envoyé par raaaahman

Ah mince, c'est vrai qu'il est toujours en privé le temps que je me décide sur la license... Je peux filer des accès aux intéressés (envoyez votre pseudo GitHub en MP).

Pour info c'est du puzzle game (~tour-par-tour), mais quand même, l'état des animations doit définir si le joueur a le contrôle ou non (pas possible de déclencher un nouveau mouvement si l'animation n'est pas terminée), et ça se mixe difficilement avec le flux de Redux. (Et je n'ai pas utilisé React, heureusement!)

Ca me fait penser que le collectif dont je parlais un peu plus haut maintient react-three (renderer react vers three.js pour faire.. de la 3D) et react-spring (pour animer des trucs). Ils ont des démos assez impressionante de jeux/trucs intéractifs, j'arrive plus à retrouver ça mais le project lead bossait dans une boîte qui faisait tourner tout un logiciel type Autocad dans un navigateur, avec react donc.

Comme tu dis (mal)heureusement mais quand même c'est classe, c'est au compte de react d'être un outil assez simple/minimaliste et donc flexible pour que tu puisses lui faire faire ce que tu veux. Forcément ils ont leurs propres patterns de gestion de l'état & co.

**tompalmer** · 14/02/2023, 14h43

La Novlang Corporate West Coast

En gros je traduis : "Vu le Backlash, on va revoir notre copie, vous faites chier a pas être des pigeons"

**raaaahman** · 14/02/2023, 17h39

Envoyé par Charmide

Ca me fait penser que le collectif dont je parlais un peu plus haut maintient react-three (renderer react vers three.js pour faire.. de la 3D) et react-spring (pour animer des trucs). Ils ont des démos assez impressionante de jeux/trucs intéractifs, j'arrive plus à retrouver ça mais le project lead bossait dans une boîte qui faisait tourner tout un logiciel type Autocad dans un navigateur, avec react donc.

Je connais cette bibliothèque de nom, mais à froid, manipuler des objets 3D avec le flux uni-directionnel de React ça ne me fait pas rêver... Ca risque de me faire tomber exactement sur le même souci dont je parlais avec Redux, mais dans la vue en plus de la gestion d'état...

**Awake** · 14/02/2023, 18h16

La gestion des events me gavait dans React, donc j'ai fait un service global avec un petit EventEmitter qui me permet de faire circuler des events transversaux. Ca marche au poil, mais est-ce que ça ne serait pas une connerie pour une raison ou une autre ?

Edit : pour expliquer un peu mieux, c'est pour un lien dans le footer qui doit activer une modale. Les scopes des deux sont assez indépendant, et je trouve que faire passer le callback de child en child n'est pas super. Surtout qu'avec mon event transversal, la modal peut être ouverte facilement à partir de n'importe où sans grandes modifications.

**Orhin** · 14/02/2023, 18h33

Pour ça en React, le plus "standard" c'est d'utiliser des contexts : https://beta.reactjs.org/learn/passi...y-with-context

**Awake** · 14/02/2023, 20h14

Merci ! Je suis pas entièrement convaincu, dans le cas de la modale, si on veut que l'ouverture soit possible de partout, il faut enfermer toute l'app dans un context. Avec de l'injection de dépendances ce serait vite réglé, mais react ne le propose pas nativement apparemment

**raaaahman** · 14/02/2023, 22h32

Tu as la technique du HOC aussi, j'avais fait ça pour une modal, c'était pas mal.

**deathdigger** · 15/02/2023, 09h56

Envoyé par Kamikaze

Ah t'as du inclure que Canard Café, pour sûr j'ai plus de posts dans les topics jeux vidéo et programmation etc.

'Tain le topic des cryptos en main topic je me dégoute, heureusement que y'a le topic Goa pour compenser

Vu que c'est toi qui t'autocite le plus, il faudrait changer ton sous-titre en Raoult

**Anonyme20240202** · 15/02/2023, 10h22

En vrai faudrait voir les posts car ça a l'air d'un bug, je fais souvent des doubles posts mais je pense pas me quoter

Quoique le web crawling d'Awake a l'air de remonter loin, je pense pas que l'API vbulletin aille ci loin (en tout cas à vue de nez j'arrive pas à chercher aussi loin), p'têt qu'il l'a implémenté lui même, et à l'époque du topic à b0b0 (Oni Oni et compagnie, ça remonte à presque 10 ans) j'avais fait un shit post ou je me quotais genre 100 fois pour faire l'idiot, ça faisait bugger le forum à l'époque (oui j'étais con)

edit: Ah nan c'est possible de chercher arbitrairement loin, ouais faudra faire gaffe le topic à b0b0 était bourré d'insultes haha

**Charmide** · 15/02/2023, 10h31

Envoyé par Awake

Merci ! Je suis pas entièrement convaincu, dans le cas de la modale, si on veut que l'ouverture soit possible de partout, il faut enfermer toute l'app dans un context. Avec de l'injection de dépendances ce serait vite réglé, mais react ne le propose pas nativement apparemment

L'injection de dépendance c'est vraiment pas dans l'esprit, c'est plus une histoire de paradigme que de feature manquante.
Regarde ce que fait cette librairie pour inspiration aussi: https://www.npmjs.com/package/material-ui-popup-state.
Tu pourrais ré-implémenter des hooks dans le même style qui sont partageables entre composants ou même la réutiliser telle quelle, de mémoire c'est découplé de material-ui et ça fait le boulot, me semble que je l'avais utilisé y'a un moment comme ça.

Envoyé par raaaahman

Je connais cette bibliothèque de nom, mais à froid, manipuler des objets 3D avec le flux uni-directionnel de React ça ne me fait pas rêver... Ca risque de me faire tomber exactement sur le même souci dont je parlais avec Redux, mais dans la vue en plus de la gestion d'état...

Hehe un peu comme toi mais je trouve ça intéressant de voir jusqu'où tu peux aller dans ce paradigme là. Dans l'idée le déclaratif c'est cool et quand tu vois des démos de ce style https://codesandbox.io/s/jnoqzplmj9 (swipe les cartes de droite à gauche) en très peu de lignes et sans spaghetti c'est classe... mais je me suis jamais dit que ça valait le coup de passer du temps à savoir faire ça.

- - - Mise à jour - - -

Envoyé par Kamikaze

En vrai faudrait voir les posts car ça a l'air d'un bug, je vais souvent des doubles posts mais je pense pas me quoter

Quoique le web crawling d'Awake a l'air de remonter loin, je pense pas que l'API vbulletin aille ci loin (en tout cas à vue de nez j'arrive pas à chercher aussi loin), p'têt qu'il l'a implémenté lui même, et à l'époque du topic à b0b0 (Oni Oni et compagnie, ça remonte à presque 10 ans) j'avais fait un shit post ou je me quotais genre 100 fois pour faire l'idiot, ça faisait bugger le forum à l'époque (oui j'étais con)

edit: Ah nan c'est possible de chercher arbitrairement loin, ouais faudra faire gaffe le topic à b0b0 était bourré d'insultes haha

J'attends le "connard" en gros dans un wordcloud

**Anonyme20240202** · 15/02/2023, 10h32

En vrai c'est un champ de mine mes anciens posts j'étais un abruti de haute volée à l'époque, je compte sur Awake pour modérer tout ça

**Awake** · 15/02/2023, 10h39

Les data sont tous les messages des sujets dont il y a eu de l'activité il y a moins d'un an. (il y en a pour 5Go juste en scrapping de l'HTML...). Donc si un topic de spam de l'époque de la mare a été remonté récemment, il faudra assumer

**Awake** · 15/02/2023, 11h23

Envoyé par raaaahman

Tu as la technique du HOC aussi, j'avais fait ça pour une modal, c'était pas mal.

Envoyé par Charmide

L'injection de dépendance c'est vraiment pas dans l'esprit, c'est plus une histoire de paradigme que de feature manquante.
Regarde ce que fait cette librairie pour inspiration aussi: https://www.npmjs.com/package/material-ui-popup-state.
Tu pourrais ré-implémenter des hooks dans le même style qui sont partageables entre composants ou même la réutiliser telle quelle, de mémoire c'est découplé de material-ui et ça fait le boulot, me semble que je l'avais utilisé y'a un moment comme ça.

J'aimerais bien comprendre pourquoi utiliser des services/provider n'est pas recommandé. Par exemple dans Angular ça fait parti des fondations. De même pour les events dans le scope global ? Il y a plein de frameworks back et front qui les utilisent, pourquoi pas React ?

J'ai un peu l'impression qu'ils essaient d'être différents par principe, et que ça mène à des solutions tarabiscotées quand ça pourrait être simple.

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

Outils de la discussion

Règles de messages