Catégories
CSS javascript React

Où je dis du bien du CSS-in-JS

Il n’y a que les imbé­ciles qui ne changent pas d’avis et c’est mon avis depuis toujours

Coluche

J’ai toujours regardé avec dédain les tenta­tives des dev JS pour contour­ner l’écri­ture de CSS mais je commence à consi­dé­rer que les outils de CSS-in-JS type Emotion sont la bonne solu­tion pour les webapp React.


J’ai été inté­gra­teur, à faire de la belle CSS sépa­rée du code HTML. On finit quand même vite par construire des monstres ou se prendre les pieds dans le tapis dès qu’on fait plus de quelques pages types.

Pour résoudre le problème, élimi­nons le. C’est ce que proposent les conven­tions comme BEM. Si je cari­ca­ture, il s’agit prin­ci­pa­le­ment de reti­rer les sélec­teurs CSS un attri­buant une ou plusieurs classes spéci­fiques à chaque contexte. C’est fran­che­ment moche mais ça fonc­tionne.

CSS-Modules va un peu plus loin. Le prin­cipe est le même mais on permet au déve­lop­peur d’uti­li­ser un nommage plus agréable. C’est l’ou­til de géné­ra­tion qui gère la complexité au lieu du déve­lop­peur.


J’avoue que j’aime bien CSS-modules. C’était mon favori jusqu’à présent.

Ça revient à juste gérer un fichier par compo­sant en se limi­tant à des sélec­teurs très simples pour ne pas créer de conflits de spéci­fi­cité. On reste sur du CSS stan­dard et sur une approche proche de mes habi­tudes histo­riques. Mieux : L’in­té­gra­tion peut se faire indé­pen­dam­ment du langage de déve­lop­pe­ment de l’ap­pli­ca­tif.

C’est top mais ça se base sur des compo­sants qui ne bougent pas beau­coup, dont on connait à l’avance tous les états.

Dès qu’il s’agit de cumu­ler plusieurs états, le résul­tat dépend de l’ordre d’écri­ture dans la CSS. Parfois c’est bien prévu, parfois non.

Dès qu’il s’agit de rendre des choses très dyna­miques, il faut de toutes façons sortir des CSS modules. Vous voulez que dans la vue large les items de navi­ga­tion se colorent au survol en fonc­tion de la caté­go­rie desti­na­tion déter­mi­née dyna­mique­ment mais qu’ils utilisent la couleur neutre dans la vue réduite desti­née aux mobiles ? Vous êtes à poil et il va falloir compo­ser avec d’autres façons d’injec­ter des CSS, peut-être même tâton­ner sur les prio­ri­tés entre classes.


Les classes utili­taires et CSS atomiques à la Tachyon sont là pour indus­tria­li­ser en pous­sant encore plus loin.

J’ai une classe par valeur à appliquer : .ms7-ns applique la septième valeur du cata­logue (7) comme taille hori­zon­tale maxi­mum (ms pour max-width) si la fenêtre a une taille supé­rieure au point de rupture « small » (ns pour non-small).

Ça n’offre quasi­ment aucune abstrac­tion utile (unifor­mi­ser les valeurs on a déjà plein d’ou­tils plus effi­caces). C’est vite cryp­tique, lourd, et mons­trueux dès qu’on multi­plie les valeurs et les points de rupture possibles.

Le seul inté­rêt par rapport à écrire direc­te­ment les attri­buts style c’est que ça permet d’ac­cé­der aux media query et aux pseudo-sélec­teurs.

Malheu­reu­se­ment non seule­ment ça ne résout pas les conflits de prio­ri­tés mais ça les empire. Si je spécia­lise un compo­sant exis­tant en y ajou­tant une classe liée à une direc­tive déjà présente, je joue à la roulette russe. Il faut abso­lu­ment que mon compo­sant initial prévoit lui-même tous les cas possibles pour savoir quelle classe injec­ter et ou ne pas injec­ter. Pas d’al­ter­na­tive.

J’ai vrai­ment l’im­pres­sion d’un retour en arrière mons­trueux avec ces CSS atomiques, cumu­ler les défauts sans aucun avan­tage, et c’est proba­ble­ment ce qui m’a fait reje­ter par prin­cipe les CSS-in-JS jusqu’a­lors.


Les CSS-in-JS c’est fina­le­ment pous­ser la logique de Tachyons un cran plus loin. Quitte à déci­der de tout dans le code HTML, autant écrire direc­te­ment les styles à cet endroit là en utili­sant la vraie syntaxe CSS et en y ajou­tant la possi­bi­lité d’ac­cé­der aux media query et aux pseudo-sélec­teurs.

Emotion c’est ça. On est à la croi­sée entre le « j’écris tout dans un attri­but style » et le « j’at­tache un module CSS ».

En fonc­tion­ne­ment basique c’est comme un CSS module sans le sélec­teur. Je donne les direc­tives en CSS on ne peut plus clas­siques et j’ai accès aux media query, aux pseudo-sélec­teurs et aux anima­tions avec une syntaxe proche de ce que font les prépro­ces­seurs habi­tuels (et en phase avec la direc­tion que prend la syntaxe CSS elle-même).

const style = css`
padding: 32px;
background-color: hotpink;
font-size: 24px;
border-radius: 4px;
&:hover {
color: blue;
}
`

Je peux direc­te­ment ajou­ter le résul­tat aux classes CSS de mon compo­sant. Il se char­gera de géné­rer un nom de classe, de créer la CSS corres­pon­dante dans le docu­ment, et de lier les deux, comme avec CSS-Modules.

