Tous les articles pour AngularJS

  • 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.


  • 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 !


  • Vue.js vs React vs Angular vs les autres MVVM

    Vue.js est un framework JavaScript client progressif permettant de créer, maintenir et évoluer des interfaces utilisateurs en liant les données utilisées entre la Vue et le Model. C'est une alternative sérieuse à React, Angular et les autres frameworks MVVM (Modèle Vue VueModèle).

    Vue.js

    J'ai eut l'occasion d'essayer Vue.js dans sa version 1 et son extrême simplicité et flexibilité m'a séduite. À l’instar de NodeAtlas, sa puissance vient de ses fonctionnalités intégrables de manière évolutives et versatiles ; on peut tout aussi bien utiliser Vue simplement sur le formulaire d'une page ou à plus grande échelle avec des composants et du routage à travers l'architecture d'un site complet.

    Cependant, là où en version 1, Vue paraissait une alternative séduisante à AngularJS (aka Angular 1) ou Knockout, dans sa version 2 il devient de plus une alternative sérieuse à Angular (aka Angular 2), React et les autres frameworks MVVM tant sur le plan des fonctionnalités que des performances.

    Pour faire simple —si vous débarquez dans le monde des framework JavaScript client MVVM et que vous ne savez pas quoi choisir— vous devriez choisir Vue ! Quoi qu'il arrive, il sera un choix pertinent pour les cas d'utilisation que vous en ferrez.

    Nous allons dans cet article :

    1. rapidement exposer pourquoi vous devriez utiliser Vue en lieu et place de Angular ou React dès maintenant et
    2. lire la traduction des explications approfondies à propos des différences entre Vue et les autres frameworks.

  • 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 !

    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.


  • Utiliser AngularJS en respectant les recommandations W3C et SEO

    AngularJS est un régale pour toute création d'Application Web de petite et moyenne taille. J'entends par là, des ensembles d'interfaces web ou l'utilisateur est sollicité à participer au remplissage de contenu par l'intermédiaire de champs, listes, boutons, etc.

    AngularJS

    Le principe est le suivant : sortir le contenu utile du HTML pour le ranger dans un scope JavaScript afin de le manipuler plus aisément et parsemer le HTML de référence à ce scope de contenu. L'avantage est que le contenu a sa propre vie, et n'est plus figé dans le HTML et surtout toute mise à jour de contenu dans le JavaScript entraîne sa mise à jour dans le HTML, bien pratique.

    Le revers de la médaille est que la source HTML mangée par les moteurs de recherche pour le référencement ne ressemble plus qu'à un ensemble de variables, et les balises et attributs HTML rencontrés font pâlir n'importe quel validateur W3C.

    C'est parti pour un tutoriel vous expliquant comment contenter le W3C pour pouvoir correctement implémenter vos recommandations SEO avec AngularJS.