Antichesse (o ^ω^ o)
Pour Lenny
Pour Chlouchloutte et Lenny... Votre avis ?
Les sources JavaScript exécutées par le navigateur sont souvent différentes des sources originales crées par un développeur. Les source map servent au debugger
Pour Animal
Je suis en train de passer en revu les différents systèmes de chargement de composants en JS. En résumé (et avec quelques imprécisions) :
- CommonJS permet de charger les libs JS de manière statique.
- AMD (pour Asynchronous Module Definition) permet de chargement des libs JS de manière dynamique et asynchrone.
- SystemJS permet de faire les deux mais également d'assurer la transpilation à la volée des libs chargées.
Il faudrait donc utiliser SystemJS pour être bien.
Créer une boite modal pour un petit site.
Un super menu en JS. Le second effet et top-moumoutte !
Fabriquer des charts jolis en JS pure sans dépendance et qui tiennent la charge.
Le morceau de code JS de la page :
La partie HTML :
<body onscroll="OnScrollDiv()" onload="OnScrollDiv()">
<div class="lazy"></div><div class="lazy"></div><div class="lazy"></div><div class="lazy"></div><div class="lazy"></div><div class="lazy"></div>
... (la ligne du dessus est répétée n-fois
<script>...</script>
</body>La partie JS :
function OnScrollDiv() {
var elems = document.getElementsByClassName('lazy');
var el = elems[0];
for (var i = 0, nb=elems.length ; i < nb ; i++, el = elems[i]) {
var rect = el.getBoundingClientRect();
// $isVisible contains "true" or "false" weither the element is visible or not
var isVisible = ((rect.top - window.innerHeight) < (0 - 200) && (200 < rect.bottom));
if (isVisible) {
el.classList.add('blue-block');
}
else {
el.classList.remove('blue-block');
}
}
}Une explication montrant l'évolution de la stack JS depuis 2010 et pourquoi autant d'outils ont fait leur apparition depuis.
Comment mixer AureliaJS et ThreeJS dans un même projet. Pour toi Lenny, je sais que tu vas en avoir besoin.
Une lib pour faire de la modélisation 3D (des cubes, des boites toussa).
Plein d'exemple de code (de convertisseurs notamment) écrit en Aurelia. Parfait pour se construire une codebase autour de ce framework.
Comment utiliser simplement le GPU à la place de CPU dans un navigateur pour exécuter plus rapidement vos calculs parallèles (facteur 5 à 15 quand même).
Bon, je dois refaire du Webpack pour mettre à jour le build d'un tool de la boite. Comme j'ai eu beaucoup de peine à retrouver comment et quoi faire, voici un bref résumé des trucs et astuces à connaître sur Webpack.
Comment concaténer des fichiers JS inter-dépendants ?
Principe : mon fichier JS (Main.js) importe d'autres fichiers JS (cf. le mot-clef require de TypeScript / ES6). Et ces fichiers JS importent également d'autres fichiers. L'idée ici est d'avoir un Webpack qui parcours le graphe des dépendances en analysant le code afin de produire un et un seul fichier JS qui n'inclut que ce dont mon application se sert.
Contenu du fichier webpack.conf.js :
module.exports = {
entry: {
Car : './src/Main.js' // Charge ce fichier ainsi que tous ceux dont il dépend via le mot-clef 'require'.
},
output: {
path: './target',
filename: 'merged-file.js'
}
};Comment créer un bundle de fichiers JS qui n'ont aucune dépendance entre-eux ?
Principe : j'ai plein de libs écrites en JavaScript avec mes petites mimines (ou pas), ces librairies n'ont aucune dépendance entre-elles, cependant je souhaiterais les concaténer dans un gros bundle de sorte à minimiser le nombre de requêtes réseau.
Contenu du fichier webpack.conf.js :
module.exports = {
entry: [
'./src/Car.js', // La liste des fichiers à concaténer
'./src/Vehicule.js'
],
output: {
path: './target',
filename: 'merged-file.js'
}
};Comment créer plusieurs bundles de fichiers JS qui n'ont aucune dépendance entre-eux ?
Principe : je reprends les fichiers JS du point précédent à ceci près que je souhaite créer plusieurs bundles, un pour chaque types de véhicules par exemple.
Contenu du fichier webpack.conf.js :
module.exports = {
entry: {
four-wheels : [
'./src/Car.js',
'./src/Vehicule.js'
],
two-wheels : [
'./src/Bike.js',
'./src/Vehicule.js'
]
},
output: {
path: './target',
filename: '[name].bundle.js',
chunkFilename : '[id].bundle.js'
}
};Comment minifier mes bundles JS ?
Principe : mes fichiers JS sont gros et je souhaite supprimer le maximum d'espace, les commentaires, réduire le nom des fonctions, variables & Co de sorte à fournir le plus petit fichier possible.
Contenu du fichier webpack.conf.js :
var webpack = require("webpack");
module.exports = {
entry: [
'./src/Car.js',
'./src/Vehicule.js'
],
output: {
path: './target',
filename: 'app.minified.js'
},
plugins: [
new webpack.optimize.UglifyJsPlugin({minimize: true})
]
};Un éditeur de text "next gen" dans votre navigateur.
Outch ! Je peux vous assurer qu'entre la programmation asynchrone, les générateurs, les itérateurs, les call-backs imbriqué et le mot-clef yield (qui à mon sens est un goto déguisé), cela va être de plus en plus compliqué d'appréhender JS pour le chaland.
Il faut vraiment s'y mettre maintenant, dans deux ans il sera trop tard.
Rappel :
TypeScript est un langage libre développé Microsoft. Le but de TypeScript est de fournir un langage fortement typé, qui étende JavaScript et qui puisse être converti en JavaScript (normes ES5, ES2016 ou ES2017) afin d'éviter au développeur d'utiliser directement JavaScript et de produire un code JavaScript qui soit portable et utilisant toutes les optimisations du langage. On dit du compilateur TypeScript qu'il est un transpilateur car il converti du code source en un autre code source et non en instructions (binaire, assembleur, byte-code).
Comment qu'on install TypeScript ?
En passant par NPM ! En effet TypeScript est devenu un paquet NPM et est considéré comme une dépendance technique de votre projet JavaScript. Cette façon permet d'avoir une version du compilateur TypeScript par projet plutôt que d'une seule version unique commune à tous les développements.
Comment faire pour installer TypeScript avec Yarn ?
## Pour une installation locale à votre projet :
yarn add --dev typescriptJe recommande bien évidemment l'utilisation de Yarn en lieu et place de NPM ainsi qu'une installation locale pour éviter les conflits de version inter-projets.
Cependant, et comme je suis vraiment sympa, voici les commandes à taper pour installer TypeScript via NPM :
## Créer une installation global sur votre OS (disponible partout dans la ligne de commande) :
npm install -g typescript
## Créer une installation local à votre projet JS (accessible uniquement via la commande ./node_modules/typescript/bin/tsc) :
npm install --save-dev typescriptComment qu'on s'en sert ?
Il y a deux méthodes pour transpiler du code TypeScript :
- Soit nous saisissons une gigantesque ligne de commande que nous écrivons dans un script shell.
- Soit nous fabriquons un fichier tsconfig.json à la racine de notre répo, qui contient tout la configuration du compilateur et que TypeScript charge automatiquement lorsque l'on tape la commande tsc.
Je rappelle que je chercher à reproduire l'architecture de dossier spécifiée par la convention Maven :
. (root folder)
|__ src/
| |__ main/
| | |__ js/
| |
| |__ test/
| |__ js/
|
|__ target/Voici mon fichier :
{
"compilerOptions": {
// BUILD GLOBAL OPTIONS :
"module": "commonjs", // What kind of loading system should we use (CommonJS, AMD, etc).
"outDir": "./target/js", // Output directory
"sourceMap": false, // Create the source-map file help to debug TypeScript code while executing JS
"target": "ES5", // The aimed JS version (ES5, ES2016, ES2017 or ESNext
// BUILD OUTPUT :
"diagnostics": false, // Display no statistics about number of files, base code size, etc.
"pretty": true, // Display color in console for error, warning, etc.
// ENCODING
"charset": "utf8", // The targeted file encoding
"newLine": "lf", // File will use Line Feed as EOL character (Unix format)
// COMPILER BEHAVIOR :
"allowJs" : false, // Allow JS syntax
"preserveConstEnums": true, // 'const enum' are kept in generated code
"removeComments": true, // Comment removed from transpiled code
"emitDecoratorMetadata": true, // Test
"experimentalDecorators": true,
// COMPILER ENFORCING :
"noImplicitAny": true, // 'any' type is mandatory
"noImplicitThis": true, // Forbien to mix 'any' and 'this' in the same expression
"noImplicitReturns": true // Raise error is a 'return' is missing in part of a function
},
"include": [
"./src/main/js/**/*" // Pattern finding the TypeScript files
]
}L'un de mes posts précédents montrant le différentiel entre deux tsconfig.json DEV & PROD est disponible ICI
Pourquoi ce tuto ?
Grosso-modo je dois apprendre comment reproduire un build Maven mais en JS avec les outils JS qui vont bien ; et qui soient plus ou moins les standards de facto du moment (i.e en ce début 2017).
Définitions :
À quoi sert quel outil dans ce gloubi-boulga d'outils tous plus hypes les uns que les autres ?
NodeJS :
C'est une machine virtuelle qui permet de faire tourner du JavaScript côté serveur.
NPM :
C'est le gestionnaire de paquets permettant de récupérer les dépendances transitives de vos projets (façon Maven). Certains disent que NPM signifie Node Package Manager mais l'auteur atteste que non.
Yarn :
NPM c'est top, mais ça possède trois inconvénients :
- La ligne de commande pu des fesses.
- NPM ne sait pas mettre les paquets dans un répo local (comme le fait a contrario Maven), donc NPM passe son temps à re-télécharger les dépendances qu'il a déjà téléchargé pour le projet précédent.
- NPM ne gère pas le build concurrent (il n'est pas multi-threadé) donc le build rame (enfin tout est relatif #CompilationC++).
Yarn est un outils qui réponds à ces trois problématiques avec un chat tout mimi en guise de logo.
TypeScript :
C'est à la fois un langage mais également un compilateur éponyme. En gros, les mecs de Microchiotte se sont dits que JavaScript ça ne sentait pas bon des fesses (comme la ligne de commande de NPM) et qu'il valait mieux coder avec de vraies classes, des vrais namespaces, de vraies visibilités (public, private, etc) et une fois que tout ceci était correctement codé en TypeScript, ont transpile ce code en du JavaScript ; autrement dit on convertir le code du TypeScript dans une syntaxe cohérente et fortement typée, vers du JS (incohérent et faiblement typé) ; et comme cela plus besoin de se prendre la tête à connaître tous les hacks de ce langage merdique (une référence ici sur la merdicitude de JS et une autre là sur la retard community - ces deux articles sont pour toi Lenny).
Jasmine :
C'est un framework permettant d'écrire des tests en JavaScript. Ces derniers peuvent être au niveau unitaire (façon JUnit) ou fonctionnel / intégration (façon Cucumber). En général Jasmine est considéré comme faisant partie des framework destinés au BDD (mais bon, je ne suis pas d'accord).
Karma :
Un outil permettant de charger une suite de tests écrits en Jasmine ou en tout autre chose. Le concurrent le plus sérieux est MochaJS qui est une sorte de medley entre Karma et Jasmine, mais comme je n'ai pas encore eu le temps de l'étudier,que Karma à l'avantage d'être soutenu par les développeurs Google qui bossent sur Angular 2 et que j'ai déjà utilisé Jasmine par le passé... Bah Karma & Jasmine.
PhantomJS :
NodeJS permet d'exécuter du JavaScript côté serveur, et bien PhantomJS est un navigateur sans interface graphique permettant d'exécuter du JavaScript dans une console afin de le tester (ndr. en s'appuyant sur Jasmine et Karma). Vous vous doutez bien qu'un navigateur sans IHM est un navigateur ultra-rapide pour faire tourner du JS (sous-entendu parfait pour avoir des phases de run de TU rapides durant nos builds).
Webpack :
Webpack peut quasiment tout faire à l'aide de ses plugins mais l'idée ici est de s'en servir pour trois choses :
- Packager l'ensemble du JS dans un seul fichier qui soit unique.
- Minifier au taquet ce fichier packagé.
- Ne pas inclure dans le package minifié le code mort, c'est-à-dire les classes qui ne sont jamais chargées directement ou transitivement par la classe Main.
Et donc dans tout ça ? Et bien dans tout cela vous aurez donc un build JS qui va chercher les dépendances tout seul, qui respecte le cycle de vie de Maven, qui assure la séparation du code à livrer (les sources) du code à ne pas livrer (les plugins du build et le code des tests), qui centralise la production des binaires en un seul endroit et qui soit capable de releaser votre build (i.e fabriquer des tags et incrémenter le numéro de version). Pas mal hein ?
La suite des posts à lire figure ici (en cours de complétion) :
Je précise ici que je cherche à reproduire l'architecture de dossier et le life-cycle de Maven mais pour un projet NodeJS / Aurelia. Nous allons donc avoir ce type de dossiers :
. (root folder) # La racine du répo
|__ node_modules/ # Le répertoire des éléments téléchargés par NPM
|
|__ src/ # Le répertoire contenant les sources
| |__ main/ # Les sources qui seront livrées
| | |__ js/
| |
| |__ test/ # Les sources qui ne seront jamais livrées (les tests)
| |__ js/
|
|__ target/ # Le répertoire contenant les éléments générés lors de build
|
|_ karma.conf.js # Le fichier de configuration de Karma (le générateur de suite de tests)
|_ package.js # Le fichier de configuration de Yarn (le build manager)
|_ tsconfig.json # Le fichier de configuration de TypeScript (le transpilateur)
|_ webpack.config.js # Le fichier de configuration de Webpack (le packager / minifier)- Comment installer et configurer NodeJS & NPM
- Comment installer et configurer le transpilateur TypeScript ?
C'est partiiii #JoueLaCommeBarnabé