L’exemple est peu parlant. On a juste l’im­pres­sion d’un CSS-Modules écrit dans le fichier JS.

L’avan­tage c’est que je ne suis pas limité aux valeurs en dur. Je peux avoir des valeurs dyna­miques venant de mon Javas­cript ou de mon thème, et je n’en limite pas les effets à ce que me permettent les variables CSS.

Je peux aussi réuti­li­ser, compo­ser ou surchar­ger un élément ou un bloc de styles avec un autre sans risque de conflit de prio­rité.


Tachyons me donnait l’im­pres­sion de cumu­ler les incon­vé­nients, ici j’ai vrai­ment l’im­pres­sion de cumu­ler les avan­tages.

La seule contrainte c’est que mon code CSS se retrouve dans mes fichiers JS. C’est moche quand c’est dit ainsi mais pour une app en React, on a de toutes façons un fichier par compo­sant HTML et ça a du sens de grou­per HTML, JS et CSS lié au compo­sant ensemble quand ils sont forte­ment liés. C’est d’ailleurs le choix de VueJS.

Ce n’est forcé­ment pas adapté à tout, et si vous voulez rester géné­riques les CSS-Modules sont à mon avis l’op­tion la plus saine, mais pour un code React je crois que c’est là que je commen­ce­rai par défaut désor­mais.

Catégories
Développement informatique javascript Sécurité informatique

Une histoire de dépen­dances

Le main­te­neur d’un paquet NPM n’a plus eu envie et a donné la main à un tiers. Ce tiers a injecté un code mali­cieux dans une version publique et poten­tiel­le­ment infecté pas mal de monde. Ça n’a été détecté qu’au bout de deux mois et demi alors que le paquet est utilisé un peu partout.


J’en vois qui lancent des blâmes ou qui se moquent sur l’ac­tua­lité du paquet NPM mali­cieux. Ça défoule mais : Faites-vous mieux ? Permet­tez-moi d’en douter très très forte­ment.

Le moindre projet React, Symfony ou Rails, c’est une centaine de dépen­dances directes et indi­rectes, certaines proviennent de sources dont vous n’avez jamais entendu parler. J’ai listé trois frame­works mais c’est bien la même chose sur les autres langages/tech­nos.

C’est bien le sujet : Sauf si vous avez la taille d’un Face­book/Google ou la criti­cité d’un Thalès ou d’un état, vous n’avez ni les moyens de passer des années-homme à tout reco­der en interne, ni les moyens d’au­di­ter chaque source à chaque mise à jour (si tant est que ça suffise).

Même ceux que j’ai nommé, je ne suis pas certains qu’ils le fassent toujours, sur tous les types de projet. Je suis même assez convaincu du contraire. Le ratio béné­fice/risque n’est juste pas assez impor­tant pour ça. Les moyens et les délais ne sont pas dimen­sion­nés pour.


Alors moquez-vous, de ceux qui utilisent NPM, de ceux qui ne contrôlent pas l’en­semble des dépen­dances, mais vous ne faites proba­ble­ment pas mieux. Il y a pas mal d’hy­po­cri­sie dans les réac­tions que je vois passer.

Ne blâmez pas non plus le main­te­neur d’ori­gine. Lui ne vous a jamais rien promis. C’est même dit expli­ci­te­ment dans la licence « aucune garan­tie d’au­cune sorte ». Ce n’est pas parce que d’autres utilisent son code gratui­te­ment qu’il aurait magique­ment des comptes à rendre. En fait avoir passé la main est plutôt quelque chose d’en­cou­ragé dans l’open source. S’il n’y avait pas eu cette issue, il aurait plutôt fallu le remer­cier.


Alors quoi ? Alors rien.

Le problème a été résolu. Si ça arrive trop souvent alors ça chan­gera le ratio béné­fice/risque et la commu­nauté évaluera le fait d’avoir trop de dépen­dances tierces un (tout petit) peu plus néga­ti­ve­ment, et ainsi de suite.

La ques­tion inté­res­sante que personne ne semble poser c’est celle de l’hon­nê­teté du main­te­neur d’ori­gine. A-t-il vrai­ment passé la main ? et s’il l’a fait, est-ce qu’il en a tiré un béné­fice tout en soupçon­nant ce qui pouvait se passer ? C’est à peu près la seule chose qui pour­rait à mon sens lui faire porter une quel­conque respon­sa­bi­lité.

Catégories
javascript navigateurs et API Sécurité informatique

Comment on fait de la crypto dans le navi­ga­teur ?

Faire de la cryp­to­gra­phie dans le navi­ga­teur se révèle bien plus simple que prévu.

Lais­sez tomber les portages de libso­dium & co. Quasi­ment tous les navi­ga­teurs supportent désor­mais une API native dédiée. Seul IE11 ne le fait pas tota­le­ment mais il a au moins le mini­mum qu’est la géné­ra­tion de nombres réel­le­ment aléa­toires. Ceux qui veulent vrai­ment pour­ront complé­ter l’im­plé­men­ta­tion d’IE11 avec un poly­fill sans risquer de problème de sécu­rité.

Il y a plein de jolis exemples sur qnimate mais certaines choses datent un peu. J’ai tenté de résu­mer ici pour ceux que ça inté­resse. Ici pour du déchif­fre­ment à partir d’une clef secrète.

Avant-propos

