Reprise du message précédent :

 
Je me suis mal exprimé. Tu peux parfaitement séparer et avoir ton HTML dans des templates front ends. Je parlais d'avoir tout le code embedded pour des sites ou des applications qui n'en ont aucunement besoin.

 
Je valide. La partie "contre productive" étant le plus souvent la destruction. Dans une app multi page ca dégage tout seul, toutes les variables sont vidées pour toi & co. Là il faut faire gaffe, et a peu près personne ne fait gaffe...
 

 
Hum nous, chaque composant a une classe qui correspond a son path dans le projet (que ce soit en React ou Vue car on a les deux). Donc le mec touche réellement que au Sass/less en targettant le bon path de classes et basta, ca suffit dans 99% du temps, le reste ils demandent une modif du code (souvent pour rajouter des balises), ou alors ils le font eux même s'ils savent faire. Ca semble pas leur poser trop de soucis (après ce sont des apps ou la fonctionnalité a plus d'importance que le visuel, donc les designers qu'on a sont pas ultra solicités pour lécher le moindre pixel)...
 

 
C'est surtout une décharge du serveur, et donc une meilleure réactivité de l'app si c'est bien fait tout en diminuant les couts... Chez nous on est a 13/14k$ d'AWS par mois alors ce genre de détails ca compte

Les designers que j'ai pu avoir maîtrisaient largement mieux le psd que l'html
Déjà je suis content quand ils ont des bonnes connaissances en CSS

