20 résultats trouvés pour la recherche « jquery »

  • Mais pourquoi devrais-je abandonner jQuery pour Angular, React... ou Vue.js !?

    J'ai longtemps utilisé jQuery. Puis Vanilla JS comme on appelle si élégamment le JavaScript implémenté nativement. Je surveillais d'un œil les Knockout et compagnie sans jamais réellement m'y investir. Ce fut également le cas avec AngularJS, tellement super-héroïque et sur toutes les lèvres ! Du MVVM paraissait t-il. Un nom barbare à se retaper alors que je terminais tout juste de comprendre en profondeur les tenants et aboutissants d'une architecture MVC(2). Non merci.

    jQuery vs. Vue
    jQuery vs. Vue

    Autant vous le dire : pour ma part je ne jurais que par la séparation des rôles. Je ne voulais pas retourner à du HTML mélangeant de la structure et du comportement, avec des attributs invalides W3C et un code source à chialer. Ça m'a bien conforté dans l'idée que jQuery ou Vanilla JS restaient des valeurs sûr !

    Mais voilà. J'ai fini par investiguer ce AngularJS, à force de le voir passer. Il s'est avéré que les principaux défauts que je lui trouvais pouvaient se régler avec un peu de rigueur. OK ? Mais à quoi bon tant d'efforts pour utiliser l'outil à la mode, là où jQuery à toujours fait le job ?

    Même si j'ai partiellement compris l'utilité d'un tel changement grâce à mes études de surface sur Aurelia, React puis Angular, il semble que j'ai trouvé la réponse définitive à la bonne raison d'abandonner jQuery grâce à l'étude de Vue.js. Et en une simple après midi de lecture ! Je ne jure plus que par cette bibliothèque à présent !

    Pour faire simple : jQuery pilote par le DOM, là où Vue pilote par les données ! Et ça, ça change tout.


  • Éviter les multiples $(document).ready() dans vos pages web

    Une chose qui me gène avec la $(document).ready() de la librairie jQuery, c'est que c'est une magnifique porte ouverte aux mauvaises pratiques JavaScript. Elle empèche les développeurs web en herbe de se pauser les bonnes questions et pire encore, comme j'ai pu le constater récemment, aux développeurs à priori chevronnés d'en faire de même...

    Oui, le $(document).ready() peut être utilisé plus d'une fois dans un ensemble de fichier et oui, il peut être placé n'importe où dans une page HTML mais non, ce n'est absolument pas vous rendre service que de faire cela ! Ce n'est pas parce que l'on peut, que l'on doit.

    Mettre ces déclarations un peu partout rend plus difficile la relecture et le debug du code en empêchant de savoir qui s'exécute avant qui sans regarder l'ordre d'appel des fichiers. Effectivement, si cela semble simple et pratique quand 3 fichiers se battent en duel, cela peut rapidement devenir complexe. De plus, si une exception est levé dans l'un des $(document).ready(), aucun des autres n’exécutera plus rien du tout. Pour finir, le code est ralenti lors de l'appel de plusieurs $(document).ready() contre un seul, ou contre aucun d'ailleurs.

    $(document).ready() ZzzZz
    Don’t let jQuery’s $(document).ready() slow you down

    Dans cet article nous allons voir l'une des dizaines de façon de vous passer de $(document).ready() dans vos pages web. Le maître mot ? Un seul point d'entré pour l'ensemble du code exécuté sur une page. Vous trouverez également un exemple de la méthode décrite dans cet article dans ce repository GitHub.


  • Vanilla JS - Documentation en français

    Vanilla JSVanilla JS

    Vanilla JS est un framework rapide, léger et multi-plateforme pour créer d'incroyables et puissantes applications JavaScript


  • Valider les formulaires simplement, et sans JavaScript

    S'il y a bien une action redondante et qui nécessite de passer par la case JavaScript, c'est bien la validation des formulaires ! Mais sachez qu'il est possible de les valider sans utiliser une seule ligne de code ! J'avoue, je triche un peu quand je dis ça. En réalité il n'y a rien de magique et il faudra tout de même inclure trois scripts pour réaliser cela, mais il ne sera pas nécessaire que vous écriviez du JavaScript.

    Voyons ici quel sont ces scripts et parcourons les différents cas de figure pour valider des champs vides, vérifier qu'un email est bien formé ou encore qu'une confirmation de mot de passe correspond bien au mot de passe initialement tapé. Par exemple, pour vérifier qu'un champ « Pseudo » est bien remplis et indiquer la place de son message d'erreur, il suffirait de le déclarer dans un formulaire comme ceci :

    <label for="pseudo">Pseudo</label>
    <input type="text" name="pseudo" id="pseudo" placeholder="Haeresis"
           data-rule-required="true"
           data-msg-required="Le champ Pseudo est requis." />
    <span data-valmsg-for="pseudo" data-valmsg-replace="true"></span>
    

    C'est donc parti pour :

    1. Trouver votre bonheur dans l'exemple complet suivant : http://codepen.io/Haeresis/pen/AzJgF/

    2. Ou/Et lire la suite de ce billet pour en apprendre un peu plus sur le jQuery Validation Unobstrusive Plugin.


  • Comment cibler un id qui contient un point

    En CSS, tout comme avec le librairie JavaScript jQuery, il faut utiliser des sélecteurs pour cibler une balise ou un ensemble de balise :

    • on utilise le sélecteur # si l'on désire accéder à l'élément par la valeur de son attribut id ou,
    • on utilise le sélecteur . si on désire accéder à l'élément par une des valeurs de son attribut class.

    En combinant les deux sélecteurs précédent on peut sélectionner une balise par son attribut id et son attribut class.

    On peut donc cibler la balise HTML suivante :

    <div id="main" class="example"></div>
    

    avec le sélecteur CSS suivant :

    div#main.example { /* ... */ }
    

  • Pourquoi vous ne comprenez rien au JavaScript ?

    Vous avez un pied dans le monde du numérique depuis quelques années, ou vous côtoyez les métiers du web de près ou de loin, et pourtant vous ne comprenez pas totalement encore les problématiques des développeurs Front-end, ou même maintenant des développeurs Full-stack.

    Pourquoi finalement ne peut t-il pas « simplement » y avoir un développeur web comme au bon vieux temps. Quelle est là réelle différence avec un intégrateur HTML/CSS ? Pourquoi le web client n'est t-il plus si abordable pour les développeurs ? Pourquoi coûte t-il si cher à présent ?

    Je vous propose, à partir d'une petite discussion fictive entre, un acteur du numérique qui n'a plus l’œil partout, et un développeur Full-stack sur le feu, de mettre en lumière en quoi le web d'aujourd'hui est « compliqué ».

    Cet article est inspiré et adapté en français de l'article « How it feels to learn JavaScript in 2016 », lui-même inspiré par « It's The Future » que j'ai modifié pour y apporter ma propre expérience. Vous pouvez lire les articles originaux respectivement ici et ici.

    Cet extrait n'est qu'une mise en situation, et tout comme n'importe quelle bibliothèque JavaScript, il ne devrait pas être pris trop au sérieux !

    En espérant que vous y apprendrez des choses !


  • Structurer le JavaScript de son site avec ou sans Framework

    On me demande souvent quelle est la structure JavaScript que j'utilise pour développer mes sites web. C'est une question à laquelle je ne sais jamais si un simple « jQuery » suffit ou si l'on s'attend à m'entendre répondre « Knockout », « AngularJS », « Vue.js », « React » ou encore, « RequireJS » ou je ne sais quelle autre composant/librairie/framework JavaScript Front-end extraordinaire !

    Au delà du fait que l'utilisation de ses ressources précédemment citées dépend du fait que l'on souhaite réaliser un site web ou un outil web ou une application web etc. je finis toujours par expliquer que j'utilise ma propre architecture JavaScript à travers toutes les différentes pages d'un site web et qu'au cas par cas, je charge les JavasSript dont j'ai besoin (parfois il est plus judicieux de charger de manière asynchrone un ckeditor sur l'unique page ou il est utile que de ce le trimbaler partout sur le site !).

    Je vais donc vous livrer à travers cet article une architecture JavaScript pas à pas, page par page. Il existe également une approche plutôt orienté composant que j'aborde ici.

    Afin de la comprendre pas à pas, j'utiliserai comme fil conducteur la réalisation d'un site vitrine. Ma façon de structurer le JavaScript client n'est pas absolue mais elle vous permettra de comprendre la logique derrière certains de mes sites dont vous trouverez les sources sur GitHub (comme pour ce blog) ou même la logique du moteur de site Node.js : NodeAtlas.


  • Séparations des rôles du HTML / CSS / JavaScript et mise en application

    Cet article fait office de conventions d'architecture d'un site web orienté composant pour la partie cliente, peu importe la technologie d'implémentation finale, de manière à ce que le code soit valide, performant et maintenable par des développeurs front-end, des développeurs back-end ainsi que des pousseurs de contenu. Ces techniques étant en constantes évolution, et les problématiques évoluant au fur et à mesure de mes itérations créatives, cet article est voué à se compléter et changer.

    Contenu, apparence et comportement
    Contenu, apparence et comportement

  • Vue + NodeAtlas : de l'art du SSR ou Rendu Côte Serveur avec JavaScript

    Nous allons voir dans cet article comment faire du rendu côté serveur ou SSR (Server-Side Render) avec le framework JavaScript client MVVM (Modèle-Vue-Vue Modèle) Vue couplé au framework JavaScript serveur MVC(2) (Model View Controller) NodeAtlas !

    Alors ce titre parle peut-être aux habitués des architectures clientes MVVM qui ont des difficultés avec le référencement et semble peut-être barbare pour d'autres. Lançons-nous dans une petite explication histoire de rendre cet article intéressant également pour les néophytes : comprenons le problème et trouvons la solution à travers cette page.

    Quel est le problème traité dans cet article ?

    Le problème avec les frameworks MVVM client est qu'ils construisent le site à partir de rien. Fouillez la source du code de la réponse HTTP de la page courante, celle lue par les indexeurs de contenus ou les navigateurs sans JavaScript ; il n'y a rien. Aussi, si je crée une liste d'actions futures pour la roadmap de ma super App, et que je souhaite pouvoir manipuler aisément (ajout et retrait) ses éléments grâce à un coupleur de données vue-modèle ; le revers de la médaille sera que les informations utilisées pour cette construction proviendront de fichiers JavaScript ou morceaux de HTML qui ne veulent rien dire pour les indexeurs où même les validateurs de page. Vos sites sont donc souvent « SEO merdiques » et « W3C bancales ».

    Quelle solution ?

    Le SSR ou Rendu Côté Serveur. Voyons ça au travers de cette page exemple avec Vue et NodeAtlas !


  • Ne vous souciez plus de la target dans vos liens

    Pour les personnes en charge de l'édition de contenu, remplir des liens est souvent source de problème car, là où la page des termes et conditions avaient toujours été une page interne au site, la voilà devenu un fichier PDF ou une page plus globale hébergée sur un autre site web ; ce qui demande l'ouverture d'un nouvel onglet pour s'afficher. Et le pire dans tout cela, c'est que c'est juste pour la version du site en Vulcain ! Il va donc falloir laisser ces mêmes personnes gérer eux-mêmes la propriété target ou...

    ...utiliser un script intelligent qui va ajouter les target="_blank" là ou ils sont nécessaires !

    Cela est également très pratique quand on rédige ses pages en Markdown.


  • Comment gérer les raccourcis clavier en JavaScript

    Nous allons voir dans cet article comment créer rapidement un système permettant de surveiller si une touche du clavier est enfoncée lors de l'exécution d'une action dans votre navigateur ou mieux, si une série de touche est enfoncée pour autoriser / lancer l'exécution d'une action lors de la pression, par exemple, sur « Ctrl + Alt + E ».

    Ctrl + Alt + E
    Image originale ici

    Et comme toujours, on va devoir jouer avec un peu de JavaScript ! Si vous n'avez pas trop le temps de jouer, le code qui vous intéresse probablement se trouve ici


  • Des sites web Node.js pour débuter en JavaScript serveur avec NodeAtlas

    Je vous propose de créer vos propres sites Node.js armés pour un rendu de qualité côté client et avec très peu de JavaScript. Vous pourrez ensuite, petit à petit et à votre rythme, vous plonger dans la partie Back-end JavaScript offerte par Node.js. Tout ceci est possible grâce au module npm (node.js package manager) NodeAtlas.

    NodeAtlas est un Framework JavaScript côté serveur orienté Front-end, c'est-à-dire qu'il permet de faire tourner des sites multilingues complets uniquement avec les parties Vue et Route d'activées le reste étant fait par le framework. Bien évidemment, en activant la partie Contrôleur et Modèle vous prendrez la main sur le JavaScript serveur et vous pourrez créer de grands sites de qualités avec tout ce que l'on est en droit d'attendre : compte utilisateur, envoi de message, chat en direct... ou de solides applications web couplées à des Frameworks Javascript Frontaux comme Vue ou même simplement du code maison ! Mais commençons par le commencement.

    Sachez que le blog sur lequel vous lisez cet article est fait avec NodeAtlas (obtenir les sources), ce qui lui permet de respecter facilement les standards HTML/CSS et de fournir sans efforts de hautes performances.

    NodeAtlas est designé pour :


  • Centrer verticalement n'importe quel élément en quelques lignes CSS

    Une solution rapide et qui fonctionne sur tous les navigateurs à partir de IE9 est le centrage vertical avec la valeur CSS3 translateY de la propriété transform.

    Pour mettre cela en place, trois simples propriétés :

    1. On place l'élément en relatif pour le repositionner par rapport à son élément parent avec position: relative;.

    2. On déplace l'élément de la moitié de la hauteur de l'élément parent avec top: 50%;, la référence de déplacement étant actuellement son bord haut.

    3. On re-centre l'élément non plus à partir de son bord haut mais de son centre vertical avec transform: translateY(-50%);

    Et voilà !


  • Conserver un affichage Desktop sur mobile avec une version Responsive Web Design

    Depuis que le Responsive Web Design a commencé son invasion, beaucoup de site ne possède plus qu'une unique version qui gère :

    • un affichage complet pour écrans larges de type écran d'ordinateur (Desktop) et
    • un affichage léger et partiellement complet pour les écrans de type mobiles/tablettes.

    Cela revient souvent à inhiber des fonctionnements jugés peu utiles par les développeurs ou ergonomiquement trop instables pour être présentés sur les petits appareils et empêche alors :

    • d'afficher la version Desktop sur les mobiles/tablettes ou
    • d'afficher la version Desktop dans une fenêtre de navigateur rétréci.

    Je vous propose, à travers des exemples CSS-Driven, de vous expliquer comment gérer deux versions d'affichage de vos pages avec comme toujours une seule structure HTML sémantique.


  • Bootstrap est une régression pour un développement Front-end de qualité

    Pourquoi je n'utilise pas Bootstrap ? Cela peut sembler une « évolution » de nos méthodes de travail front-end, mais gare au loup et attention de ne pas tomber dans un travers que le W3C tente d'enrayer au fur et à mesure des évolutions HTML et CSS.

    Commençons par le commencement. Qu'est-ce que Bootstrap ? Comme pleins d'autres « Bibliothèque » ou « Framework » CSS dans la même veine, Bootstrap est un outil permettant d'augmenter la productivité des développeurs front-end le maîtrisant, dans le but de fournir le plus rapidement possible un rendu visuel ergonomique et si possible responsive.

    Mon problème ne vient pas tant de sa finalité qui est louable, mais bel et bien de la mise en œuvre technique qui permet d'atteindre cette finalité. Pour être concis avant de développer : l'utilisation faites de Bootstrap est une régression pour un travail front-end de qualité.

    Je ne compte persuader personne, et à défaut de convaincre, je vais au moins vous expliquer mon point de vue.


  • Un dé pour les gouverner tous ! Le d120 ultime !

    Si je vous parle de dés, immédiatement vous imaginez un petit cube à 6 faces numérotées de 1 à 6 : c'est ce que l'on appel un d6 dans le jargon des jeux de rôle. Mais le d6 n'est pas le seul, et surtout, le d6 plus performant en terme de hasard.

    C'est pourquoi je souhaite vous présenter le seul dé capable de remplacer des dés comme les d4, d6, d8, d10, d12 et d20 et j'en passe tout en étant le plus équilibré qu'il soit possible de l'être : j'ai nommé le d120 !

    Le dé ultime, le d120 !
    d120 de The Dice Lab

    Je vous propose de découvrir dans cet article :

    • pourquoi le d120 est appelé le dé ultime,
    • comment le d120 peut être à lui seul utiliser pour faire office de d1 jusqu'au d119 en passant bien entendu par le symbolique d100 des jeux de rôle,
    • les tables de correspondance associées des dés multiples de 120 et
    • les outils pour aligner votre d120 sur vos statistiques ou aligner vos statistiques sur votre d120.

    On finira bien entendu par le moyen de vous procurrer le d120 !

    Si vous êtes développeur front-end et que vous cherchez des exemple d'utilisation de Vue.js à la volée (comme on utiliserait simplement jQuery), je peux vous conseiller de jeter un œil au code source de cet article derrière ce CodePen : https://codepen.io/Haeresis/pen/qGQLvp


  • Activer vos effets JavaScript en fonction de vos Media Queries

    Je viens de voir un code allembiqué permettant de maintenir la hauteur de deux <div> côte à côte. Problème ? Ces éléments ne sont pas côte à côte en version mobile mais l'un sous l'autre : et maintenir la hauteur dans ce cas là ne sert à rien. La semaine d'avant, j'ai vu un code avec une cascade de if permettant d'ouvrir une vidéo dans une popup sur PC et d'ouvrir un lien Youtube sur mobile. Bien évidemment, les petits écrans PC ouvraient une popup alors qu'il aurait été intéressant qu'ils ouvrent aussi un lien. Je vous fais l'impasse sur les comportements au redimensionnement de la fenêtre.

    Bref, lançons-nous dans un petit exercice pour permettre un code JavaScript Responsive Web Design, sans se soucier de l'appareil qui l’exécute.


  • JavaScript et callback par nom de paramètre comme dans AngularJS

    Ce qui m'a interpellé la première fois que j'ai pu m'essayer à AngularJS, c'est la possibilité offerte de sélectionner les services que l'on souhaite en les récupérant par leur nom d'argument, et non par leur position d'argument. Ce concept n'existe pas en JavaScript et pourtant le fait est bien là : function ($scope, $http) ou function ($http, $scope) renvoi les bons contenus de variable en fonction de leurs noms et function (scope, $http) vous dit que scope n'existe pas !

    Accès par nom de paramètre
    Accès par nom de paramètre

    Comment cela est-il possible en JavaScript ? Il est possible de « simuler » un passage par nom d'argument avec un type Object en utilisant ses noms de propriété, mais là, il s'agit bel et bien de différents arguments.

    Voici le petit exercice que je vous propose dans cet article, faire du « Reverse Engineering » sur le mécanisme « caché » permettant aux fonctions de rappel (callback) JavaScript de délivrer leurs arguments par « nom d'argument » en lieu et place du mécanisme natif qui est par « position d'argument ».

    Note : on parle souvent de passage par « nom de paramètre » dans les autres langages. Ici, en réalité, il s'agit plutôt de passage par nom d'argument car cette fonctionnalité est associée aux arguments fournis par la fonction de rappel et non aux paramètres que l'on fourniraient à une fonction. Pour rappel on fournit des arguments en déclarant une fonction, et on passe des paramètres en exécutant une fonction.


  • Les types en JavaScript : pour tout savoir !

    Mais le JavaScript n'est pas typé ? Mais si, il y en a 13 ! Ah non, il y en 7... Bah il me semble qu'il y a Object, Function, Array, Math, String, Number, Boolean. Et tu fais quoi de RegExp ? Attends, Function c'est pas un type, c'est un sous type mais Null c'est un type... ? Ho là là...

    Si vous faites du jQuery à vos heures ou même pas mal de JavaScript sur vos sites web, il est temps d'apprendre tout ce qu'il y a à savoir sur le typage implicite de JavaScript, car oui : contrairement à ce que certain vous ont dit, JavaScript manipule des éléments typés, on peut même dire que le JavaScript est faiblement typé et dynamiquement typé si vous voulez tout savoir. Les fonctions (et les instances) Object, Function, Array, Date, String, Number, Boolean, RegExp, Error ou encore les objets globaux, Math et JSON : tous sont d'un seul et même type, le type Object. Pourtant String, Number et Boolean sont eux-mêmes un type à par entière en plus des deux petits spéciaux les type Null et Undefined.

    Si vous deviez retenir quelques trucs rapidement à propos du JavaScript et des types ça serait que :

    • Le JavaScript n'a que 6 types : Object, Number, String, Boolean, Null et Undefined.
    • À part le type Object : les 5 autres types sont dit des types primitifs.
    • Les types Null et Undefined sont des types spéciaux.
    • La Function n'est qu'un type Object qui peut être exécuté et instancié avec « new ».
    • Array, Date et RegExp sont des types Object instanciables (Function).
    • Math et JSON sont simplement un type Object (ne s'instancie pas avec « new »).
    • Bien que Number, String et Boolean soient des types primitifs, il existe un équivalent de type Object instanciable (Function) pour chacun d'eux (à ne pas confondre).
    Les 6 types en JavaScript
    Les 6 types en JavaScript

    Je vais dans un premier temps vous proposer la traduction d'un article de Dmitry Baranovskiy —développeur JavaScript expérimenté— qui explique très bien les types en JavaScript. Je lèverai le doute sur le fameux sixième type (Null ou Function). Et je vous fournirai des lignes de code test pour mettre en évidence ce qui a été expliqué.

    Dans cet article les propos entre [ ... ] sont les miens ainsi que ceux qui ne sont pas entre « ... ».

    Pour finir, bien que l'auteur vous encourage à lire les spécifications officielles (pour les initiés), je vous encourage pour ma part à lire JavaScript Eloquent (disponible en français ici).


  • Créer et maintenir des maquettes HTML avec NodeAtlas

    NodeAtlas est une application multi-os écrite en Node.js qui va vous permettre de créer, modifier et maintenir tout un ensemble de maquette HTML. Ces maquettes HTML pourront ensuite être validées par le client, et ré-utilisées totalement ou en partie par les développeurs Back-end quelque soit leurs technologies. Ces maquettes HTML pourront également servir de site stand-alone fonctionnant sans serveur ou avec un simple serveur HTTP pour créer des documentations JSDoc ou autre comme pour GitHub par exemple. C'est ce que nous allons voir dans cet article.

    Mais NodeAtlas permet également de faire tourner des sites web complet, performant et rapide tel que le site sur lequel vous être entrain de lire cet article.

    NodeAtlas est designé pour :


Lire dans une autre langue