Je ne suis pas un expert en chif­fre­ment et ce genre de choses est toujours à manier avec précau­tion. Si vous faites quelque chose de sérieux, ne vous conten­tez pas d’exemples et embau­chez quelqu’un qui sait.

Rien que choi­sir l’al­go­rithme perti­nent demande de savoir ce qu’on fait. AES-CTR semble perti­nent pour mon cas d’usage où n’ai pas besoin de véri­fier l’au­then­ti­cité du message, où je n’ai pas envie de me colti­ner les ques­tions de padding, et où je serai heureux de profi­ter des multiples cœurs des smart­phones.

Si l’al­go­rithme choisi ou autre chose vous dérange et que vous en savez plus que moi, n’hé­si­tez pas à commen­ter.

Récu­pé­rer une clef

Le plus simple est de récu­pé­rer direc­te­ment une clef au format JSON Web Key (en gros la clef en base64url plus un peu de méta­don­nées). Dans ce cas il suffit de passer par importKey :

const crypto = window.crypto.subtle;

const jwk = {
  "kty": "oct",
  "use": "enc",
  "k": "SDRSTgdOpUGfgn3iAwiC1cpzsevLM98r_6ehMXlK1Gk",
  "alg": "A256CTR"
};
const algo = {name: "AES-CTR"};
const exportable = false;
const usage = ["decrypt"];

const key = await crypto.importKey("jwk", jwk, algo, exportable, usage);
Déri­ver une clef

Si on veut partir d’une phrase secrète mémo­ri­sable et non d’une clef complète, on commence par créer une clef tempo­raire et on utilise un algo­rithme de déri­va­tion comme PBKDF2.

Malheu­reu­se­ment pour créer cette première clef il faut passer par un TextEn­co­der et ArrayBuf­fer. peut toujours déri­ver la clef à partir de là. TextEn­co­der n’existe pas sous Edge et IE11, il vous faudra utili­ser une fonc­tion comme uniba­bel qui fait ça pour vous.

const crypto = window.crypto.subtle;
const encoder = TextEncoder();

const passphrase = "l'eau ça mouille, le feu ça brûle";
const buffer = encoder.encode( passphrase );
const d_algo =  {name: 'PBKDF2'};
const d_exportable = false;
const d_usage = ['deriveBits', 'deriveKey'];
const d_key = await crypto.importKey('raw', buffer, d_algo, d_exportable, d_usage);

const deriv = { 
  name: 'PBKDF2',
  salt: encoder.encode( "c'est le week-end !" ),
  iterations = 25,
  hash: 'SHA-256',
};
const algo = {name: "AES-CTR", length: 256}; 
const exportable = false; 
const usage = ["decrypt"];

const key = await crypto.deriveKey(deriv, d_key, algo, exportable, usage);

La sécu­rité de tout ça dépend de la longueur et de l’uni­cité de votre phrase secrète initiale. À vous de trou­ver le bon compro­mis entre la sécu­rité et la puis­sance des smart­phones qui risquent d’uti­li­ser votre code. Le 25 ici est pure­ment arbi­traire et le temps de calcul néces­saire est propor­tion­nel.

Déchif­frer

Déchif­frer n’est pas plus diffi­cile.

Le vecteur d’ini­tia­li­sa­tion (iv) et la donnée chif­frée (encryp­ted) sont atten­dus sous forme d’Ar­rayBuf­fer. Il faudra de nouveau passer par uniba­bel ou une autre solu­tion si vous avez ça sous forme de chaîne binaire ou codé en base64.

Le résul­tat de decrypt() vous est retourné sous la même forme. S’il est petit le plus simple est d’uti­li­ser TextDe­co­der ou uniba­bel. Si vous avez quelque chose de plus volu­mi­neux vous pouvez aussi passer par un Blob et un FileRea­der.

const crypto = window.crypto.subtle;
const decoder = TextDecoder

const key = ...
const iv = ...
const encrypted = ...

const algo = { name: 'AES-CTR', iv: iv }
const buffer = await crypto.decrypt(alg, key, encryted);
Catégories
Développement web javascript Sécurité informatique

Donnée confi­den­tielle dans une session de navi­ga­tion.

Je partage, ça peut servir à d’autres. Je cher­chais à garder confi­den­tiel une infor­ma­tion confi­den­tielle le temps d’une session de navi­ga­tion. En gros je cher­chais un genre de cookie de session mais qui reste côté client sans jamais tran­si­ter sur le réseau.

Le localS­to­rage est top mais il persiste au delà de la session de navi­ga­tion. Le sessionS­to­rage est top mais il n’est pas partagé entre les onglets.

Visi­ble­ment certains se sont penchés sur la ques­tion il y a quelques années et sont reve­nus avec une solu­tion toute bête mais effi­cace : Faire dialo­guer les diffé­rents sessionS­to­rage en surveillant les écri­tures dans le localS­to­rage.

C’est tout con, ça prend juste 20 lignes, mais il fallait y penser.

Merci Rik

Catégories
Développement web javascript

[Aide] Commu­ni­ca­tion entre une page et une exten­sion navi­ga­teur

J’ai une page qui fait des trai­te­ments javas­cripts basés sur des appels XHR authen­ti­fiés vers son origine et sur des commu­ni­ca­tions en window.postMes­sage avec des <iframe>. Elle n’a besoin d’au­cune permis­sion privi­lé­giée, c’est juste une page web avec une origine normale.

