Reprise du message précédent :

C’est assez logique, d’après ce que j’ai compris l’effet de la chloroquine est de modifier le pH des lysosomes, ce qui ralentit la réplication du virus. Donc si c’est efficace c’est au début de l’infection, quand le virus est encore peu présent. Quand il a eu le temps de multiplier et que la réponse immunitaire est enclenchée (ce qui provoque les lésions pulmonaires), ça n’a plus d’intérêt.

- Pour commencer, la philosophie de React au départ c'était d'avoir un language de markup avec x backend différents, l'idée étant (et ça a été exploité de manière ultra marginale par quelque boite) de pouvoir utiliser un seule base de code pour le front end sur différente plateforme. Par exemple: avoir une implem pour le web desktop, une pour le web mobile, une pour les TVs, une pour les app natives, etc... Sauf qu'aujourd'hui c'est pas comme ça que c'est utilisé: 99% de l'utilisation c'est pour du web. Sans parler du fait que React DOM est une putain d'usine à gaz.
- Ensuite, c'est pas trop difficile de se rendre compte ou de démontrer que React montre ses limites en terme d'expressivité dès qu'il s'agit d'ajouter un peu de logique. Et c'est un peu logique, c'était pas pensé pour ça à la base. D'ailleurs, sans Array#map, on aurait probablement même pas cette conversation.
- La philosophie de réact c'était de penser au component level, pas de faire des applications entières basées sur un language de markup. Une des best practises du développement React c'est d'éviter les composants stateful autant que possible, sauf que, le routing par exemple est stateful par définition.

- Quand j'entends SPA c'est au sens, application drivée par React. Comme je l'ai dit avant, on utilise react sous forme de hiérarchie hyper complexe qui finit par rendre une page complète. Driver une SPA c'est pas son boulot.
Je ne comprends pas cette obsession qu'ont les équipes à vouloir tout rendre dans un seul composant alors que la fonctionnalité la plus intéressante d'un outil comme Redux c'est l'observability qui permet de ne pas avoir de lien fort entre la datasource et ses consommateurs.
On arrive toujours à ce même pattern mono root component, qui n'apporte rien en terme de performance ou de maintenabilité, bien au contraire. C'est un pattern qui scale mal et qui n'apporte rien.

https://www.technologyreview.com/s/ [...] ntilator/?

avis intéressant shinuza, mais je trouve un peu tranché. React native est vraiment un succès, autant en terme de perf qu'en terme de facilité de développement par rapport à du natif.c Et  pour tout le reste (de la tv aux smartphone, ) le web fonctionne plutôt bien, je ne pense pas que ce soit de la faute de react

Sans le array#map, il y aurai des collectionComponent, comme dans backbone par exemple

Je n'ai jamais tenté d'avoir plein de racins react dans une page, est ce que ça simplifie vraiment la vie ? Genre tu as une racine Header , une Section, une Footer ? Mais le gros de la magie est dans la partie centrale, donc au final, est ce que ça ne fait pas un composant qui fait 80% du code
Est ce qu'il est possible de rendre en React des balises qui serviront de racine a un autre bout de react ?

Enfin, je ne comprends pas React ne peut pas driver une page ? Pour moi il y a tout ce qu'il faut avec react-router (ou un clone) et des états là ou c'est nécessaire. Eviter les composant statefull , ça ne veut pas dire les supprimer complètement, sinon, le moindre form devient impossible

Ce que je dis c'est assez dommage que ça ne soit pas un des critères qui drive le choix de cette lib vs autre chose.

Non, faire une zone login, une zone liste des produits, une zone menu dynamique, etc.. Le but c'est d'éviter de faire du rendering pour des trucs qui ne bougent pas puisque structurels.

Pas compris.

Si y'a bien un truc que j'ai compris en programmation, c'est que si un truc est très dur à faire avec un outil, c'est probablement pas l'outil adapté. Or, y'a plein de trucs triviaux qui sont ou qui ont été très compliqués avec React et qui ont nécessité des modifications de la lib. Namely l'ajout des portals. Gérer des forms ou des modals avec React c'est pas trivial et c'est normal: c'est pas fait pour.

mais alors tu utilise quoi comme techno autour, pour dire "là il me faut un login", "là il me faut un menu" ?

