An Argument Against Requiring IIFEs

From Yanfly.moe Wiki
Revision as of 22:45, 7 November 2021 by Yanfly (talk | contribs) (Running an unnamed one-time planned function)
Jump to navigation Jump to search

Welcome to the wiki! This is where you can find resources from Yanfly.moe, Ækashics.moe,
VisuStella, Caz Wolf, Fallen Angel Olivia, Atelier Irina, and other affiliated content creators.


Yanfly.png This is an article written by Yanfly.

Introduction

Nah IIFE.jpg

This is a programming article, so if you don't understand JavaScript, don't care about JavaScript, or don't care about Immediately-Invoked Function Expressions (IIFE's), this article will probably mean nothing to you.

Now that that's out of the way, let's make sure we're all on the same page here. An Immediately-Invoked Function Expressions (IIFE) is the following:

(function () {
    ...
})();

It's a private scope that's created within the code that will run immediately upon its code being read. This has applications, yes, and from personal experience, there are times where its useful, too.

However, there's been a trend in the RPG Maker community, especially amongst plugin developers, that argue that entire plugins need to be wrapped around in an IIFE. I personally don't believe that. In fact, doing such a thing will often lead to problems later down the road especially if a plugin library gets bigger and bigger.


The Common Arguments In Favor of IIFE's

Here are the things I've seen people argue in favor of IIFE's:

  1. Not polluting the global namespace
  2. Keeping code private and unreadable from NodeJS's dev tools

Not Polluting the Global Name Space

In regards to the first: Not polluting the global namespace, uh, I'm not sure about you, but that's almost never gonna be a major issue especially when programmers become more experienced. Very few experienced programmers actually declare commonly used variable names inside the global namespace unless they have a reason to do it. The majority of programmers already declare their own global namespace object and place their declared variables inside of that instead.

// This is what "polluting the namespace" looks like, while using 
var x = Window_Base.prototype.initialize;
var y = Window_Base.prototype.lineHeight;

// In the above example, uses of 'x' and 'y' can be called from the global namespace.
// Since 'x' and 'y' are highly common variable names, it's likely to be overwritten.
// This can lead to any code that utilize 'x' and 'y' as called functions to not work.

// This what experienced programmers do:
var ProgrammerName = {};
ProgrammerName.Window_Base_initialize = Window_Base.prototype.initialize;
ProgrammerName.Window_Base_lineHeight = Window_Base.prototype.lineHeight;

// Only 'ProgrammerName' appears in the global namespace and it appears as an object.
// The stored functions can be called from 'ProgrammerName.Window_Base_initialize' and
// the like with a low likelihood of being overwritten.

Keeping code private and unreadable from NodeJS's dev tools

In regards to the second point: Keeping code private and unreadable from NodeJS's dev tools, this is meaningless unless you have the code obscured from legibility, too. Especially if the "user", whether it is the game developer or the player, can simply open up the plugin's JS file and read what's there.

While sure, they won't be able to run it directly from the dev tools console, it doesn't change the fact the user can still just copy the contents of a specific function, declare it publicly in the dev tools console (and thus, the global name space), and proceeding to invoke it on demand. See below:

IIFE Example 1.png


Real Applications of IIFE's

Now, let's talk about the real applications of IIFE's. These are arguments that I seldom see mentioned in the RPG Maker community, but I don't want people saying I'm cherrypicking bad examples. Instead, I'll provide legitimate cases for IIFEs:

  1. Isolation of variables, making them private and unchangeable
  2. Running an unnamed one-time planned function
  3. Usage of placing external web functions, content extensions, and/or snippets loaded from cross-net providers (such as analytics, ads, widgets, etc.)

Now, if you're planning on arguing from these perspectives, allow me to elaborate on them, too.


Isolation of variables, making them private and unchangeable

This is the primary and most viable reason for most programmers out there. Programmers are picky and territorial creatures. They don't like it when you touch their code. They especially don't like it when you touch their variables. And before, in the past, programmers would isolate and privatize their variables via IIFE's.

However, nowadays, that's not needed anymore. Why not? Because of the creation of the 'let' and 'const' variable declarations. On top of that, modules are also automatically isolated within their own functions. 'let' and 'const' allowed the restrictions to go to even smaller scopes, such as their own bracketed conditional blocks.

const createId = (function () {
  let id = 0;
  return function () {
    id++;
    return id;
  }
})();

createId(); // 1;
createId(); // 2;
id = 10000; // throws an exception because id is not in scope

Makes sense?

Usage of 'const' to declare a variable in the global namespace prevents it from being changed at all, too.