J’ai­me­rais pouvoir inter­ro­ger cette page depuis une exten­sion Fire­fox et qu’elle me commu­nique le résul­tat de ses trai­te­ments, mais sans que ça n’af­fiche la page à l’uti­li­sa­teur.

Au départ j’ima­gi­nais que l’ex­ten­sion pouvait lancer une <iframe> cachée et discu­ter avec elle en postMes­sage. On me dit que ce n’est pas possible.

Embarquer direc­te­ment le code de la page dans l’ex­ten­sion n’est pas envi­sa­geable pour des raisons de sécu­rité (et on ne ferait que repor­ter le problème vu que cette page lance elle-même des iframes pour commu­niquer avec elles).

Dis, public, est-ce que tu aurais une sugges­tion ou une piste à explo­rer ?

Catégories
javascript

Variables et constantes — Javas­cript 103

Travailler avec ES2015 c’est quelques chan­ge­ments sur les décla­ra­tions des variables.

Premier chan­ge­ment : Les modules ES2015 sont impli­ci­te­ment en mode strict. Y utili­ser une variable non décla­rée provoque une erreur. Ce seul chan­ge­ment est une béné­dic­tion vu l’ubuesque compor­te­ment par défaut de Javas­cript. Il reste que ça ne chan­gera pas grand chose pour qui utili­sait déjà un outil d’ana­lyse de code (linter).

Pour décla­rer les variables nous avons aussi le nouveau mot clef let en complé­ment de l’an­cien var.  La portée est alors limi­tée au bloc de code parent le plus proche (if, while, func­tion, for…) au lieu d’être éten­due à toute la fonc­tion parente.

let a = 2;
for(let b=1; b<3; b++) {
  let a = 3;
  a = 4;
}
console.log(a); // 2 et non 4

Au début j’étais enthou­siasmé. J’ai trouvé excep­tion­nel de pouvoir travailler avec des variables jetables le temps de quelques lignes et j’ai pensé éviter de nombreuses réuti­li­sa­tions par erreur.

À l’usage c’est un ajout sympa mais pas si révo­lu­tion­naire. Si c’est pratique c’est surtout pour gérer les ferme­tures syntaxiques (closure) au sein des boucles. Le reste du temps ça n’a que peu d’in­fluence quand on a des fonc­tions de taille et de niveau d’im­bri­ca­tion raison­nables.

var fns = [ ];
for(var i=1; i<3; i++) {
  fns.push( function () { console.log(i); } );
}
var fn = fns[0];
fn(); // affichera 3 et non 1

//----

fns = [ ];
for(let j=1; j<3; j++) {
  fns.push( function () { console.log(j); } );
}
fn = fns[0];
fn(); // affichera 1

Je me demande si ça pour­rait être la portée par défaut dans un langage. Visi­ble­ment certains pensent que non mais je n’ai pas été convaincu par l’ar­gu­men­taire.

L’autre nouvel arrivé c’est const. Décla­rée ainsi la variable a la même portée qu’un let mais on ne peut pas y affec­ter une valeur diffé­rente.

Là aussi c’est pas mal d’en­thou­siasme. Une variable qui est modi­fiée sans aver­tis­se­ment par une ferme­ture lexi­cale ou un module tiers, ça fait parfois des dégâts.

Le problème c’est que ça ne protège pas vrai­ment de ça. Si on ne peut pas affec­ter de nouvelle valeur au même nom de variable, la valeur elle même n’est pas immuable. On peut toujours faire chan­ger d’état un objet ou modi­fier les éléments d’un tableau. Domma­ge…

const tab = [ ];
tab[3] = 4; // ne provoque pas d'erreur mais change `tab`

const obj = { 
  var priv = 2; 
  this.chg = function() { priv = 3; };
};
obj.chg(); // `obj` vient de changer d'état silencieusement

tab = [1, 2, 3]; // là par contre on génère une erreur.

Pour obte­nir une vraie sûreté il faut utili­ser des des struc­tures de données expli­ci­te­ment prévues pour. On ne peut plus utili­ser les raccour­cis habi­tuels { } ou [ ] et l’ins­tan­cia­tion devient bien plus verbeuse. Facile d’ou­blier par inat­ten­tion et par habi­tude.

import immutable from "immutable";
const map = Immutable.Map({a:1, b:2, c:3});
// map ne changera plus jamais de valeur

Le problème c’est que tous les modules tiers conti­nuent à utili­ser les struc­tures de données variables habi­tuelles. Malheu­reu­se­ment des modules tiers, vue la pauvreté de la biblio­thèque stan­dard de Nodejs, on en utilise des tonnes,  y compris pour des fonc­tions de base.

Pour se proté­ger vrai­ment des chan­ge­ments d’état il faudra non seule­ment utili­ser expli­ci­te­ment nos struc­tures de données immuables (aie), mais en plus faire régu­liè­re­ment des conver­sions quand on commu­nique avec des modules tiers (ouch).

Il y a tout lieu de penser qu’on finira par avoir des données variables et d’autres immuables, suivant d’où elles viennent et comment elles sont décla­rées. Il faudra réflé­chir à chaque utili­sa­tion, parfois remon­ter à la créa­tion de la donnée. Possible même que le compor­te­ment de const avec les struc­tures de données natives nous incite plus d’une fois à nous croire en sécu­rité alors que ce ne sera pas le cas.

Pour moi c’est le scéna­rio du pire. Non seule­ment on complexi­fie le code (plus verbeux) et la charge cogni­tive (savoir à chaque fois quel est le type de variable et le type de données), mais en plus on garde des risques.