Le rôle des intégrateur a évolué par contre(ceci dit, le rôle d'un intégrateur non codeur me semble léger pour une web app )

{isOpen && (
          <div
            className="backdrop"
            onClick={e => {
              this.props.close && this.props.close();
              e.preventDefault();
            }}
          />
        )}

  Et encore y'a pas une ternaire avec des expressions d'un km chacune    
 

{isOpen && (
          <div
            className="backdrop"
            onClick={e => {
              this.props.close && this.props.close();
              e.preventDefault();
            }}
          />
        )}

Qu'est ce qui te choque a propos de ca ? C'est plutôt classique pour du React.
Par contre le style inline dans les composants  

On a couiné à mort contre le mélange HTML/Code logique/CSS, on a fait des framework MVC, pour en revenir à ça ?

Même pas avec un bâton je touche à ça

Foutre tous les styles sur le div alors qu'on peut le mettre dans une classe, c'est sûr c'est moche.

C'est pas uniquement que c'est moche, c'est surtout que ça flingue les perfs de rendu

Nan mais react il est tellement malin, qu'il remplace ça par une classe à la compilation et il colle le style dans une css à part non ?

c'est mon code, c'est forcement améliorable, et sur le coup, j'ai été faineant, je l'avoue ( surtout que webpack gère très bien les petites css à packager)
 
Mais franchement, tout mon composant modal fait 70 lignes, en comptant les css. C'est loin d'être imbitable.
 
@skylight : oui, parceque tout séparer dans des fichiers aux quatres coins de ton IDE est finalement penible. Pour rappel, j'ai fait du php 3/4/5 sans framework, du symfony ,du laravel, du nodejs/angular1 et pas mal d'autres framework
 
Je trouve que react est le plus efficace que j'ai plus tester, autant pour les mini projet en mode MVP que sur notre plateforme de gestion de contenu ( environ 20KLoc de code maison)

nope
D'u autre côté, ça te garanti que tu n'as pas de collision avec une autre classe CSS d'un autre composant

Sur un composant modal qui est utilisé, par définition une fois et une seule  
 
C'est sûr que l'impact va être énorme

Non, mais c'est la théorie, en pratique je fais aussi de temps en temps des trucs rapides mais crades

T’facon on s’en balek, ce sera deprecated dans 2 ans et re-écris dans 3

Et angular (dans ses dernieres versions hein) vous en pensez quoi sur le topic ?
 
Perso je m'en lasse pas, la productivité est au top, aucun soucis de perf, s't'un plaisir tous les jours

l'avantage est que même du vieux code ( a coup de createClass) fonctionne toujours en 16.x.  
 

J'ai essayé angular2 , alors qu'il état sensé être quasi fini, et puis ils ont décrété qu'il fallait un nouveau router donc fuck la compat
ça m'a gonflé, je suis passé sur react
 
et je n'aimais pas la syntaxe des templates a coup de symboles à la con : difficile à demander à google, difficile à trouver dans les docs
a croire qu'il y un cout par caractère  
 
En vrai, les FW modernes sont pas mal en JS ( angular/ember/react/vue) , ils ont des partis pris différents, mais ils te permettent tous de lancer rapidement une licorne sans se tirer une balle dans le pied, à condition de ne pas vouloir faire de l'angular en react ou de l'ember en vue  

 
Quite à avoir tout dans le même fichier, je préfère carrément l'approche de Vue et de leurs Single File Components, avec 3 sections bien distinctes pour le template, le script JS et le style.

C'est aussi l'approche d'Angular (pour ceux qui veulent tout mettre à la porcasse dans le même fichier).
 
Après je vois difficilement la moindre justification à faire ca quand on peut dissocier proprement avec un componentA.ts  componentA.scss et componentA.html dans son dossier components/componentA/ sans aucun impact (le css restera encapsulé au component etc)
 

 
   
 
Là ou j'ai plus a redire sur react , c'est plutôt sur des choses comme les events synthétiques ou le binding à faire, ...

C'est un style déjà en JS qui pue la merde. Donc là, dans un pseudo-langage de markup, ça me fait mal aux yeux. Ça serait 1000 fois moins laid de faire:

<MyThing show={ bool } />

Je sais, c'est pas la même sémantique.

C'est pas vraiment de l'enculage de mouche, il faudrait un framework un peu opiniated qui gere ce genre de truc. Aujourd'hui y'a pas 2 projets react qui se ressemblent, donc même en connaissant la techno, t'as une learning curve assez pentue quand tu rentres dans un nouveau projet.

Tu formes un nouveau c'est:

- Déballes ton mac
- On compile comme ça
- On teste comme ça
- On lint comme ça
- On utilise ce framework de css-in-js
- On organise nos fichiers comme ça
- On utlise Redux avec ces middlewares (ou pas)
- Etc...

Au final, c'est très dur de prendre ces marques sur un projet React vs du python, du go, du php, du ruby, du java ou même du nodejs, parce qu'il existe x flavors du même truc et que personne n'est d'accord avec son voisin. Aka la maladie de Javascript depuis 10 ans.

Granted, c'est pas un problème inhérent à React, mais il en souffre d'autant plus car y'a rien d'imposé dans un écosystème qui sait pas prendre des décisions.

Ember, Angular, ou Vue règlent ça.

Tu peux aussi faire la même chose en Vue

Et en un seul fichier, et c'est fucking propre.
 
Et tu peux meme faire que tes plugins aient leur propre balise, genre moi mes templates commencent par:

 
Pour la trad.

<MyThing show={ bool } />

 
Tu feras quoi dans <MyThing /> ? Exactement la meme chose, au bout d'un moment faire des composants pour juste faire des composants ca ne sert plus a grand chose  

C'est un exemple d'une built-in prop qui ferait ça, pas un composant qui wrap le truc... Y'a pas de conditional rendering built-in, ce qui assez con, mais c'est assez trivial d'implémenter une prop qui fait ce travail au niveau du transpiler

Hello à tous!
 
  noob inside
 
Parfait débutant je cherche un tuto/piste/conseil pour la réalisation de graphique en barre avec en abscisse une échelle du temps et en ordonné un valeur (KW électrique). Le but étant d'obtenir un histogramme de consommation/production électrique avec des valeur issues d'une base de donnée comme sur cette appli:

https://guide.openenergymonitor.org [...] /solar-pv/
 
j'y connais pas grand chose en prog HTML/CSS mais j'suis motivé et débrouillard si on me donne des "pistes"    
 
merci à vous!
 
 

 
chart.js
 
Par contre, c’est surtout du JS/DOM et quand tu dis que tu n’y connais pas grand chose, je pense que tu vas probablement galérer.  
Tu peux aussi le faire toi-même, mais ce sera sûrement de la merde, pas responsive et qui ne s’adaptera même pas au values du graph...

Merci pour ton retour    
 
j'ai googlé et effectivement c'est pile ce que je cherche! je vais regarder ça tranquillement je DOIS y arriver    
 
merci!  

Plotly aussi.

merci pour la réponse!    
 
En fait concrètement je suis en train de créer une interface domotique à l'aide de programme jeedom. C'est un "hub" pour interfacer toute la domotique...
Ce dernier est apparemment "compatible" (désolé je ne sais pas si c'est le bon terme   ) avec la lib Highcharts comme l'indique ce post dans le forum :
 
https://www.jeedom.com/forum/viewto [...] 24&t=31768
 
le site de la lib indique plusieurs exemple qui correspondraient tout à fait à ce que je veux! reste à chercher les valeurs dans la base de donnée de jeedom    
 
https://www.highcharts.com/demo

Qui d'entre vous a abandonné REST au profit de GrapQL (ou autre) ?
La question m'intéresse particulièrement pour ceux qui n'utilisent pas React.
C'est une réflexion un peu récurrente depuis quelques temps de mon côté, autant j'apprécie REST (like, on n'est pas RESTful dans ce que l'on produit à l'heure actuelle) pour faire communiquer deux middlewares, autant pour du front web, j'en revient de plus en plus, notamment à cause de la lourdeur du modèle et du nombre d'échanges réseau.

Angular + GRPC + server GO ici
 
Les protobuf c'est le bien (contrat WS partagé entre client et server) avec generation auto de lib et ce, dans n'importe quel language.
 

Bon, je relance le développement de mon site de cul c'est décidé
 
Par contre pour les technos ... le dernier POC était en FuelPHP

Question d'un mec qui connaît pas Vue (moi ), c'est possible de faire dès maintenant du TypeScript, ou il vaut mieux attendre la V3 ?
Caveat?

 
Pourquoi faire du TS quand tu peux l'éviter. Its a feature.

 
Parce que je le vois comme un avantage (je comprend pas trop le "quand tu peux l'éviter" du coup).

Si tu utilises le cli oui c'est possible (par exemple):
 
https://alexjover.com/blog/integrat [...] e-project/
 
Perso je suis un fan de typescript, mais sous vuejs, je ne l'utilise pas... Pas le besoin, les components sont souvent assez petit, et facilement lisible, donc le besoin de typer devient nettement moins important...

Salut à tous,

Après un MVP (sorte de démo très simple) qui a été développé en PHP/MySQL, un prospect me demande de chiffrer une webapp finale, afin de pouvoir la développer.
Je ne pense pas que cela soit bien que l'application finale soit développée en PHP/MySQL...
Donc je ne sais pas trop comment m'organiser pour trouver
- Le language à utiliser (React, Angular, Node..)
- Les partenaires (freelance, sociétés)
- L'aspect sécurité.

Le MVP a coûté 4k€, j'estime à la grosse louche l'application finale pour 50-60k€.

Est-ce que vous avez des conseils là-dessus ?
Et éventuellement, si cela intéresse des gens, on peut en discuter

Merci,

Et pourquoi ça ?

Parce que je me dis qu'il y a mieux aujourd'hui, SAUF que je ne connais pas les autres langages.
(React/Node/etc...)
L'application se doit d'être sécurisée, et de pouvoir évoluer facilement (il y a beaucoup de règles de routages qui peuvent changer).
Le MVP a été fait via un framework MVC, ça fonctionne bien, mais c'est peut-être "just" pour les prospects que j'ai en face (groupes dans la finance).
Le projet est viable, les budgets peuvent être là facilement, mais faut juste que je fasse une estimation de budget et de temps pour développer un truc costaud et fiable. Si des gens veulent se joindre
Je me positionnerai en chef de projet perso.
Je suis preneur d'avis

 
Les langages ont tous evolue, je trouve un peu surprenant de dire que tel langage est mieux qu'un autre sur les aspects securite et routage, qui sont des besoins classiques et eprouves en php comme dans d'autres langages.
Vu la description tres succinte du projet je pense que tous les langages sont de bons candidats, cela depend plus de quels devs tu as sous la main, de ce qu'ils veulent afire, de quelles contraintes de deploiement tu as, quel outillage tu as besoin, ce genre de choses.

Ok.
Et même en PHP/MySQL (faut gérer les clefs étrangères tout ça), un FW de prédilection ? Genre faut-il préférer Zend, Symfony, Laravel..
J’imagine que ça dépend des devs mais peut-être qu’un FW est plus sûr qu’un autre.