La méthode originelle consiste à faire glisser l'archive .ipa dans Apple Music. C'est un peu répétitif et surtout sur android on peut taper adb install <chemin_apk>

Sur IOS on peut installer sur son Macbook ideviceinstaller

Ensuite il suffit de brancher son téléphone et de lancer la commande suivante

Comment installer une archive iOS App Store Package (.IPA) en utilisant l'interface en ligne de commande.

Vous souhaitez implémenter une connexion OAuth2 avec Facebook et expo.io ? Vous êtes au bon endroit !

Les APIs d'authentification OAUth2 pour Facebook et Google étant maintenant dépréciées, Expo nous invite à utiliser la nouvelle implémentation à base du Web Browser nommée expo-auth-session.

Cependant, force est de constater que cela ne marche pas encore très bien dans tous les contextes.

En effet quand vous utilisez Expo GO le client pré-compilé pour Expo cela fonctionne plutôt bien mais dès que l'on créé une app Standalone  cela peut vite se compliquer, principalement sur Android et on fini par s'arracher les cheveux.

Plusieurs topics sont d'ailleurs à l'heure où j'écris cette article entrain de signaler divers problèmes liés à expo-auth-session (SDK44 Expo)

https://github.com/expo/expo/issues/13714

https://github.com/expo/expo/issues/17011

https://github.com/expo/expo/issues/13513

Après moultes recherches et expérimentations j'en suis arrivé à trouver une solution plutôt correcte qui corrige deux problèmes, afin d'avoir un login Facebook fonctionnel sur IOS et Android en Workflow Managed pour des applications créés avec eas-build en standalone ou expo-dev-client.

Mais avant voyons un peu plus en détail le fonctionnement de expo-auth-session.

expo-auth-session est une librarie qui a vocation à nous simplifier la vie pour une autorisation OAuth2 avec divers fournisseurs supportés, parmis lesquels Google et Facebook.

Elle fournie des primitives via une API simple qui va entre-autres permettre d'ouvrir un navigateur dans notre application qui utilise les cookies du navigateur système (afin de profiter du fait que l'on est peut-être déjà connecté au service en question). 

Une fois que l'utilisateur valide les permissions la librairie va gérer la redirection du service tier et traiter les données de retour afin de récupérer un jeton d'authentification, un ID utilisateur et tout ce qui pourrait nous servir dans le cadre d'une démarche de connexion OAuth2. Avec ce jeton d'authentification on peut ensuite consommer une API tierce afin de récupérer des données client.

Comme on l'a vu c'est pratique et sur Expo GO ça marche plutôt bien, par contre sur une application standalone qui n'a pas toute la configuration au milimètre comme dans Expo GO, c'est parfois plus compliqué, notamment sur Android.

Pas de panique : ci-dessous un workflow fonctionnel et très simple à implémenter.

Un workflow expo-auth-session complet et fonctionnel avec Facebook pour ExpoGO ET Android/IOS standalone (EAS BUILD)

Testé sur expo SDK 44 avec les packages suivants :

expo install expo-auth-session expo-random

2 - Définir un scheme pour le deeplinking vers son app.

3 - Configurer l'application Facebook Developer

