🐫 🎙️ 👩🏾‍🤝‍👨🏿 Pourquoi est-il temps d'arrêter d'utiliser JavaScript IIFE 👼🏽 👩🏿‍✈️ 🥒

La fonction Expression de fonction immédiatement invoquée (IIFE) en JavaScript est une construction qui vous permet d'appeler une fonction immédiatement après sa définition.

Dans cet article, nous comprendrons pourquoi il vaut la peine d'abandonner l'utilisation de l'IIFF, malgré ses mérites antérieurs.

Nous pouvons déclarer des variables à l'intérieur de blocs autonomes

Depuis que la norme ES6 a vu le jour, nous pouvons déclarer des variables et des constantes à l'intérieur d'un bloc avec let et const. Parallèlement à cette norme, il est également devenu possible d'allouer des variables et des constantes en blocs autonomes, inaccessibles de l'extérieur.

Par exemple:

{
 let x = 1;
}

Alors x ne sera pas accessible de l'extérieur. C'est clairement mieux que:

(()=>{
 let x = 1;
})();

Maintenant que ES6 est pris en charge par presque tous les navigateurs modernes, nous devons cesser d'utiliser IIFE pour séparer les variables du monde extérieur. Une autre façon d'isoler les variables consiste à utiliser des modules qui n'ont désormais plus aucun problème à les supporter. Jusqu'à ce que nous les exportions, ils ne seront pas disponibles pour d'autres modules.

Nous pouvons nous débarrasser de presque toutes les fermetures

La fermeture est un mécanisme par lequel une fonction se souvient de ses variables externes et peut y accéder. Si à l'intérieur de la fonction, nous en créons une autre et la renvoyons, alors la fonction retournée pourra accéder aux variables externes qui sont internes à la fonction externe.

Par exemple, ici, nous pouvons obtenir des effets secondaires:

const id = (() => {
 let count = 0;
 return () => {
   ++count;
   return `id_${count}`;
 };
})();

Encore une fois, cela n'a plus de sens de clôturer tout ce jardin, car nous avons des blocs et des modules autonomes pour l'isolement des données. Nous pouvons simplement mettre tout cela dans notre propre module, alors nous n'aurons pas à nous soucier de l'accès aux données.

Les fermetures provoquent des effets secondaires, ce qui n'est pas très bon, car les meilleures pratiques et le bon sens nous demandent de les éviter autant que possible. Ils rendent difficile le test de fonctions qui ne sont pas propres dans ce cas.

De plus, vous ne devez pas produire de fonctions imbriquées lorsque cela peut être évité: avec elles, le code devient plus déroutant que sans elles.
La meilleure alternative est de les remplacer par des modules:

let count = 0;
export const id = () => {
 ++this.count;
 return `id_${count}`
}

Dans le code ci-dessus, nous avons la même déclaration pour la variable count et exportons la fonction id () afin qu'elle soit disponible pour les autres modules. Nous masquons donc count et ouvrons id (), comme nous le voulions, uniquement sans utiliser IIFE. En conséquence, nous obtenons moins d'imbrication et nous nous débarrassons de la nécessité de définir une autre fonction et de l'exécuter.

Nous pouvons créer des alias pour les variables différemment.

Nous pourrions écrire ceci:

window.$ = function foo() {
 // ...
};(function($) {
 // ...
})(jQuery);

Mais maintenant, il n'est plus nécessaire d'utiliser IIFE pour créer des alias. En utilisant des modules, nous pouvons simplement importer une variable sous un nom différent, créant ainsi un alias pour elle.

Et puis il suffit d'écrire:

import { $ as jQuery } from "jquery";
const $ = () => {};

De plus, vous ne devez pas ajouter de nouvelles propriétés à l'objet window, car cela pollue la portée globale.

Nous pouvons facilement obtenir un objet global.

Avec l'avènement de globalThis, nous n'avons plus à nous soucier du nom de l'objet global dans divers environnements car il devient la norme.

Nous pourrions utiliser IIFE pour capturer un objet global:

(function(global) {
 // ...
})(this);

Mais maintenant, ce n'est pas nécessaire. Oui, et avant il était possible de s'en passer, simplement en écrivant la ligne suivante:

const globalObj = self || window || global;

Pour être plus précis, vous pouvez écrire ceci:

const getGlobal = () => {
 if (typeof self !== 'undefined') { return self; }
 if (typeof window !== 'undefined') { return window; }
 if (typeof global !== 'undefined') { return global; }
 throw new Error('unable to locate global object');
};

Et puis, vous ne pouvez pas ajouter un appel de fonction et une imbrication supplémentaires qui apparaissent lors de l'utilisation de IIFE.

Nous pouvons faciliter la minification

Avec les modules JavaScript, nous n'avons plus besoin de séparer le reste du code de l'IIFE afin de réduire correctement nos fichiers.

Webpack, Browserify, Parcel, Rollup et ainsi de suite peuvent fonctionner correctement avec les modules, nous devons donc les utiliser pour créer un code plus propre.

Conclusion

Il est temps d'arrêter d'utiliser IIFE dans notre code. Cela ajoute des fonctionnalités supplémentaires et une imbrication redondante.

De plus, c'est maintenant un anachronisme: l'IFEF était utilisé avant même l'avènement et l'utilisation répandue des modules en JavaScript. En 2020, nous devons utiliser des modules et des blocs autonomes pour séparer le code.

Pour empêcher l'accès externe aux variables à l'intérieur du module, nous pouvons utiliser des étendues de bloc.