const x = 100;
x = 200; // throws an error because 'x' was already declared by 'const' and prevents it from changing

Usage of 'let' to declare a variable in the global namespace allows it to be changed, but prevents it from being redeclared.

let x = 100;
x = 200;
console.log(x); // 200

// Variable 'x' can have its variable changed.

var x = 500; // throws an error because 'x' was already declared by 'let'

As you can see, isolating and privatization of variables makes usage of IIFE's for that purpose moot.


Running an unnamed one-time planned function

It makes sense, if you want to make an unnamed one-time planned function to run and then immediately be gone forever, then yeah, use an IIFE for it. In my opinion, you can never tell when you would want to run a function more than once so it's best to keep them publicly available. However, if you do have a case for it, then yeah, I will concede that's a legitimate reason to use the IIFE. In fact, VisuStella MZ does use IIFE's for those reasons, albiet extremely rare.

External web functions, Content extensions, and/or Snippets

The majority of these cases aren't used for games that are created by RPG Maker. And in the event there are uses for them, there's little need to make a counter point. This is probably the only real legitimate case for the usage of IIFE's for RPG Maker games, even if rare.


Incorrect Usage

Plugin-Wide IIFE Wrappers

However, if this argument is to be used to explain wrapping IIFE's around entire plugins, then that makes no sense.

(() => {

const ProgrammerName_Window_ActorCommand_addAttackCommand = Window_ActorCommand.prototype.addAttackCommand;
Window_ActorCommand.prototype.addAttackCommand = function() {
    var NEO_ATTACK_ID = 42;
    if (this._actor.isStateAffected(NEO_ATTACK_ID)) {
        this.addNeoAttackCommand();
    } else {
        ProgrammerName_Window_ActorCommand_addAttackCommand.call(this);
    }
};

})();

I see plugins using the IIFE's like above and see nothing coming out of it. If you remove the IIFE wrappers, you get the same results.

Instead, it's just privately declaring monkey patched variables that are being used for a public function. You get almost the same exact results as the following without any IIFE's:

const ProgrammerName_Window_ActorCommand_addAttackCommand = Window_ActorCommand.prototype.addAttackCommand;
Window_ActorCommand.prototype.addAttackCommand = function() {
    var NEO_ATTACK_ID = 42;
    if (this._actor.isStateAffected(NEO_ATTACK_ID)) {
        this.addNeoAttackCommand();
    } else {
        ProgrammerName_Window_ActorCommand_addAttackCommand.call(this);
    }
};

The difference here is, 'ProgrammerName_Window_ActorCommand_addAttackCommand' can be called from a public scope, which is better by far. Making monkey patches in a private scope create tons of problems. Let's assume the following are two different plugins:

(() => {

const ProgrammerName_Window_ActorCommand_addAttackCommand = Window_ActorCommand.prototype.addAttackCommand;
Window_ActorCommand.prototype.addAttackCommand = function() {
    var NEO_ATTACK_ID = 42;
    if (this._actor.isStateAffected(NEO_ATTACK_ID)) {
        this.addNeoAttackCommand();
    } else {
        ProgrammerName_Window_ActorCommand_addAttackCommand.call(this);
    }
};

})();
(() => {

const ProgrammerName_Window_ActorCommand_addNeoAttackCommand = Window_ActorCommand.prototype.addAttackCommand;
Window_ActorCommand.prototype.addAttackCommand = function() {
    var NEO_ATTACK_ID = 42;
    var SEAL_NEO_ATTACK_ID = 43;

    if (this._actor.isStateAffected(NEO_ATTACK_ID) && this._actor.isStateAffected(SEAL_NEO_ATTACK_ID)) {
        ProgrammerName_Window_ActorCommand_addAttackCommand.call(this);
    } else {
        ProgrammerName_Window_ActorCommand_addNeoAttackCommand.call(this);
    }
};

})();

In the above case, as the two IIFE's created two private scopes, 'ProgrammerName_Window_ActorCommand_addAttackCommand' cannot be used to add the original 'Attack' command anymore that was created by the first instance. While this seems a bit unusual, there are indeed times where you want to be able to call the original functions that are untouched by any modifying code and adding those to a private scope will prevent that. Now if this is the intent of the creator of the said function, then there's really not much else you can do.

But

To go past that, there are also times I've seen where new classes are entirely engulfed inside of the IIFE. This makes it not only impossible to call the class from a public scope, but you can't even make extensions or monkey to patches from a scope different from the own individual private scope.

IIFE 02.png

End of File