Aller dans la configuration de son application Facebook (en créer une si on en n'en pas) et dans la section Facebook Login mettre l'URL vers le expo auth link. 

Cette URL est construite en deux parties https://auth.expo.io/ et votre originalFullName qui est la sommes du username et du slug de l'app.

Pour récupérer votre originalFullName vous pouvez utiliser la commande suivante dans le dossier root de votre projet :

expo config --type public | grep "originalFullName"

Ensuite on vérifie qu'on est bien dans cet état et on valide !

Maintenant on passe à la meilleure partie…

La première chose à noter est qu'on a un bug sur EAS build actuellement et qui ne sera peut-être plus d'actualité au moment où vous lirez cet article (n'hésitez pas à me MP pour me le signaler si tel est le cas).

Pour cela il faut surcharger le originalFullName comme ci-dessous, quelques part au démarrage de l'app, sans quoi on aura une erreur à l'utilisation de useProxy: true. Vous pouvez consulter les topics en début d'article pour suivre l'avancement sur ces bugs.

Le deuxième problème est un problème de redirections qui ne marche pas et qui font soit crash l'app, soit d'autres comportements étranges et qui juste ne marche pas.

Ici la solution consiste à toujours utiliser les liens auth.expo.io qui ont plusieurs bénéfices

pour se faire il faut combiner useProxy: true et une redirectURL définie à la main qui va générer le lien en auth.expo.io TOUT LE TEMPS.

On récupère ensuite le jeton d'authentification dans la variable response, qui nous permet par exemple d'interroger l'API Facebook.

https://graph.facebook.com/me?fields=first_name,last_name,email,picture.type(large)&access_token=${response.authentication.accessToken}

And VOILÀ avec tout cela vous devriez être tranquille en attendant que Expo démocratise un peu l'utilisation de ce module.

Pour implémenter une authentification OAuth2 via Facebook avec Expo qui marche sur toutes les plateformes et dans tous les modes ! Ce qui n'est pas le cas pour la configuration par défaut.

Utiliser expo-auth-session via Facebook (Expo Managed Workflow | Expo GO/Standalone app/expo-dev-client | EAS BUILD)

XState est une bibliothèque permettant de créer, d'interpréter et d'exécuter des machines à états finis et des diagrammes d'états, ainsi que de gérer les invocations de ces machines en tant qu'acteurs. Les concepts informatiques fondamentaux suivants sont importants pour savoir comment faire le meilleur usage de XState, et en général pour tous vos projets logiciels actuels et futurs.

Cela tombe bien car lorsque nous avons réalisé Jerry, l'application de blagues qui vous propose de rire entre amis nous avons eu besoin de gérer des transitions d'états pour gérer les différentes phases qui s'enchainent pour le jeu.

Dans cet article nous allons détailler comment ont été modélisés les états et les transitions entre les 3 phases de jeu d'une des premières version de Jerry :

Le lancement d'une chronomètre où il ne faut pas rire

Comme nous le suggère la méthodologie pour déterminer une machine à état commençons par définir la liste des états, les évènements (permettant de déclencher les transitions) et l'état initial.

La définition de l'état de notre machine

choose_joke : L'état dans lequel on tire au hasard une blague.

timer_running : L'état dans lequel le décompte de temps est affiché

choose_loser : L'état dans lequel on choisit si quelqu'un à rigolé à la plaisanterie et qui déclenchera le gain d'un point pour l'équipe gagnante !

Et le contexte, qui sont des variables sur lesquelles on peut agir, parfois aussi nommé état, mais au sens plus large.

current_joke nous permet de récupérer une chaine de caractères qui représente notre blague actuelle, color sert à donner la couleur de fond utilisée pour afficher la blague, celle-ci est tirée aléatoirement à chaque cycle et enfin teams_score sert à définir l'avatar de chaque équipe ainsi que le nombre de points dans la partie.

La définition des évènements de notre machine

GET_NEW_JOKE : Est un évènement qui permet de tirer une nouvelle blague

START_TIMER : Est un évènement qui permet de démarrer le décompte de temps

SELECT_WINNER : Est un évènement qui permet d'indiquer le gagnant du duel en cours.

Commençons par partager le code de notre machine et expliquons chaque éléments les uns après les autres.

Le truc bien avec XState c'est que l'on peut utiliser le vizualizer pour récupérer un diagramme représentant les états et transitions de notre machine. Pour le code ci-dessus, voici le diagramme obtenu.

Pour plus de détails et de contrôle  il est possible de suivre ce lien pour consulter le diagramme en détails.

Explication des parties de notre machine à états

Tout d'abord on définit deux interfaces Typescript qui nous servirons à définir d'une part le contexte (équivalent de l'état qui peut changer) de notre machine, comme vu plus haut, mais également les évènements qui permettront de déclencher les transitions, grâce à cela on obtient un typage sécurisé en utilisant la généricité de la méthode createMachine.

Ensuite, on continue en donnant un identifiant à la machine avec la clé id, cela sert à des fins de debug. Un état initial, dans notre cas choose_joke et un contexte par défaut qui sera probablement surchargé afin que l'on puisse injecter de la donnée.

S'en suit la définition de nos différents états, commençons par choose_joke

On voit ici que plusieurs hooks sont définis :

entry : permet de définir une action à exécuter à l'entrée dans l'état choose_joke. Dans notre cas on fait appel à une fonction getRandomBackgroundColor qui nous permettra de changer le contexte avec une nouvelle couleur. Cette fonction est définie par défaut dans le second argument de notre méthode createMachine, à savoir la configuration, qui notons-le peut être surcharger au moment ou nous allons exécuter notre machine. Ici rien de sorcier, on utilise lodash pour tirer aléatoirement une couleur de fond d'écran, puis on utilise la méthode assign de XState pour fusionner la donnée dans le contexte actuel de la machine.

Ensuite nous avons invoke, ce qu'on appelle un service dans XState. 

id permet de cibler ce service plus tard et de mieux le repérer dans le générateur de diagramme.

src permet d'indiquer la fonction qui retourne une promesse à exécuter dans le cadre de ce service, ici pour un meilleur debug et une meilleur visualisation on utilise encore une référence textuelle à une fonction qui renvoie une blague de manière asynchrone

onDone est l'action à exécuter quand la promesse résous, dans notre car on déclenche une action qui vient modifier le contexte de notre machine pour mettre à jour l'interface. On pourrait également transitionner vers un autre état si l'on voulait plus de granularité, ce n'est pas le cas ici.

Cela n'a pas été fait mais on aurait également pu gérer un onError pour le cas où la promesse échoue.

Enfin nous avons la clé on qui permet de définir les réponses aux évènements qui correspondent à notre définition.

START_TIMER permet de déclencher le changement de phase vers l'état du timer.

GET_NEW_JOKE permet de changer la blague en re-exécutant les hooks vu plus haut.

Ici très simple, on utilise l'instruction after pour définir une période de temps après laquelle on exécutera une action. Dans notre cas c'est un changement d'état vers choose_loser.

Encore une fois on utilise une référence textuelle vers la configuration de la machine mais on aurait pu simplement passer la durée en clé (ce qui est moins pratique mais plus simple pour tester).

Ici, selon l'environnement React Native que l'on soit en mode développement ou production la durée est raccourcie à 2 secondes au lieu de 10 secondes pour développer plus facilement.

On atterri ensuite dans la phase de choix du perdant, où si quelqu'un à rigolé durant la phase précédente il fait marquer un point à l'équipe adverse.

Ici on utilise encore l'instruction on sauf qu'on y rajoute un paramètre sous forme de tableau.

XState va évaluer dans l'ordre les éléments en y appliquant la condition définie et cond et référencée en option de la machine. Lorsqu'une condition sera bonne XState s'arrêtera et exécutera les actions définies dans le bloc.

Dans notre cas on vérifie si l'évènement à reçu un argument avec la référence vers le perdant, si c'est le cas on adapte le score en cohérence, sinon on migre simplement vers l'étape choose_joke

Maintenant que l'on a réussi à définir notre machine à états, comment utiliser cette dernière avec React ? Et bien c'est très simple grâce à la librairie pour react fournie par XState.

Si vous voulez essayer Jerry, vous pouvez aller télécharger l'application sur IOS ou Android et nous faire un petit retour, cela sera avec plaisir :-)

Comment nous avons utilisé XState pour les premières versions de notre application Jerry, développée en JavaScript avec React Native.

Comment utiliser XState pour gérer l'état d'un jeu mobile React Native?

Les problèmes quand on essaye de gérer un état composite avec des booléens

Essayer de gérer l'état d'une fonction par l'utilisation de booléens pose plusieurs problèmes fondamentaux. Le premier est souvent appelé "explosion booléenne". Pour chaque booléen que nous ajoutons à une fonction, nous augmentons le nombre d'états possibles à un taux de 2^n où n est le nombre de booléens. En faisant le calcul quelques fois seulement, on obtient rapidement une quantité absurde d'états.

Le deuxième problème est que beaucoup de ces états sont des "états impossibles", des états dans lesquels notre application ne devrait jamais se trouver. Par exemple si on gère un état pour un animal avec un booléen estVivant est un autre estEntrainDabboyer on se rend compte qu'on ne peut pas être mort et être entrain d'aboyer en même temps. Pourtant au fur-et-à-mesure que le nombre de booléen s'enchainent et complexifie notre état, il y a de plus en plus de chances qu'à un moment on se retrouve dans un état comme celui-ci, ce qui ne devrait pas arriver.

Pour résoudre ce problème une manière saine est d'énumérer les états possibles et les évènement qui permettre de transitionner d'un état à un autre de manière déclarative, plutôt que de manière impérative.

Ce qui suit m'a pris quelques années à apprendre et surtout comprendre et m'a valu nombre d'essais et d'erreurs dans les logiciels que j'ai conçus. Je vais tenter de vous l'illustrer avec un exemple : Imaginons un logiciel d'achat de Pizzas, on choisit une quantité puis on clique sur « commander 

Une approche naïve avec React serait d'avoir un formulaire de la sorte où l'ont gère la quantité et l'état d'envoi avec deux booléens.

Par la suite on nous demande de gérer des erreurs, puis comme le traitement du formulaire prends un certains temps, on nous demande de gérer un état de soumission du formulaire qui désactive le bouton pendant le chargement.

Nous sommes donc à 3 états booléens, soit 2^3 états possibles, soit 8 états possibles ce qui commence à faire.

Comme vous pouvez le voir, cela devient très verbeux et les possibilités d'erreurs et d'oublies sont assez probables.

Mais, à ce stade, nous devons nous poser une question : est-ce qu'on veut vraiment être le prochain développeur à travailler sur ce formulaire ?

Je ne pense pas. Le code est complexe. Il y a des états à gauche et à droite. Il y a même des paramètres à des endroits où nous ne sommes même pas sûrs d'en avoir besoin. Et nous essayons d'éviter de mettre notre composant dans des états impossibles.

On peut constater que le nombre d'États commence à augmenter très rapidement. Mais avons-nous réellement autant d'états dans notre programme ? Notre formulaire utilise actuellement trois booléens, mais a-t-il vraiment huit états ? Non, la plupart de ces états sont impossibles. Par exemple, nous ne pouvons pas être dans un état où isSuccess, error et isSubmitting deviennent tous vrais. C'est impossible.

Alors pourquoi donnons-nous à nos programmes la possibilité d'être dans des états impossibles ?

C'est quoi l'énumération d'états et comment faire ?

L'énumération, qui consiste à identifier un ensemble de choses une par une, est un moyen simple mais efficace de rendre nos programmes un peu plus robustes.

Compte tenu des mêmes exigences, on rend compte que notre formulaire ne peut se trouver que dans une poignée d'états. Énumérons-les :

Remarquons à quel point il est simple d'envoyer des événements et de s'assurer que notre composant est dans le bon état. Nous avons également beaucoup moins de conditions et de guards qu'auparavant. En éliminant l'existence d'états impossibles, nous avons créé un code dans lequel nous pouvons avoir une grande confiance.

Maintenant reposons-nous la question « souhaite-t-on vraiment être le prochain développeur à travailler sur ce formulaire ? »

En ce qui me concerne la réponse serait oui, mais bien évidemment il existe des outils qui nous permettre d'encore mieux représenter la gestion de nos états. Cela est présenté dans un autre article qui explique comment gérer l'état d'un jeu mobile à 3 étapes par tours en utilisant la librairie X-State

Gérer ses états en utilisant seulement des booléens peut augmenter la complexité du code. Utiliser des énumérations d'états est beaucoup plus productif et maintenable.

Utiliser des énumérations pour gérer des états plutôt que des booléens.

À quoi sert l'attribut « autocomplete » du navigateur ?

L'attribut autocomplete ou autofill permet au navigateur de remplir automatiquement des champs de formulaire si l'utilisateur a sauvegardé des données dans ce dernier.

En 2017 l'auto-complétion à permis aux utilisateurs de gagner un temps énorme, c'est une fonctionnalité dont on a l'habitude de se servir et qui sert beaucoup.

Cependant c'est tellement pratique que parfois le navigateur va remplir des données dans nos formulaires, alors qu'on aimerait qu'il ne le fasse pas pour X raison. Par exemple car il ne le fait pas comme on le souhaite par défaut.

Pour cela la spécification officielle indique qu'il suffit de mettre l'attribut autocomplete à off. Comme présenté ici-même :

Mais comme ça n'est jamais si simple, les navigateurs basés sur chromium n'interprètent souvent pas correctement la valeur de cet attribut.

Et bien que cela soit embêtant, ce n'est pas forcément hors-spécification car en effet :

https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofilling-form-controls%3A-the-autocomplete-attribute

The autocomplete content attribute can be used to hint to the user agent how to, or indeed whether to, provide such a feature

En effet avec le HTML, cet attribut (comme tout autre) est une suggestion au navigateur.

Pour compliquer un peu plus les choses, les navigateurs peuvent également remplir automatiquement les champs de formulaire en se basant sur les attributs name ou id du champ.

C'est ainsi que les navigateurs procédaient avant l'arrivée de l'attribut autocomplete (la bonne vieille époque… ou pas)

Comment utiliser efficacement l'attribut « auto-complete » ?

Pour une prise en charge maximale, il est donc intéressant de bien utiliser les attributs name et autocomplete.

Mais si on souhaite que Chrome (et d'autres navigateurs) arrête de remplir automatiquement les champs, on devrait utiliser un nom, un id et une valeur d'auto-complétion que le navigateur ne reconnaît pas.

Maintenant souvent il suffit de changer uniquement la valeur d'autocomplete, mais dans le doute si vous voulez vraiment vous assurer que cela n'arrivera pas il faut agir sur les trois champs.

Ce que je propose donc pour désactiver la saisie c'est de mettre l'attribut à la valeur nope qui ne corresponds donc à rien (que le navigateur reconnaisse en tout cas). De cette manière le champ n'est plus auto-complété :) On aurait pu mettre n'importe quoi mais je pense que sémantiquement c'est toujours bien d'avoir un nom parlant.

On pourrait penser qu'il suffit de mettre autocomplete="off" mais malheureusement c'est un peu plus compliqué, cet article donne une technique pour solutionner le problème

Empêcher Chrome d'ignorer l'attribut autocomplete=off dans son formulaire HTML

Lorsque l'on développe une application NextJS il est fréquent de vouloir définir des mises en pages communes entre nos différentes pages.

Se pose alors le problème de la réutilisation. La documentation officielle nous propose une approche certes pratique mais un peu sommaire de comment gérer ses mises en page.

Une méthode simple pour gérer ses gabarits

Un composant LayoutFactory qui permet à partir d'une propriété de venir charger dynamiquement un layout donné.

Un fichier de types qui permet de définir un contrat d'interface entre nos page et nos mises en page

Des composants de layout respectant ce contrat d'interface

Et enfin une mise à jour dans le fichier pages/_app.tsx pour prendre en compte notre layout

Commençons par le fichier de définitions de types, ici on a CodingSparkAppProps qui sont nos propriétés qui seront utilisées dans pages/_app.tsx puis on définit CodingSparkPageLayoutProps qui surcharge un type assez générique LayoutArgs avec les layouts qui sont disponibles pour notre application.

On étends bien évidemment les types par défaut de NextJS : NextPage.

Dans le fichier qui suit on notera que par défaut on gère un layout « none » ce qui signifie qu'il n'y a pas de mise en page. C'est utile dans le cas où vous n'avez pas encore migré l'intégralité de vos pages vers ce système de layout.

Ici car on en a peu, on part sur un switch/case mais on pourrait bien utiliser une table de correspondance comme une Map ou un objet. C'est d'ailleurs ce que je vous invite à faire si vous commencez à avoir beaucoup de layouts.

À noter qu'on utilise next/dynamic pour ne charger les layouts que lorsqu'ils sont utilisés afin de d'optimiser les premiers chargements de l'application avec du chunking.

Enfin très simplement on va aller « Taguer » notre page avec les meta-données que l'ont a définies plus haut dans le fichier d'interfaces.

And voilà, rien de bien compliqué on profite même de l'auto-complétion !

La dernière chose qu'il nous reste à faire et brancher nos layouts avec notre application, pour se faire on procède de la sorte dans le fichier page/_app.tsx.

Il ne reste plus qu'à savourer le doux parfum de la réussite… 😌

Un pattern de conception pour gérer facilement ses layouts par page sur une application NextJS.

Gérer différents layouts persistants avec NextJS et Typescript

React Hook Form est l'un des frameworks les plus performants et flexibles pour react et react native pour construire des formulaires. Tandis que yup est l'une des bibliothèques les plus simples et les plus agréables pour valider la structure des données. En combinant les deux, vous obtenez un flux de travail fluide et efficace que je vous suggère fortement d'essayer.

Quelques interrogation me venaient cependant souvent à l'esprit :

Pourquoi devrais-je importer yup dans chaque composant où j'ai un formulaire ? En plus du fait que l'auto-importation de yup est assez bancale avec Typescript.

Comment puis-je écrire moins de code et profiter de l'inférence de type TypeScript ?

Après avoir remarqué que je copiais à chaque fois le même code, j'ai fini par créer ces deux hooks pour pouvoir concevoir rapidement un formulaire avec sa validation dans une application react.

Créer facilement un formulaire avec React Hook Form et Yup pour la validation

Et après quelques réflexions, voici ces extraits de code qui profitent de l'inférence de type TypeScript pour donner l'auto-complétion et la sécurité de type.

Rien de bien compliqué, il suffit simplement de copier le code ci-dessus et essayez de l'utiliser, il a été fait en deux formats différents, chacun ayant son propre but.

Faites attention au fait que vous n'avez pas besoin de passer un resolver aux arguments useform car il sera de toute façon écrasé par l'extrait de code comme vous pouvez le voir.

La vraie valeur ajoutée ici est dans l'inférence de type Typescript qui donne une bonne auto-complétion et la sécurité des types.

En utilisant un schéma yup déjà existant

Ou en utilisant la fonction de construction

Si vous n'avez pas encore de schéma et que vous ne voulez pas importer yup partout, utilisez la fonction d'usinage. De plus, cela permet de jouer avec la validation dynamique.

Cela a un léger coût en termes de performances, car le render est renouvelé à chaque fois, ce qui implique la création d'un nouveau schéma à chaque fois. C'est pourquoi vous pouvez envisager l'autre approche si jamais des problèmes de performances se font sentir.

Cet article propose deux « hooks » pour react-hook-form et yup afin de vite développer vos formulaires sans devoir importer plusieurs fichiers.

Gérer ses formulaires avec react-hook-form et yup avec une validation très simple

Utiliser la fonction process.env pour consommer des variables d'environnement dans son programme NodeJS est très fréquent, c'est d'ailleurs une bonne pratique des «Twelve-Factor App» — un manifeste pour concevoir des applications qui se mettent à l'échelle automatiquement—.

Par défaut quand vous installez les types ambiants TS de NodeJS (@types/node) dans votre projet javascript, les types de process.env sont définis comme tels :

Et bien on voit que l'objet process possède une propriété env de type ProcessEnv (une interface). Cette interface est composée d'un objet ayant des clés sous forme de string et des valeurs string ou non définies.

Super ! Le compilateur typescript ne criera pas si vous tapez process.env.HOST par contre, vous êtes obligés d'aller voir les variables d'environnement injectée pour savoir quelles variables sont disponible à l'utilisation.

Vous en conviendrez : il y a mieux comme expérience de développement.

Typescript permet de surcharger des définitions ambiantes d'un autre module très simplement en utilisant un concept nommé fusion d'interfaces (interfaces merging), grâce à cela nous allons pouvoir définir en amont la représentation des valeurs disponibles dans process.env.

Surcharger les définitions de process dans NodeJS afin d'avoir de l'autocompletion

Dans un fichier que j'appelle modules.d.ts nous allons définir les choses suivantes.

Attention : Ce module doit être dans le scope du projet défini dans le tsconfig afin que le compilateur le trouve et le prenne en compte

Désormais, votre compilateur et IDE devrait vous proposer de l'autocompletion et une bonne validation.

Comment obtenir de l'autocompletion de types en surchargeant un module indépendant ? L'exemple de process.env avec NodeJS et Typescript.

Comment définir les types de process.env avec typescript pour avoir de l'auto-complétion

De nombreuses possibilités s'offrent à vous pour développer vos applications, on ne peut pas tout connaitre et la spécialisation — du moins dans un langage de programmation — est une façon de pouvoir être efficace dans ce que vous produisez.

Pourquoi apprendre Javascript pour vos réalisations et pas un autre langage ? Voici 5 raisons — entre-autres — qui pourront vous aider à vous décider à franchir le pas.

De nombreuses choses sont à apprendre lorsque l'on réalise une application, il faut comprendre chaque concepts, pratiquer et mémoriser. Vous pouvez faire cela seul mais c'est toujours plus agréable de traverser le désert à plusieurs.

Sérieusement, vous trouverez de tout et n'importe quoi, du bon et du mauvais. Pensez donc à faire le tri et sélectionnez les outils éprouvés dans un premier temps. 😊 N'hésitez pas à regarder le nombre de « stars » sur Github ou bien questionner quelqu'un de plus expérimenté.

Javascript est également appuyé par les géant du web, ces derniers créent de nombreuses librairies de code « Open Source ». Par exemple Facebook propulse le très célèbre framework permettant de créer des interfaces utilisateurs ReactJS (nous y reviendrons plus tard), AirBnB et Netflix sont d'ailleurs des utilisateurs de cette technologie.

Enfin le gestionnaire de paquet de NodeJS : NPM contient tout ce qu'il faut pour répondre à l'intégralité de vos besoins. Vous y trouverez des librairies qui répondent à des problématiques qui ont probablement déjà été résolues par d'autres développeurs, il suffit de chercher un petit peu avant de développer votre fonctionnalité.

Grâce à JS aujourd'hui vous pouvez vraiment prétendre être un développeur « Full Stack ».

Un développeur en mesure de réaliser n'importe quelle partie de la chaîne de montage d'une application mobile ou d'un site web.

C'est également la possibilité de démarrer un projet sur n'importe quelle plateforme :

Des applications mobiles avec React Native ou Cordova.

Des applications web performantes avec ReactJS, VueJS ou Angular .

Avec NodeJS vous pouvez créer de petits scripts à faire tourner sur vos machines ou bien un vrai serveur d'application capable de traiter des requêtes dans le cas d'une API web par exemple.

Enfin avec Electron vous pouvez créer des applications bureautique, le célèbre IDE VSCode développé par Microsoft utilise cette technologie.

C'est une tendance forte et elle continue encore aujourd'hui, le marché du travail des développeurs est à la hausse. Cependant si vous observez de près ce marché, vous remarquerez que les profils de recrutement s'axent sur des outils et technologies en particulier. Les recruteurs cherchant des profils spécialisés.

En France en PHP nous aurons des demandes de connaissances sur des outils tel que Symfony ou Drupal. Dans le milieu Javascript, des frameworks frontend tel que ReactJS.

Spécialisez-vous donc dès aujourd'hui dans un domaine technologique et javascript est une option solide.

En effet c'est un choix judicieux car une partie du marché, notamment les startups sont en recherche de nombreux profils de développeur maitrisant des outils à base de JS.

Un profil Github bien alimenté en librairies ainsi que quelques références de vos travaux feront fuser vos messages privés de démarchage sur LinkedIn ! Alimentant un cercle vertueux qui si vous savez bien l'alimenter pourrait bien mettre à bas votre précarité et votre besoin de chômage !

4. Aujourd'hui Javascript est le langage qui fait fonctionner l'intégralité du web

Présent notamment dans tous les navigateurs web bureau mais également mobile, il n'existe à ce jour plus aucune page web qui n'utilise pas cette technologie pour dynamiser son contenu.

Connaissez-vous un autre langage de programmation de haut niveau répandus qui peuvent en dire autant ? Sauf erreur de ma part, je n'en connais pas.

Outre le fait que vous pouvez développer du côté serveur et du côté client — ce qui déjà un bel avantage —, vous pouvez également comprendre le fonctionnement et mettre en place nombreux outils présents sur le marché du web.

Par exemple Google Analytics ou Facebook Pixel sont des librairies propriétaires visant à installer un petit morceau de code sur votre application afin de pouvoir analyser le trafic et cibler de manière plus efficace votre audience.

Enfin dernier point et pas des moindres : malgré sa création et son utilisation depuis plus de 20 ans à ce jour, le JS d'aujourd'hui, dit « moderne » est une technologie ayant connu une renaissance, en constante évolution et promue à un bel avenir.

Faire ce choix aujourd'hui c'est s'appuyer sur des technologies qu'un nombre croissant d'utilisateurs vont utiliser de plus en plus dans les prochaines années, soutenues notamment par les géants du web.

De part sa flexibilité, vous pourrez réaliser des applications répondant à des usages très basique ou de très gros système d'information digne de géants du web. Et ce, sur la majorité des plateformes déjà supportées mais également sur de nouvelles plateformes qui apparaissent petit-à-petit dans nos vie tel que l'Internet Of Things (IOT) ou la Réalité Virtuelle (VR).

Pourquoi Javascript est un langage adapté aux développeur d'aujourd'hui ? Découvrez 5 bonnes raisons d'apprendre à programmer en JS pour créer des applications modernes et performantes.

5 Bonnes raisons de developper en JavaScript

Pourquoi ne peut-on pas directement utiliser async/await avec useEffect dans React ?

Il va sans dire que le hook useEffect est très pratique car il permet de déclencher des actions en fonction de changement d'état ou de props, cependant par défaut il n'est pas possible du d'utiliser facilement du code asynchrone à l'aide de la syntaxe async/await.

À première vu on pourrait être tenté de faire quelque chose de la sorte pour récupérer le contenu d'une API distante.

🤔  Qu'est-ce qui ne va pas avec ce morceau de code ?