React est une lib UI: elle sert à designer et rendre réactive des interfaces utilisateur. Si ce que tu veux faire ne s'affiche pas à l'écran, React s'en bat les steaks.
AngularJS change ta manière de coder en JS mais pas tes pratiques en HTML/CSS alors que React fait le contraire: peu de changement côté JS (hors le code spécifique de ton UI) mais modifie ta façon de créer en HTML/CSS.
Les composants React sont toujours des composants UI
Créer une impression de hasard (dans les formes, couleurs ou tout ce qui peut être stylé en css) en utilisant :nth-of-*() pour changer des variables css.
En utilisant assez de variables et en utilisant des nombres premiers pour nth-of, on donne l'illusion de la randomisation. Intéressant.
Merci @Timo pour ce résumé qui explique bien des déboires personnels avec le Drag&drop.
Je me résume ça ici:
un élément acceptera un 👉drop et déclenchera ⚡ondrop si et seulement si l’élément a un ⚡onDragEnter ET un ⚡onDragOver.
🔧event.target != 🔧event.currentTarget:
event.target est l'objet qui reçoit l'événement alors que event.currentTarget est celui quel les gestionnaires d'événements sont attachés et ils peuvent être différents dans le cas d'objets imbriqués.
En dehors du réflexe lui-même, je trouve très didactique la méthode d'observation employée.
Pour ma part, je fais partie des «cintrés»...
...et je dirai qu'ils s'agit moins d'un réflexe que d'une envie inexpliquée de tourner la tête: on ressent un vif besoin, un peu comme une démangaison te donne envie de gratter, mais ce n'est pas incoercible. Ce qui est troublant, c'est que l'envie démarre dès la pose du cintre au bon endroit et s'arrête dès qu'on le retire.
Bon, je ne vous cache pas que c’est long niveau processing et je ne pense pas que ce sera vraiment utilisable pour de l’application web grand public. Mais c’est rigolo.
TLDR; On trouve des connexions vers des serveurs USA pour à peu près tout. Même en dehors de trackers authentiques, ces appels suffisent à eux seuls à poser un problème vis-à-vis du RGPD.
L'article
Le problème est que si on interdisait toutes les applications poubelles, si on arrêtait d’utiliser Zoom, Teams... On serait contraint de ressortir la machine à écrire
Argument fallacieux et facile: non, on n'est pas «coincé» avec des outils «dont on n'arrive pas à se passer»... on trouve beaucoup d'alternatives saines dans le monde du libre et de l'open-source. Par contre, oui, il faut changer d'habitudes, voir plus modeste, accepter de se former un peu... Si les GAFAM et autres monstres marchent aussi bien, c'est que la majorité s'en fout et veut que ça «juste marche».
En réalité, les parents n’ont pas d’alternative. Soit ils consentent et ils peuvent suivre leurs enfants, soit ils refusent et dans ce cas ils ne peuvent plus les suivre.
Pire, on ne leur demande aucune forme de consentement. Toutefois, le RGPD n'impose pas le consentement sous certaines conditions, en particulier dans le cadre d'un service public et l'exercice d'une obligation légale (voir https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre2#Article6 alinéa c et e) ; il suffit de respecter un des critères de la liste:
Le traitement n'est licite que si, et dans la mesure où, au moins une des conditions suivantes est remplie:
a. la personne concernée a consenti au traitement de ses données à caractère personnel pour une ou plusieurs finalités spécifiques;
b. le traitement est nécessaire à l'exécution d'un contrat auquel la personne concernée est partie ou à l'exécution de mesures précontractuelles prises à la demande de celle-ci;
c.le traitement est nécessaire au respect d'une obligation légale à laquelle le responsable du traitement est soumis;
d. le traitement est nécessaire à la sauvegarde des intérêts vitaux de la personne concernée ou d'une autre personne physique;
e. le traitement est nécessaire à l'exécution d'une mission d'intérêt public ou relevant de l'exercice de l'autorité publique dont est investi le responsable du traitement;
f. le traitement est nécessaire aux fins des intérêts légitimes poursuivis par le responsable du traitement ou par un tiers, à moins que ne prévalent les intérêts ou les libertés et droits fondamentaux de la personne concernée qui exigent une protection des données à caractère personnel, notamment lorsque la personne concernée est un enfant.
Du coup, l'utilisation des données personnelles est légitime dans ce cadre pour les applis estampillées EN...
En revanche,
s'il y a captation des données par des tiers et usage publicitaire, il s'agit d'un détournement de l'usage légitime des données et ça, c'est dans le RGPD à la rubrique «PAS BIEN» car le responsable du traitement est censé garantir que les données ne seront pas utilisées autrement que dans le cadre légitime prévu par le RGPD et dans la durée prévue, voir https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre2#Article5
[Les données à caractère personnel doivent être :] collectées pour des finalités déterminées, explicites et légitimes, et ne pas être traitées ultérieurement d'une manière incompatible avec ces finalités; le traitement ultérieur à des fins archivistiques dans l'intérêt public, à des fins de recherche scientifique ou historique ou à des fins statistiques n'est pas considéré, conformément à l'article 89, paragraphe 1, comme incompatible avec les finalités initiales (limitation des finalités);
Toujours utile ?
la solution serait déjà de cantonner le numérique au sein de l’Éducation nationale à ce dont on a besoin. Ces outils sont parfois bénéfiques, et parfois ils n’apportent rien.
Je suis d'accord: le «numérique» est un moyen et pas une fin. (hors confinement, qui est une période très particulière)
Là où on en apprend plus, c'est sur Pronote, dont je n'avais rien à dire mais qui pourtant n'a pas le cul propre puisqu'il requiert des frameworks fermés et puants (google et huawey) ... J.O.I.E
Ils ont été intégrés pour :
des notifs : dont on n'a rien à foutre dans le contexte EN, on est bien d'accord ?!
des stats : mais bourdel di pitin de mârde, pourquoi vous voulez des stats ?! Faites juste votre taf !
Il n'y a AUCUNE RAISON PÉDAGOGIQUEMENT VALABLE pour détourner les données des utilisateurs des applis EN.
En amont de la rentrée scolaire, chaque enseignant a reçu, sur son adresse mail académique, une url personnelle de classe virtuelle du CNED
rien d'essentiel ne doit dépendre de javascript, en particulier les formulaires.
JS peut être désactivé
le navigateur peut être obsolète (oui, windows, c'est de toi que je parle)
des extensions peuvent bloquer le script
le client a peut être une connexion lente qui va timeout
le client a peut être une connexion intermittente (genre le train)
il peut y avoir un firewall qui bloque certaines choses.
etc
En gros, JS devrait être réservé à des choses qu'on ne peut pas faire autrement et/ou non essentielles.
Pour les formulaires, on peut partir d'un formulaire normal fonctionnant normalement et l'améliorer via JS: capturer l'événement onsubmit et gérer l'envoi au serveur via des promises et fetch, traiter les erreurs etc.
Si JS ne fonctionne pas, le formulaire continuera de faire son job avec le comportement par défaut de submit mais de façon moins sexy, c'est tout.
Et si les envois et retours se font en JSON et tout le merdier ?
Problème de type de retour et de format de réception
L'auteur propose d'utiliser le header côté serveur pour identifier qui de JS ou de HTML est à l'origine de la requête (avec Sec-Fetch-Mode par exemple ) et ainsi adapter le comportement du serveur (traitement des données et composition de la réponse)
En gros:
si ça vient de JS ➜ gère le JSON et renvoie du JSON pour que JS gère la réponse
si ça vient de HTML ➜ gère le formulaire normalement et renvoie une nouvelle page HTML composée côté serveur.
