Débat JavaScript : Named imports contre default imports

Un débat sur le type d'import que l'on utilise en JavaScript est apparu récemment. C'est un peu le même type de débat sur celui des point-virgules. Peu importe ce que tu choisis, ça fonctionne, mais chaque développeur a son avis sur la chose et personne n'est d'accord. J'ai aussi mon avis.

Pour faire court : je préfère les named imports. La version longue de ma réponse est ci-dessous.

Quel est la différence entre les default imports et les named imports ?

Il s'agit d'un détail très subtil comme d'habitude dans ce genre de débat.

import detectRotation from 'rotate'

Ce premier exemple consiste à récupérer le symbole par défaut d'un module JavaScript et le stocker dans une variable du nom de detectRotation.

import { detectRotation } from 'rotate'

Les named imports ont l'air moins simples. En effet, on déstructure le module pour ne récupérer que les symboles dont on a besoin dans celui-ci.

Le sens, les outils et le clean code

Si les développeurs se disputent sur la méthode d'importation à utiliser c'est qu'il y a bien quelques différences autres que la syntaxe.

Tout d'abord les default imports n'ont pas de nom. Ou plutôt, ils perdent leurs noms à l'exportation. Que ce soit des variables, constantes, objets, classes, etc : ils possèdent un nom dans leur module. Ils sont exportés en tant que default et cela devient un peu leur nouveau nom.

Ainsi lorsque l'on écrit :

import detectRotation from 'rotate'

on n'importe pas detectRotation de l'intérieur du module rotate mais on importe le default symbole du module rotate que l'on renomme detectRotation dans le module courant.

Et c'est là une des plus grosses raisons que j'ai de préférer les named imports. Parce que rien ne m'indique que c'est bien la fonction detectRotation qui est exporté en tant que default dans ce module.

À l'inverse, lorsque l'on écrit :

import { detectRotation } from 'rotate'

il s'agit bien de la fonction detectRotation que j'importe du module rotate. Si cette fonction n'existe pas mes outils de développement (éditeur, linteur, langage services, etc) me le feront savoir de façon plus ou moins insultante. Au pire, mon import plantera à l'exécution dans l'interpréteur.

Certains me diront qu'il suffit de lire la documentation du module pour savoir comment l'utiliser, mais je n'ai pas envie de faire une recherche dans la documentation à chaque fois que je reviens sur du code deux semaines après l'avoir écrit.

Je pense que le code doit être le plus clair et compréhensible possible de lui-même et les named imports sont une bonne option pour ça.

Les standards des communautés

Dans plusieurs autres articles sur les bonnes pratiques, le linting et autres méthodologies, je conseille de suivre au maximum la façon de faire de la communauté.

Un des buts de ce conseil est de faciliter le travail en équipe et donc d’améliorer la maintenance d'un projet. Il y a quand même plus de chance qu’un nouveau développeur connaisse les choix "standard" de la communauté plutôt que les vôtres…

En fait, vous pouvez traduire ce conseil en :

Faites passer le bien de l'équipe avant votre bien personnel

Qu’en est-il pour le débat "named import vs default import" ? On ne déroge pas à la règle, les différentes communautés ont leurs propres avis sur la question.

Par exemple, celle d'Angular préfère nettement les named imports. On peut l'observer d'ailleurs dans la documentation d'Angular. Il n'y a presque pas (voir pas du tout) d'import ou d'export en default.

import { ProductAlertsComponent } from './product-alerts.component.ts'

À l’inverse, la communauté React a choisit d'utiliser les default imports en fonction de la situation. Comme le raisonnement est un peu plus complexe que "nous on fait que du named import" ou "on fait que du default import", et que je trouve leur logique plutôt intéressante, je vais prendre le temps de la détailler ici.

Tout d'abord, le fichier qui contient un composant doit porter le même nom que celui-ci. Ce composant est exporté en default.

Ensuite vous pouvez exporter d'autres choses utiles des fichiers de vos composants. Comme des hooks, des utils, la version de test de votre composant, etc...

import ProductAlerts, { useProducts } from 'ProductAlerts.ts'

Bien-sûr il y a des exceptions et des cas particuliers mais l'essentiel est là. Et même si je préfère les named imports pour des raisons déjà citées plus haut dans l'article, je trouve que cette façon de faire n'est pas illogique du tout.

Encore une fois, chaque communauté a ses préférences et il vaut mieux les adopter pour faciliter le travail en collaboration ainsi que d'autres aspects de nos vies de développeurs (review de code, etc).