Pour jouer à ça il aurait fallu que le langage s’as­sure que ce qu’on déclare comme tel soit réel­le­ment immuable, jusqu’en profon­deur. Je comprends très bien pourquoi ça aurait été diffi­cile voire impos­sible, mais du coup ce const m’a l’air d’une vraie fausse bonne idée. Domma­ge…

Pour autant je me prends quand même à utili­ser const pour les litté­raux. Ça ne coûte pas grand chose et ça fixe par écrit l’in­ten­tion que j’ai en tête. Même si je n’y suis pas obligé, je fais tout de même atten­tion à garder let quand j’uti­lise un tableau ou un objet natif. J’ai trop peur d’in­duire en erreur le prochain déve­lop­peur qui passe (d’au­tant que ce sera proba­ble­ment moi).

Je jette­rai peut-être de nouveau un œil à immu­table.js si une partie signi­fi­ca­tive des modules s’y conver­tit. Entre temps le ratio béné­fices/(risques+­dé­fauts) me parait assez faible.


Au delà de ces ques­tions de décla­ra­tions, j’en tire un avis plutôt néga­tif sur la propa­ga­tion des variables en Javas­cript. On fait des ferme­tures lexi­cales de partout et on ne maitrise pas bien les effets de bord. Pas éton­nant que les déve­lop­peurs cherchent à avoir des variables et des struc­tures de données immuables ! Si la propa­ga­tion des variables était plus saines au départ, ce besoin ne ferait pas surface ainsi.

var i = 1;
function hello10times() {
  for(i=1; i<10; i++) {
    console.log("hello ");
  }
}
hello10times();
// oups ! i a changé et vaut désormais 10

PHP est plus strict (ouch, dire ça me fait mal) : Les variables ne sont pas décla­rées mais ne sont jamais héri­tées d’un contexte parent sauf à le décla­rer expli­ci­te­ment, avec global pour les variables globales, ou use pour les ferme­tures lexi­cales. On peut toujours faire des effets de bord assez moche, mais on les voit venir assez faci­le­ment.

$i = 3;
$hello10times = function () {
  for (i=1; i<10; i++) {
    echo "hello ";
  }
}
// $i vaut toujours 3

$hello10times = function () use ($i) {
 for (i=1; i<10; i++) {
 echo "hello ";
 }
}
// $i vaut 10 mais là c'est forcément intentionnel

La visi­bi­lité des variables de Python est plus proche de ce que fait Javas­cript mais, sauf à le décla­rer expli­ci­te­ment, si on utilise une variable d’un contexte parent, c’est en lecture seule. On garde des effets de bord, mais c’est déjà plus limité (bon, en échange savoir si la variable utili­sée est locale ou héri­tée n’est pas toujours super expli­cite).


D’ailleurs, quitte à parler d’ex­pli­cite, je trouve dommage d’avoir à décla­rer mes variables en Javas­cript. Il n’y a pas vrai­ment le choix vu l’his­to­rique du langage mais ça reste agaçant vue la faible valeur ajou­tée de la chose, surtout quand je vois avec Crys­tal que même un langage à typage statique peut s’en passer.

Si j’avais à créer un langage de zéro je pense que j’ap­pré­cie­rais de ne pas avoir à décla­rer mes variables, éven­tuel­le­ment leur donner la portée par défaut de let, mais avec la décla­ra­tion expli­cite de PHP pour les ferme­tures lexi­cales (avec peut-être une excep­tion pour les petites fonc­tions anonymes d’une unique ligne/expres­sion).

L’idée de const me plait beau­coup, mais unique­ment si le langage se révèle capable de réel­le­ment rendre la donnée tota­le­ment immuable, et ça en profon­deur. À minima le freeze de Ruby serait une demie-solu­tion (une demie seule­ment parce qu’il faut penser à faire un freeze récur­sif sur un clone de tous les objets avant leur affec­ta­tion par const, ce qui est assez pénible). Celui de Javas­cript ne me semble pas effi­cace pour bloquer les chan­ge­ments d’état d’objets qui contiennent des proprié­tés privées (implé­men­tées via des ferme­tures syntaxiques).

Tiens, ça pour­rait même être inté­gré au langage : si l’af­fec­ta­tion se fait avec := plutôt qu’a­vec =, alors ni la variable se voit affec­ter une copie immuable de la donnée, sans possi­bi­lité de modi­fi­ca­tion ou ré-affec­ta­tion.

Si vous déve­lop­pez le nouveau langage de demain, vous avez désor­mais mon cahier des charges :-)

Catégories
javascript

Résoudre le call­back hell — Javas­cript 102

Après la mise en place, il est peut-être temps de faire un premier script. J’ai tenté un petit script que j’ai fait la veille en ruby : lister toutes les images dans une hiérar­chie de réper­toires et faire un gros fichier Json qui réca­pi­tule les diffé­rentes tailles.

Faire un petit fichier outil CLI à l’aide de comman­der.js : un call­back. Lister les fichiers d’un réper­toire : un call­back. Lire les exif : un call­back. Écrire dans un fichier JSON : un call­back.

Bon, lire et écrire peuvent se faire en synchrone sans call­back – et dans mon cas précis ça ne chan­ge­rait proba­ble­ment rien – mais je suis là aussi pour apprendre comment faire pour plus tard dans cet écosys­tème.

