javascriptrevealing-module-patternairbnb-js-styleguide

Is there a suitable or recommended design pattern for the airbnb style guide?


I learned about the revealing module pattern which I've taken a liking to. This pattern was described as being useful for not polluting the global scope by wrapping a function in an IIFE and returning only public methods and variables.

const foo = (function() {

    const _private = function() {
        ... do private stuff
    }

    const method = function(){
        ... do public stuff
    }
    
    return {
        method: method
    }

})();

export default foo

However, now that I am using esLint and the airbnb style guide, I got to the section about IIFE where it says:

7.2 Wrap immediately invoked function expressions in parentheses. eslint: wrap-iife jscs: requireParenthesesAroundIIFE

Why? An immediately invoked function expression is a single unit - wrapping both it, and its invocation parens, in parens, cleanly expresses this. Note that in a world with modules everywhere, you almost never need an IIFE.

So I understand that the revealing module pattern is best suited for avoiding polluting the global scope, and since modules are in a local scope it isn't needed in this context. My question is if there exist any design patterns that are well suited to the airbnb style guide, and better abide by the guide itself. The styleguide itself doesn't make mention of any design patterns.

Apologies in advance if this is subjective - I'm not looking for the best design pattern, but for one that is useful in the context of a project using the airbnb style guide, and module export/imports.


Solution

  • As stated by some of the comments below my question, the style guide deliberately avoids recommending any design patterns so as to be applicable to as many users as possible. Many higher level design patterns should not interfere with the linter config the way the revealing module pattern does.

    As for the revealing module pattern, it is not really necessary to use in ES6 as long as your code is separated into modules. It might still be useful if you want to create different local scopes within the same module, but this kind of code can easily be separated into modules with their own global scopes to avoid scope pollution.