Antichesse (o ^ω^ o)
Différence entre les modules JavaScript (CommonJS, AMD, UMD et ESM). J'oublie tout le temps lequel est lequel.
Bref dans mon cas c'est :
- ESM quand on peut car c'est la norme ES6.
- Sinon UMD qui marche côté back et front.
- Sinon AMD pour le front (et qui reste asynchrone comme le premier).
- Sinon CommonJS (CJS) surtout pour le back (même s'il marche pour le front).
Enfin, quand on intègre des lib JS qui n’apportent rien comme jQuery ou TypeScript (oui : ces job n’apportent rien : à part traduire du code écrit par un dev en Vanilla JS, ça ne fait rien du tout), ça ne peut pas être rapide.
Nope, TypeScript n'est pas une lib mais un langage (précisement superset de JavaScript) qui vise à se transpiler en JavaScript (ie. vanilla-js) et dont la motivation est de prouver à la compilation que certaines exécutions seront correctes ainsi qu'ajouter ce qui manque à JS (eg. les namespaces). Ce faisant on ne découvrent plus certains problèmes au runtime mais on prouve leur absence au compile-time.
Du coup, TypeScript c'est du JS avec un tree-shaking + optimisations en fin de build, je ne comprends pas bien le point de vue de Timo qui me semble ne pas bien connaître le langage.
Pour @Chlouchloutte ce tutoriel explique comment marche l'API WebSocket de JavaScript et comment mettre en place le mode push et les notifications via cette API.
J'ai enfin trouvé ! Merci à la team PeerTube qui affiche clairement ce qu'il se passe dans la console du navigateur :) #ZestesLesMeilleurs
En résumé, le protocole HTTP permet d'envoyer du contenu par morceaux : les Partial Contents dont le code de transfert est 206. Ce faisant, il est possible de streamer un flux vidéo en chunks où ces blocs téléchargés un à un sont en fait des plages d'octets bruts à rassembler dans le bon ordre côté client.
Donc pour mettre en place une telle solution il faut :
1) Un serveur qui sache envoyer du contenu par morceaux (et dans le bon ordre ou alors fournissant à ses clients le moyen de remettre les partials dans le bon ordre).
2) Un client qui sache récupérer ce contenu par parties puis le rassembler.
Évidemment une fois que le contenu fût intégralement téléchargé, il devient un gros fichier placé dans le cache du navigateur sauf si l'on décide de l'enregistrer dans le local storage (il faut alors penser à lever la limite des 5 Mo s'il s'agit d'un très gros fichier).
Je vais regarder pour me bidouiller quelque chose courant de la semaine prochaine (parce que ponçage demain et peinture dimanche) mais je suis contente.
Mon client m'a demandé de lui faire part de différents frameworks de test End-to-End qui marcheraient bien avec des SPA. Ici Nightwatch dont le seul défaut est de ne pas gérer nativement le Gherkin (même s'il est possible de lui greffer une bidouille).
Un exemple :
Mon dieu mais c'est génial !
console.table(...)
console.group(...)Merci à je ne sais plus qui.
Je me disais bien qu'il y avait des trucs pétés dans les deux ! #Antipattern
Merci à Sebsauvage
Tout est dans le titre
Convertir un div HTML en PDF.
Pour Lenny
The magical disappearing UI framework.
Le principe de Svelte me plaît beaucoup : vous codez votre GUI et il n'y a pas de framework, juste du code transpilé par Svelte.
Dit autrement, avec Aurelia ou Angular, nous avons besoin, au moment du run, de télécharger 250Ko à 950Ko de sources qui appartiennent au framework, ensuite seulement nous pouvons afficher notre SPA.
Svelte n'est pas un framework mais un transpiler qui va modifier votre code pour qu'il s'exécute directement, sans lib en pré-requis.
C'est plus léger à télécharger et cela évite l'overhead au run. En tant que DevOps, j'ajouterais que cela doit rendre la regénération de la SPA plus rapide avec un Gulp watcher + BrowserSync puisque moins d'étapes et moins de code à traiter.
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.
Plein de petits algos pour se faciliter la vie entre POO et PF.
=> A adapter en Kotlin
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.