Une hiérar­chie de quatre fonc­tions de rappel pour ce qui m’a pris 5 à 10 lignes tout mouillé en Ruby, ça me fait mal. J’avoue, je suis presque surpris que la trans­for­ma­tion en JSON ne me demande pas un call­back.

Me voici en plein call­back hell. Le problème est connu. J’ai bête­ment pensé qu’on me donne­rait une solu­tion rapi­de­ment, un outil ou un usage à suivre.

On me pointe vers les promesses ES2015 mais l’API Node et tous les modules en ligne conti­nuent à utili­ser des call­back. Sérieu­se­ment, personne n’a cher­ché à présen­ter l’API Node direc­te­ment en promesses ?

C’est donc à moi de trans­for­mer chaque méthode ou chaque module pour qu’il utilise des promesses. Promi­sify semble être la baguette magique pour ça. À partir de là il suffit de conver­tir chaque module pour enchaî­ner des promesses (atten­tion aux écueils).

Fran­che­ment ça reste assez moche. Des gens biens me pointent vers les systèmes à base de géné­ra­teurs (je recom­mande la lecture de ce lien) et le module co. Le code résul­tant est déjà bien plus lisible malgré les arti­fices.

On me rappelle alors les async / await (là aussi, je recom­mande la lecture). Je crois que c’est seule­ment main­te­nant, après cette explo­ra­tion, que je comprends l’in­té­rêt et le fonc­tion­ne­ment. Parfait, si ce n’est qu’il faut choi­sir presque au hasard entre trois plugins diffé­rents pour ajou­ter la fonc­tion­na­lité à Babel.

Atten­tion, ce n’est pas magique. Il faut se rappe­ler que ce n’est qu’une surcouche aux promesses, et il y a quelques écueils (lien indis­pen­sable si vous comp­tez utili­ser async/await) à bien connaitre là ici aussi, entre autres pour ne pas perdre les excep­tions dans un trou noir.

Je me retrouve avec un code qui a l’air rela­ti­ve­ment élégant mais la réalité me rattrape : Visi­ble­ment quasi aucun code en produc­tion ne fonc­tionne ainsi. Une majo­rité des gens utilisent encore des call­backs, les autres se sont conten­tés des promesses. Est-ce une bonne idée de déjà viser les async/await ?


Il reste aussi que j’ai l’im­pres­sion de retrou­ver le mode multi-tâche coopé­ra­tif de Micro­soft Windows 3.1 en moins bien inté­gré. Je ne vois aucune raison pour que la biblio­thèque stan­dard m’im­pose des call­backs, des promesses ou des async/await à tout bout de champ plutôt que de gérer ça en interne.

L’OS sait déjà passer à un autre proces­sus quand mon programme est en attente d’une i/o. Si la machine virtuelle du langage veut gérer plusieurs fils d’exé­cu­tion en interne pour opti­mi­ser le proces­seur, qu’elle le gère elle-même via l’API mise à dispo­si­tion. C’est à elle d’iden­ti­fier que je veux ouvrir un fichier et de savoir qu’elle peut favo­ri­ser un autre fil d’exé­cu­tion en atten­dant que le disque me remonte la donnée. Je trouve ahuris­sant que ces méca­nismes débordent sur mon code et le complexi­fient ainsi.

Oui, les promesses ne servent pas qu’à gérer la lenteur des i/o et faire coopé­rer les diffé­rents fils d’exé­cu­tions de la machine virtuelle V8 mais c’est quand même pour ça qu’on me les impose partout dans l’API de Node.js. Ça en devient même un style de program­ma­tion et les modules proposent des call­backs partout et pour tout (à vue de nez, y compris là où ça n’a pas vrai­ment de sens, à mon humble avis par mime­tisme).

Promesses, async, call­backs… J’adore tous ces concepts, mais quand j’en ai besoin moi, pas pour compen­ser les choix d’ar­chi­tec­ture du moteur sous-jacent.

Javas­cript a énor­mé­ment évolué, dans le bon sens. Côté syntaxe ES2015 et suivant donnent un résul­tat qui m’at­tire beau­coup. Le fonc­tion­ne­ment et l’API de Node.js me semblent pour l’ins­tant gâcher tout ce résul­tat. Un beau langage avec un boulet aux pieds.

Catégories
javascript

Recom­mençons à zéro — Javas­cript 101

PHP a été mon langage favori pendant presque 10 ans. Ruby l’a suivi pour à peu près la même durée. Javas­cript a été l’ou­til secon­daire pas très atti­rant pour quand il n’y a pas d’autre choix, c’est à dire sur navi­ga­teur.

Avant-hier j’ai eu un petit pince­ment de frus­tra­tion en cher­chant à déstruc­tu­rer un diction­naire lors d’une affec­ta­tion. Ruby n’a toujours qu’une demie solu­tion pas très élégante. PHP et Javas­cript ont tous deux énor­mé­ment évolué entre temps, au point qu’on ne les recon­nait qu’à peine.

Si Ruby garde des capa­ci­tés inéga­lées pour faire de la méta-program­ma­tion, 10 ans c’est peut être le bon moment pour reprendre un autre langage de zéro.

Je fais du web, j’aime beau­coup l’idée de l’iso­mor­phisme, il me faudra donc quelque chose qui sache compi­ler en Javas­cript. Elm pour­rait me faire du pied vu sa gestion des types mais c’est un pari osé consi­dé­rant qu’il est encore absent côté serveur.

Ça sera donc Javas­cript. D’abord pour quelques scripts en ligne de commande, puis peut-être des appli­ca­tions plus sérieuses.