Et si React ne répond qu'à ça, je trouve qu'on reste sous une masse critique qui n'impose pas de sortir l'artillerie lourde parceque justement la partie compliquée est la gestion de ces blocs indépendants comme une entité globale et cohérente

pour les form, sérieux ? dès le début tu pouvais faire

class MyForm{
    constructor(props) {
       this.state = {first:'', second:''}
       this.change = this.change.bind(this)
    }
   
   change(event){
      this.SetState({[e.target.name]: e.target.value})
  }
 
   render(){
     return <form >
 
       <input type="text" name="first" value={this.state.first} />
       <select="text" name="second" value={this.state.first} >
            <option/>
            <option value="1">1</option>
       </select>
    </form>
  }
}

Même si ce n'est pas complètement trivial, on est loin du viol de librairie. Le pire était de ne pas oublier les bind

Pour les modal, je te l'accorde que c'était moins confortable avant les portal, mais pas impossible.

De ce que j'ai compris des  portal, ils ne sont indispensable que pour le titre de la page OU si ta page n'est pas rendue intégralement par React. Ce qui te gène plus que moi , vu que je ne fais pas de multi racine.

Du coup pour que le traitement ait un quelconque intérêt il faudrait tester les gens

C'est d'ailleurs ce que dit Raoult.

Suffit juste de monter ton root component dans le placeholder prévu à cet effet, au lieu d'avoir un seul et unique ReactDOM.render(), en avoir plusieurs

class MyForm{
    constructor(props) {
       this.state = {first:'', second:''}
       this.change = this.change.bind(this)
    }
   
   change(event){
      this.SetState({[e.target.name]: e.target.value})
  }
 
   render(){
     return <form >
 
       <input type="text" name="first" value={this.state.first} />
       <select="text" name="second" value={this.state.first} >
            <option/>
            <option value="1">1</option>
       </select>
    </form>
  }
}

Ouais, fin là t'es en en easy mode, déjà c'est pas trivial et assez lourd. Mais quand t'ajoutes la validation, les éléments qui apparaissent quand tu coches cette radio et pas celle ci, les erreurs, l'injection dans Redux: tu finis avec un truc bien loin du code de départ. Est-ce absolument nécessaire d'utiliser React pour ça?
 

Je dis pas que c'est impossible, je dis que ça posais des difficultés qui devrait mettre la puce à l'oreille: i.e: si le truc que je faisais facilement avec x est très difficile à faire avec y, est-ce que y est adapté, ou est-ce que je ne suis pas en train de le tordre pour mon utilisation?

mais comment tu définis tes placeholder avec leurs paramètres ? ( dans le cas de la liste d'article ou de  l'écran de login)  

Justement, c'est quoi ta vision pour gérer les formulaires non triviaux (dynamique, vérifications non triviales asynchrones, ...) ? j'ai toujours trouvé ça pénible et j'ai finis par me dire que c'était normal, mais peut être que j'ai raté quelque chose.  
 
Ma dernière itération pour notre CMS (donc avec des formulaire très lourds), c'est une définition en json de leur structure + des composants react pour le rendu /validation. C'est limitant pour la mise en page, mais au moins la partie validation/UX est robuste et facile à mettre en place.
 

Je me pose la même question souvent, mais je n'ai justement pas tant l'impression que ça de tordre react.

Putain mais Douste-Blaze ce crétin. Il dit que le test de Raoult "prouve" que le HCQ fonctionne.
 
Et l'épouse d'Estrosi qui dit que la chloroquine l'a guérie. Mais moi aussi j'ai été guéri pauvre conne, et j'ai pas pris de chloroquine. Tout comme la grande majorité des gens qui ont chopé la maladie.

La France, sponsorise par Boiron

Ne medis pas de Boiron : leur usine qui devait fermer va produire du gel hydroalcoolique... Pour une fois ils vont produure un truc qui a de l'effet!!

Sinon, c'est un peu gênant que l'auteur principal de l'étude sur la chloroquine est aussi l'éditeur en chef de la publication qui publie ledit article, et qu'une seule journée a été consacrée à la relecture (normalement, c'est plutôt 3-6 mois).
https://twitter.com/MicrobiomDigest [...] 7417699328

Et apparemment, 45 publications de Raoult ont été faites dans son journal.

Il y a que chez moi que le forum rame affreusement depuis hier après-midi? Ils ont réduit le débit comme youtube et netflix?

