Array<Type> vs Type[] en TypeScript : 5 erreurs fatales et comment les éviter

Array<Type> vs Type[] en TypeScript : la bataille des syntaxes que vous devez absolument gagner

Si vous avez déjà écrit en TypeScript, vous avez certainement vu deux façons de déclarer un tableau de nombres :

const numbers1: number[] = [1, 2, 3];\nconst numbers2: Array<number> = [1, 2, 3];

Les deux variantes fonctionnent. Les deux se compilent. Les deux sont du TypeScript valide. Alors pourquoi tant de débats autour d'elles ? Pourquoi cette question sur Stack Overflow a-t-elle rassemblé des milliers de vues ? Et surtout, comment éviter les pièges qui casseront votre projet ?

Éclaircissons cela une fois pour toutes. Sans théorie ennuyeuse. Seulement ce qui sera vraiment utile sur le terrain.

Petit lexique : qu'est-ce que quoi

Syntaxe Type[] (Array Literal Syntax)

C'est la façon la plus courante de déclarer un tableau en TypeScript. Elle vient de JavaScript et semble naturelle :

let fruits: string[] = ['apple', 'banana', 'cherry'];\nlet matrix: number[][] = [[1, 2], [3, 4]]; // Tableau de tableaux

Court, lisible, intuitif. Pour 90% des cas, cela suffit.

Syntaxe Array<Type> (Generic Syntax)

C'est la forme générique, utilisant l'interface intégrée Array<T> :

let fruits: Array<string> = ['apple', 'banana', 'cherry'];\nlet matrix: Array<Array<number>> = [[1, 2], [3, 4]];

Cela semble plus "académique", mais offre plus de flexibilité dans les scénarios complexes.

Top 5 des erreurs que même les développeurs expérimentés commettent

Erreur n°1 : Confiance aveugle en l'autocomplétion de l'IDE

Votre IDE peut suggérer les deux variantes. Mais cela ne signifie pas qu'elles sont interchangeables partout. Prenons un exemple avec des types union :

// Possible ainsi\ntype Status = 'active' | 'inactive';\nconst statuses1: Status[] = ['active', 'inactive'];\n\n// Mais pas ainsi — erreur de syntaxe !\n// const statuses2: Array<'active' | 'inactive'> = ['active', 'inactive']; \n// ❌ Erreur : ';' attendu\n\n// Variante correcte avec le générique :\nconst statuses3: Array<Status> = ['active', 'inactive'];

Conclusion : À l'intérieur de Array<>, vous ne pouvez pas utiliser directement des types union complexes. Définissez-les d'abord dans un type séparé.

Erreur n°2 : Confusion avec les tableaux readonly

Lorsque vous devez rendre un tableau immuable, les syntaxes se comportent différemment :

// ✅ Correct avec Type[]\nconst readonlyFruits: readonly string[] = ['apple', 'banana'];\n// readonlyFruits.push('orange'); // ❌ Erreur : readonly\n\n// ❌ Cela ne fonctionne pas :\n// const wrong: readonly Array<string> = ['apple']; \n// Erreur : le modificateur 'readonly' ne peut apparaître que sur les types de tableaux\n\n// ✅ Correct avec Array<> — utilisez ReadonlyArray :\nconst correct: ReadonlyArray<string> = ['apple', 'banana'];

Conclusion : Pour les tableaux readonly, utilisez readonly Type[] ou ReadonlyArray<Type>. Il est impossible de mélanger readonly avec Array<>.

Erreur n°3 : Problèmes avec les tableaux multi-niveaux

Lorsqu'un tableau contient d'autres tableaux, la syntaxe Array<> devient lourde :

// Lisible et compréhensible\nconst grid1: number[][] = [[1, 2], [3, 4]];\n\n// Déjà plus difficile à lire\nconst grid2: Array<Array<number>> = [[1, 2], [3, 4]];\n\n// Et avec trois niveaux ? Cauchemar :\nconst cube: Array<Array<Array<number>>> = [[[1]]]; // 🤯\n\n// Avec Type[], c'est plus simple :\nconst cube2: number[][][] = [[[1]]];

Conclusion : Pour les tableaux avec une imbrication supérieure à 2, utilisez Type[][]. Vos collègues vous remercieront.

Erreur n°4 : Ignorer le contexte d'utilisation

Dans certains frameworks (Angular, React) et bibliothèques, un style particulier est adopté. Enfreindre la convention peut semer la confusion :

// Angular utilise souvent