Reprendre de zéro c’est l’oc­ca­sion de lais­ser le passé derrière soi et recom­men­cer comme si c’était un nouveau langage. Je ne prends que les dernières versions et outils récents dans la chaîne, voire ce qui n’est pas encore sec mais qui arri­vera demain.

Il s’agit aussi de reprendre de zéro, pour apprendre. Exit donc les boiler plate et autres kits de démar­rage rapide.


Première étape : instal­la­tion de npm (3.10.3) et nodejs (6.3.1).

# Sur Mac avec Homebrew (http://brew.sh/)
brew install nodejs

et initia­li­sa­tion du projet (un peu de doc si besoin pour aider à remplir)

mkdir my-js-project
cd my-js-project
npm init

Ensuite l’idée c’est d’uti­li­ser le nouveau Javas­cript moderne et ne cher­cher aucune compa­ti­bi­lité passée. Instal­la­tion de Babel pour gérer ES2015 et + :

npm install --save-dev babel-cli

La plupart des sites recom­mandent des preset pour ES2015 ou React mais visi­ble­ment Nodejs 6.x gère déjà l’es­sen­tiel des fonc­tions nati­ve­ment. Il existe au moins trois preset spéci­fiques pour Nodejs 6 mais la seule confi­gu­ra­tion commune aux trois est le plugin qui trans­forme les modules ES2015 en modules Commonjs. Je suis donc reparti de là :

npm install --save-dev babel-plugin-transform-es2015-modules-commonjs

Puis l’édi­tion du .babelrc :

{
  "presets": [ ],
  "plugins": [ "transform-es2015-modules-commonjs" ]
}

Si quelque chose manque à Nodejs 6, il faudra que j’ajoute le plugin corres­pon­dant. Voici les plugins sur lesquels mes trois presets étaient en désac­cord :

  • trans­form-es2015-func­tion-name,
  • syntax-trai­ling-func­tion-commas,
  • trans­form-es2015-destruc­tu­ring,
  • trans­form-es2015-para­me­ters,
  • trans­form-object-rest-spread,
  • trans­form-es2015-sticky-regex,
  • trans­form-es2015-unicode-regex,
  • trans­form-es2015-modules-commonjs,
  • et trans­form-class-proper­ties.

Je n’ai pas pris le temps de les tester un par un pour voir lesquels étaient réel­le­ment néces­saires pour pas. Si quelqu’un a le courage de faire le travail…

Reste à enfin permettre d’exé­cu­ter un premier script. J’ai tenté de suivre les usages en mettant les sources dans src/ et les fichiers compi­lés dans lib/ avec un index.js comme fichier prin­ci­pal.

mkdir lib
echo "Compiled files will go here." > lib/README.md
echo "Leave these files untouched"  >> lib/README.md
echo "and modify ../src/* instead." >> lib/README.md

mkdir src
echo "Source files will go here." > src/README.md
echo "They should be compiled before any use." >> src/README.md
touch src/index.js

Et la confi­gu­ra­tion du package.json pour lancer tout ça (notez le main qui prend en compte notre nouveau chemin et le scripts qui liste nos deux nouvelles actions) :

{
  "name": "my-project",
  "main": "./lib/index.js",
  "scripts": {
    "build": "babel src -d lib --source-maps",
    "watch": "babel src -d lib --watch --source-maps"
  },
  "devDependencies": {
    "babel-cli": "^6.11.4",
    "babel-plugin-transform-es2015-modules-commonjs": "^6.11.5"
  }
}

Un npm run build permet de compi­ler tous les fichiers, un npm run watch permet de surveiller en temps réel les modi­fi­ca­tions des fichiers sources pour mettre à jour les fichiers desti­na­tion corres­pon­dants.


J’ai ajouté un README, le .giti­gnore proposé par Github pour un projet Nodejs, une licence, et ‘op, vous trou­ve­rez le tout sur Github.

Ça fait déjà pas mal pour toujours aucune ligne de Javas­cript utile.

Quelques feed­back après ce tout petit premier pas :

1– C’est long et complexe

Oui, j’ai cher­ché les ennuis, il existe des boiler plate tout faits, mais je ne crois pas avoir le même problème avec Python, Ruby, PHP ou d’autres.

Le fait d’avoir une étape de compi­la­tion avec Babel n’aide pas mais Java pour­rait en dire tout autant. Pourquoi n’existe-t-il pas un babel init qui lit la version courante de Nodejs, m’ins­talle un .babelrc adapté à cette version et me modi­fie mon package.json pour m’ajou­ter les raccour­cis build et watch ?

Oui, je pour­rais faire une pull-request, mais fallait-il m’at­tendre ?

2– La doc aide peu

Fran­che­ment c’est la plaie. Je ne dirais pas qu’il n’y a aucune doc, mais il y en a dans tous les sens. La plupart ne sont pas à jour, toutes semblent incom­plètes, et il est bien diffi­cile de savoir si telle ou telle a pris en compte les dernières évolu­tions.

Peut-être n’ai-je pas trouvé la bonne réfé­rence ? Dites-moi.

Rien que le npm init n’était indiqué sur aucune doc que j’ai croisé. Pire : si on l’ou­blie il n’y a pas de message rouge très expli­cite pour indiquer que les npm install –save-dev n’au­ront pas l’ef­fet demandé. Il a fallu comprendre qu’il fallait créer un package.json, puis décou­vrir qu’il n’était pas néces­saire de le faire à la main.