Sly Angel se fait un mirror de pornhub premium HD pour lui et Marc avant que ce ne soit plus accessible

nope, idem ici  

Dans un sondage récent qui demandait "à votre avis quel pays va prendre le plus cher" entre USA, UK, Pays-Bas et je sais plus lequel autre, j'avais répondu USA et vu comment Trump gère la crise et envoie délibérément dans le mur les états à dominante démocrate en croyant que de toute façon les états ruraux prendront pas trop cher, je me dis que ça va être cataclysmique là-bas.

 
Haha Mélenchon avait à peu près réussi à être décent depuis le début de cette crise, je me demandais à quel moment il allait se rouler dans la fange, bah c'est maintenant

Cuomo et de blasio n'ont pas vraiment eu besoin de Trump pour foutre la merde dans New York State

Il faut quand même rendre hommage à Hollande, il a réussi à faire en 5 ans ce que la droite rêvait de faire depuis l'avènement de la Vème République : il n'y a plus d'alternative politique nationale saine et crédible à la gauche de Macron

Y'a pas grand chose à sa droite non plus

mais c'est plus dur de n'attribuer le mérite qu'a un seul Homme

Ca se passe mieux en bloquant googletagservices.com
 
edit : bof non

Y a des cons partout (et le QI n'est pas un truc qui fait le tri là-dessus).
(merde j'ai répondu sur une vieille page avec les menuisiers alors que j'avais la nouvelle à côté).
 
Mais bon, le point positif, y a aussi des gens bien, et on grandit mieux quand c'est ce côté qu'on cherche à voir.

class MyForm{
    constructor(props) {
       this.state = {first:'', second:''}
       this.change = this.change.bind(this)
    }
   
   change(event){
      this.SetState({[e.target.name]: e.target.value})
  }
 
   render(){
     return <form >
 
       <input type="text" name="first" value={this.state.first} />
       <select="text" name="second" value={this.state.first} >
            <option/>
            <option value="1">1</option>
       </select>
    </form>
  }
}

 
Voilà exactement pourquoi je parlais de lisibilité du code. Ton exemple est ultra basique, et pourtant il y a du constructor, du binding, un change event et du JSX (bon ça à la rigueur...).
 
Le même exemple trivial en Vue donnc ça :
 

<template>
<form>
    <input v-model="first" />
    <select v-model="second" >
        <option/>
        <option value="1">1</option>
    </select>
</form>
</template>
 
<script>
export default {
  data: () => { first: '', second: '' };
}
</script>

 
Que je trouve autrement plus lisible, surtout pour un néophyte.

https://eu.cincinnati.com/story/new [...] 085403002/

Bof. C’est super visible parce qu’ils sont en avance (un peu comme l’Italie ici) & testent beaucoup mais la majorité des états sont complètement à la ramasse, apparemment à 500 cas et 9 morts le système d’AZ est déjà sous l’eau, en bonus c’est une Mecque de vieux.  
 
Les autres états qui pensent que ça ira vont avoir un réveil aussi difficile que NY, sinon pire. Les cas sont en train de monter dans le sud qui est beaucoup moins équipé, beaucoup plus pauvre, complètement pas préparé, et beaucoup plus haut en comorbidités.

<template>
<form>
    <input v-model="first" />
    <select v-model="second" >
        <option/>
        <option value="1">1</option>
    </select>
</form>
</template>
 
<script>
export default {
  data: () => { first: '', second: '' };
}
</script>

 
Calme toi, il montrait un exemple de l’époque. C’est plus comme ça maintenant.

Ah ben je peux pas deviner moi  

Edit: En même temps, c'est toujours dans la doc https://fr.reactjs.org/docs/forms.html

<template>
<form>
    <input v-model="first" />
    <select v-model="second" >
        <option/>
        <option value="1">1</option>
    </select>
</form>
</template>
 
<script>
export default {
  data: () => { first: '', second: '' };
}
</script>

c'est du vieux code

Aujourd'hui , je ferai :

const myFuckingForm = ({initialValues}) => {
    const [values,setValues] = useState({initialValues})
    const change = (e) => setValues({...values, [e.target.name]:e.target.value})
    return <form >
       <input type="text" name="first" value={values.first} onChange={change}/>
       <select="text" name="second" value={values.second} onChange={change} >
            <option/>
            <option value="1">1</option>
       </select>
    </form>
}

je te l'accorde que vue.js est plus agréable à utiliser sur les formulaires simples, mais je trouve que ça converge dès que tu rajoutes des validations custom.

Edit: c'est toujours dans la doc parceque react pousse jusqu'à l'absurde la rétro compatibilité, et que maintenant qu'il ya une grosse base d'utilisateurs les nouvelles syntaxes prennent un peu de temps à être généralisées.

Edit2: sur un form un peu velu, je ferai un contexte local, comme ça tous mes fils pourraient utiliser les valeurs sans faire du passage de props à répétition

Je capte pas la difficulté, j'ai du mal m'expliquer
 

<body>
  <section id="article-list"></section>
  <aside>
    <div id="login"></div>
  </aside>
  <script>
    ReactDOM.render(<ArticleList />, document.getElementById('article-list'));
    ReactDOM.render(<Login />, document.getElementById('login'));
  </script>
</body>

Ma vision c'est de pas les faire en React.
Y'a des outils plutôt complets pour faire ça, et rien ne t'empêche de sortir de React, d'utiliser un autre truc et d'y revenir si ça te simplifie la vie. C'est ça que j'essaie de combattre.    
 

Bah, si tu trouves un truc dur et chiant mais que ça devient normal, je pense que c'est un indice  

<body>
  <section id="article-list"></section>
  <aside>
    <div id="login"></div>
  </aside>
  <script>
    ReactDOM.render(<ArticleList />, document.getElementById('article-list'));
    ReactDOM.render(<Login />, document.getElementById('login'));
  </script>
</body>

je dois rater un truc évident  
Prenons ce scenario : si l'utilisateur n'est pas connecté, alors on affiche le login, sinon, la liste des articles:  le markup global des composants change. Autre cas : suivant l'url, ce n'est pas une liste d'article, mais un seul article, tu le rends dans article-list ?
Comment tu le génères ?
Ou alors, tu fais un markup hyper générique et plein de ReactDOM.render qui retournent potentiellement null ?

Typiquement, tu utilises quoi pour tes forms riches côté client ?

il y a des trucs qui sont difficiles par nature. Ou plutôt : il y a pas mal de taf à faire côté dev si tu veux simplifier la vie de l'utilisateur.

Effectivement, parfois leur doc est chiante à suivre.

Mais globalement :

• Tu n'es pas obligé de faire des class en React.
• Si tu utilises des Class, tu n'es pas obligé d'avoir un constructeur. Tu peux directement écrire state = {}
• Tu n'as pas besoin de bind tes fonctions grâce au arrow function.
• Tu n'es pas obligé de suivre le lifecycle du début. Maintenant tu as les hooks et useEffects.

CF. exemple de Flo.

Hook et effects : https://reactjs.org/docs/hooks-intro.html

 
Puis faut dire que le Spring Break va bien aider
 
https://twitter.com/goldengateblond [...] 6469949440

Helmuth avait partagé ses stats dans le topic chambre de garde, quasiment tous les patients en réa en dessous de 60 ans font plus de 100 kg.
Ça va faire un carnage dans le sud et le midwest.  

 
Ici en FR ?

 
Oui, son hosto.

Ah ouais je savais que ça allait foutre la merde (dans les deux sens, si c’était pas déjà en floride ça y est, et ça a partagé le truc dans toute la moitié est du pays) mais c’est autre chose de le voir.  

Ouaippers, d’autant plus avec des types genre Reeves dans le Mississippi qui veulent rien fermer.

C'était un exemple générique. Juste pour montrer que ce qui est dynamique peut-être en React mais ce qui n'est pas dynamique peut rester en HTML pur. L'idée c'est pas s'emmerder avec une SPA. Mais tu peux avoir une approche à la Youtube, ou tu recupères de l'intelligence et tu rends uniquement la partie qui doit bouger.
 
Donc au lieu de "article-list" tu as "content", tu scratches juste le "content" quand il a besoin de changer et t'y mets le composant qui doit être rendu. Bien sûr c'est dépendant du type d'application et de où  tu mets le curseur pour la partie "dynamique".
 
Moins la page est dynamique, plus ça fait sens de ne pas rendre la totalité de la page via React.
 

validate.js