Modèles d'autres langages et frameworks pour améliorer vos projets frontaux

Je programme depuis douze ans et j'ai travaillé avec de nombreux langages. Ceux-ci incluent C , C++ , Java , Python , C# et enfin JavaScript . Chaque langage ou framework a ses propres règles. Par exemple, Rust utilise la casse serpent pour les noms de fonction.

Cependant, il existe certaines règles, outils et modèles que j'ai appris à apprécier. Je les intègre dans mes applications frontend. Ces règles résonnent davantage en moi et rendent le codage plus fluide. En voici quelques-unes que je privilégie particulièrement :

Programmation fonctionnelle

Mon premier conseil vient du C, le premier langage que j'ai appris. Tu te souviens quand on écrivait React with classes ? Rien que d'y penser, ça me donne des frissons. Lorsque React est passé aux composants fonctionnels, cela a rendu le code non seulement plus facile à lire, mais également plus facile à tester.

Il s'aligne également mieux sur les principes de la programmation fonctionnelle.

Cette approche fonctionne très bien avec les frameworks frontend car ils se concentrent souvent sur la création de morceaux de code réutilisables. L'utilisation de la programmation fonctionnelle dans le développement frontend a toujours été une stratégie utile pour moi pour comprendre ce concept et aussi pour créer de nouvelles fonctionnalités frontend.

Suivre les principes de la programmation fonctionnelle est indispensable dans chacune de mes applications frontales.

Si vous n'êtes pas familier avec la programmation fonctionnelle, je vous recommande fortement de l'explorer davantage . Ce point n'est pas au début de cette liste sans raison. Les avantages qu'il peut apporter à votre processus de développement sont considérables.

Formateurs de code

Quand j'ai commencé à programmer, je n'ai pas prêté beaucoup d'attention au formatage du code. Je suppose que tout a commencé à l'université où j'apprenais le C++ sur mon super IDE CodeBlocks avec un thème blanc.

En regardant mon ancien code de 2016 sur GitHub , je peux voir que je n'ai utilisé que des espaces pour le formatage. Je n'ai utilisé aucun outil pour m'en occuper automatiquement.

Maintenant, je me rends compte que c'était une erreur. Si vous pouvez automatiser quelque chose dans votre projet, vous devriez certainement le faire. Maintenant, je configure toujours Prettier et ESLint au début de chaque projet. Si vous ne voulez pas passer beaucoup de temps là-dessus, vous pouvez utiliser des configurations préfabriquées comme celle d' Airbnb .

Croyez-moi, vous ne le regretterez pas !

Oh et n'oubliez pas de mettre en place dans votre IDE une action de formatage automatique sur l'enregistrement de fichier !

Actions pré-commit

Maintenant que vous avez des formateurs géniaux, automatisons-les ! Je ne me souviens pas très bien quand j'ai commencé à utiliser les hooks de pré-commit, mais ils m'ont été d'une grande aide dans mes projets. Pourquoi formater manuellement alors qu'il peut être automatisé avant chaque commit ? Des outils comme husky et lint-stage rendent cette automatisation possible.

Kebab-cas pour les noms de fichiers

Même si Angular a de nombreux fans et critiques, j'aime me concentrer sur le positif. Angular est souvent le premier choix pour les grandes entreprises et les grandes applications. Je pense que bon nombre des décisions prises dans Angular visaient à faciliter la maintenance.

C'est pourquoi j'ai décidé d'utiliser kebab-case pour tous mes projets frontaux. Il offre quelques avantages, comme :

• Simplicité : Je n'ai pas à me soucier d'utiliser pascal-case, camel-case ou snake-case (si vous préférez). Avec le kebab-case, il n'y a qu'une seule option.

• Cohérence : si vous travaillez en équipe, l'adoption d'une convention de nommage unique comme kebab-case peut aider à garantir que tout le monde est sur la même longueur d'onde et que le projet reste organisé. N'oubliez pas que vous pouvez forcer l'utilisation de kebab-case via la règle eslint en utilisant le package unicorn :

 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ],

• Compatibilité multiplateforme : différents systèmes d'exploitation traitent les noms de fichiers différemment. Par exemple, Windows ne se soucie pas des majuscules, contrairement à Linux. En utilisant kebab-case, qui utilise des lettres minuscules et des traits d'union, j'évite tout problème.

• Pas de problèmes de git : il y a un problème avec le renommage d'un fichier de minuscules en majuscules dans git. En utilisant kebab-case, je n'ai pas à m'en soucier.

J'aime garder les choses simples. Si je peux me faciliter la vie et en tirer des avantages, je suis tout à fait d'accord.

Utilisation de balises pour les types de fichiers

Une autre chose que j'ai empruntée à Angular est la façon dont ils nomment les fichiers. Angular recommande de nommer les fichiers d'une manière qui reflète leur fonction et leur type. Je trouve que cela me facilite la navigation et la compréhension de la structure d'un projet. Dans Angular, le nom de fichier comporte généralement trois parties : la zone de fonctionnalité, le rôle du fichier et le type de fichier.

Par exemple, heroes.component.ts indique que le fichier est un composant de la fonctionnalité heroes et qu'il s'agit d'un fichier TypeScript. heroes.service.ts est un service pour heroes .

Je ne suis pas un grand fan des services , mais j'utilise une structure similaire pour mes composants React. Voici un exemple :

 my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx

J'utilise également ce modèle pour mes crochets et mes fonctions. Ce patron m'apprend aussi à mettre mes tests à côté des fichiers qui s'y rapportent.

Automatiser la génération de code

Le modèle que j'ai mentionné précédemment est très utile, mais nous pouvons l'améliorer encore avec l'automatisation. Angular CLI permet aux utilisateurs de générer du code automatiquement, et j'utilise toujours plop pour faire de même. Le système de modèles de Plop est très puissant, mais surtout, il permet de gagner du temps.

Avec l'automatisation, je n'ai pas besoin de passer beaucoup de temps à réfléchir à la structure de base d'un composant. Cette tâche peut être automatisée, ce qui me permet de me concentrer sur ce que je veux vraiment faire.

Utiliser un 'Domaine'

Je ne vais pas expliquer en détail ce qu'est un domain ici. Si vous souhaitez en savoir plus, je vous conseille de lire cet article . En ce moment, je travaille avec une équipe de développeurs full-stack, et nous avons constaté qu'avoir une couche de domaine dans notre projet frontend est vraiment utile.

C'est là que nous plaçons tous nos principaux types et opérations. Il sert de "source de vérité" dans notre application.

Si vous voulez voir comment je gère les "domaines" dans mes applications, vous pouvez consulter cet article . J'y passe beaucoup de temps à décrire ce sujet.

Tester votre architecture

Dans notre travail avec Kotlin , nous avons déjà rencontré un problème où la logique se mélangeait sur plusieurs couches, comme l'utilisation d'un type défini dans le référentiel à l'intérieur de notre domaine. C'est interdit du point de vue de l'architecture propre, mais tout le monde fait des erreurs.

C'est alors que nous avons découvert ArchUnit , un outil de test unitaire de notre architecture. Il vérifie essentiellement si nous adhérons correctement à notre architecture.

Si vous maintenez une certaine architecture, il peut être utile d'avoir un outil pour vérifier si elle n'a pas été cassée à un moment donné. Un outil comme dependency-cruiser peut être inestimable à cet égard.

Et cela conclut ma liste essentielle de modèles d'autres langages et frameworks pour améliorer vos projets frontaux. J'espère que vous avez trouvé ces informations utiles et qu'au moins une de ces stratégies vous a inspiré à la mettre en œuvre dans votre propre travail !