Ce n’est que le début. Quand il va s’agir de choi­sir une biblio­thèque ou des outils, je sens que ça va être toute une histoire pour d’y retrou­ver. La doc de setup de Babel en donne un premier aperçu.

J’ai l’im­pres­sion qu’à chaque étape la roue est en pleine recons­truc­tion, et qu’on en a fait plusieurs versions diffé­rentes en paral­lèle, pour tout.

3– Qui a eu l’idée d’uti­li­ser des fichiers de config JSON ?

Je suis aussi assez peu fana aussi des config dans des fichiers Json. J’ai l’im­pres­sion de retrou­ver les fichiers de confi­gu­ra­tion XML de Java. Je n’ai pas l’im­pres­sion que ce soit beau­coup plus lisible.

La grosse diffé­rence c’est que Java a créé ces confi­gu­ra­tions avec tout un outillage autour. Le déve­lop­peur n’avait que rare­ment besoin d’y plon­ger manuel­le­ment. C’était géré auto­ma­tique­ment par les IDE et les scripts.

J’ai ajouté un plugin au .babelrc décrit plus haut. Ce plugin a une option. Je me retrouve avec un Json de 7 lignes dont 4 qui contiennent autre chose que des crochets et acco­lades fermantes.… et déjà un diction­naire dans un tableau dans un tableau dans un diction­naire. Rien que ça.

Même mon petit package.json me parait déli­cat à mani­pu­ler malgré l’in­den­ta­tion. Heureu­se­ment que les dépen­dances sont ajou­tées auto­ma­tique­ment par npm lors de leur instal­la­tion.

Là, dès qu’on dépasse le simple clef valeur, j’ai l’im­pres­sion de me retrou­ver avec une double peine : Un fichier de confi­gu­ra­tion peu aisé à mani­pu­ler, mais pas pour autant d’ou­til pour le faire à ma place.

Catégories
javascript tests

[Lecture] On a testé fonc­tion­nel­le­ment notre app JS

Lu sur le web :

L’uti­lité des tests fonc­tion­nels pour les appli­ca­tions web n’est plus à démon­trer (comment ça, vous ne testez pas encore vos apps ?). Malheu­reu­se­ment, tout ne peut pas être tota­le­ment testé fonc­tion­nel­le­ment, ou de façon aisée : je pense par exemple au player chez nous, un compo­sant stra­té­gique mais pauvre­ment testé fonc­tion­nel­le­ment de par sa nature un peu hybride (mélange de flash et de JS). Dans tous les cas, pour ce qui peut l’être, nous sommes parti­sans dans l’équipe Cytron d’user sans mesure (ou presque !) de cet outil de manière à être le plus zen possible au moment d’ap­puyer sur le bouton “deploy”.

chez M6 Web

Inté­res­sant, mais à deux moments j’ai l’im­pres­sion de tâton­ne­ments, de tests qui peuvent échouer sans raisons et qu’on relance pour s’as­su­rer que ça passe. Je trouve ça assez risqué comme approche. Ai-je mal compris ?

il nous arri­vait que le compor­te­ment “hover” ne soit pas déclen­ché, mettant en échec la suite du test. Nous avons donc changé notre manière d’ef­fec­tuer le rollo­ver : on répète l’ac­tion grâce au waitUntil tant que l’éle­ment devant appa­raître au hover n’est pas visible

Pourquoi l’évé­ne­ment n’est-il pas déclen­ché ? Et l’uti­li­sa­teur risque-t-il d’avoir le même bug ?

Elle permet de stocker dans un fichier texte la liste des scéna­rios en échec pour les relan­cer ensuite afin de véri­fier qu’ils le sont réel­le­ment.

Des faux posi­tifs ? Et si parfois le test échoue alors qu’il ne devrait pas, il y a-t-il un risque qu’il réus­sisse alors qu’il ne devrait pas ? Combien de fois le relan­cer pour être certain du résul­tat ?

Le retour d’ex­pé­rience est extrê­me­ment inté­res­sant, mais ça laisse un goût de bidouille qu’il serait préfé­rable de corri­ger avant de consi­dé­rer la solu­tion comme stable.

Catégories
javascript

La commu­nauté JS est actuel­le­ment une machine à créer de la dette tech­nique

on est dans la phase de l’ado­les­cence. Ça cri, ça bouge, ça a plein d’éner­gie, et ça mérite des baffes.

— par Sam & Max

L’ins­tal­la­tion est deve­nue un enfer. Entre les dépen­dances dépré­ciées, les libs incom­pa­tibles, les diffé­rents outils de build, et les options de config et les plugins, c’est une merde incom­men­su­rable. Plusieurs stan­dards d’ins­tal­leurs (et outils joints) se tirent la bourre : AMD, CommonJS et Harmony. Vous vous souve­nez du temps ou on copiait juste jQuery dans le réper­toire static ?

[…] On peut faire plus de choses qu’a­vant. De manière plus propre […] Mais l’éco­sys­tème, c’est le bordel géné­ral, l’anar­chie totale, et ça conti­nue d’avan­cer, en lais­sant tout le reste derrière.

Les projets JS s’ac­cu­mulent, de free­lances en SS2I qui se pointent, codent ou (surtout) recodent, et repartent en lais­sant un projet qu’il sera imbu­vable à reprendre, dépré­cié avant même d’être terminé, non docu­menté, non testé.

Livré sans commen­taire, mais j’ai­me­rais bien les vôtres.