Suite de https://css-tricks.com/a-better-api-for-the-resize-observer/ , l'article propose une refonte des API pour MutationObserver et IntersectionObserver afin de les rendre plus simples à utiliser. L'auteur montre comment simplifier l'utilisation de ces observateurs en utilisant des motifs de rappel et d'écouteurs d'événements. Pour MutationObserver, il explique comment observer les mutations du DOM et se déconnecter proprement en utilisant une méthode disconnect. Concernant IntersectionObserver, il détaille comment observer les changements d'intersection d'un élément avec un ancêtre ou une fenêtre de visualisation. Enfin, l'article mentionne une bibliothèque pratique, Splendid Labz, qui offre des utilitaires pour ces observateurs, facilitant leur intégration dans des projets web.
L'article propose une amélioration de l'API pour le ResizeObserver, un outil JavaScript utilisé pour observer les changements de taille des éléments DOM. L'auteur suggère d'encapsuler la logique du ResizeObserver dans une fonction plus simple et réutilisable, ce qui rend son utilisation plus intuitive et proche des modèles d'écouteurs d'événements familiers. En passant un élément et une fonction de rappel à cette fonction personnalisée, les développeurs peuvent facilement réagir aux changements de taille sans avoir à réécrire le code standard du ResizeObserver à chaque fois. De plus, l'article montre comment intégrer des options supplémentaires et gérer l'arrêt de l'observation, offrant ainsi une solution plus flexible et maintenable. Enfin, il mentionne une bibliothèque appelée Splendid Labz qui offre une version améliorée de cet observateur, capable de gérer plusieurs éléments simultanément.
Les Arbres Syntaxiques Abstraits (AST) sont essentiels pour les développeurs, servant de base à des outils comme les compilateurs et les linters. Ils transforment le code source en une structure arborescente, facilitant l'analyse et la manipulation du code. Par exemple, un AST peut clarifier les priorités d'opération dans une expression arithmétique. Le processus de parsing, incluant l'analyse lexicale et syntaxique, convertit le code en AST, permettant des applications variées comme le linting, la transpilation et le refactoring automatique. Des outils comme AST Explorer aident à visualiser et comprendre ces structures, rendant les AST indispensables pour l'analyse et la transformation du code.
L'article décrit une refonte pratique en C# pour transformer des modèles anémiques en modèles riches en comportement, en utilisant les principes du Domain-Driven Design. Il montre comment déplacer la logique métier des services vers les agrégats, améliorant ainsi la maintenabilité et la clarté du code. L'auteur illustre chaque étape avec des exemples de code avant et après la refonte, soulignant les avantages de cette approche.
Un très bon résumé
Tout est dans le titre
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique la nécessité de connaître les principes orientés objet et autres bonnes pratiques (clean code, tests, refactoring, etc.)
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique en quoi travailler dans du code legacy est surprenamment plus agréable que créer du code "from scratch"... Un point de vue peu commun mais intéressant !
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur donne quelques heuristiques pour choisir les parties du code à refactorer, en fonction de leur valeur business et de leur fréquence de changement
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur insiste sur le fait que le refactoring fait partie du quotidien du développeur : ce n'est pas une tâche de la todo liste mais bien une étape de chaque item de celle-ci (cf le nettoyage en fin de service dans un restaurant) Si le refactoring est plus important, alors nommer le ticket sur ce qui est refactoré et pas seulement "refactoring"
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique une manière revisitée de la règle du boy scout - toujours laisser le code sur lequel on a travaillé dans un meilleur état que celui dans lequel on l'a trouvé.
Notamment il donne une procédure d'amélioration continue très intéressante.
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique la technique de refactoring d'extraction de méthode : comment faire et surtout dans quel but - diminuer la complexité, masquer les détails d'implémentation (ne pas mélanger les degrés d'abstraction), etc. Il donne aussi quelques recommandations pour ne pas introduire de bugs subtils (manipulation de tableaux, etc.)
Tout est dans le titre
Un exemple de refactoring d'une classe pour appliquer le principe d'inversion de dépendance
L'auteur effectue le refactoring d'un test en appliquant plusieurs techniques / idées pour le rendre plus lisible.... très intéressant
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre