Revealing module pattern is beautiful

Sudharshaun Mugundan — Sat, 28 Aug 2021 06:02:59 +0000

Revealing module pattern is one of the sub pattern of the module pattern. Don't know how many people still use module pattern in javascript, and I have seen a fair amount of code which uses RMP.

So what is a module pattern anyway?

The public members are exposed in the return function.
The private members live in the closure.

function greet() {
  const name = "Natasha";
  return {
    function greetHello() {
      return `Hello ${name} ! Thanks for signing up!`;
    }
    function greetWelcome() {
      return `Hello ${name} ! Welcome back!`;
    }
  }
}

How RMP is different from Module pattern?

All the functions live in the closure.
Only the functions that should be exposed are made public under return.
The return functions will not have any function definitions. It will just reference the functions in the private.

(function greet() {
  const name = "Natasha"
  function greetHello() {
    return `Hello ${name} ! Thanks for signing up!`;
  }
  function greetWelcome() {
    return `Hello ${name} ! Welcome back!`;
  }
  return {
    hello: greetHello,
    welcome: greetWelcome
  }
})();
const hello = greet.hello(); //Hello Natasha ! Thanks for signing up!
const welcome = greet.welcome(); //Hello Natasha ! Welcome back!

It gives a flexibility to reference the function name with our choice. Here greetHello is the function but it is exposed as hello. This helps in a lot of scenarios, let's say you are writing an API and the module would want a function name saveDetailsToDB for understanding the logic but not anyone who wants to use the API need that information, so you can just say return {save: saveDetailsToDB} .
Removing the key pair from the return object would make the exposed function private. Whereas in module pattern you have to remove the function from return object.

I have been a big fan of this pattern and it is just an admiration post on how beautiful it is :P

Why to use a Front end framework/library for your application

Sudharshaun Mugundan — Sun, 22 Mar 2020 08:10:13 +0000

1. Code management

Be it a simple Todo list or a Nuclear science project you are working on, your code will get messy. You don't know where the URL came from and how it's handled after a point of time. Eventually you'll end up having yelling WTF is happening here syndrome. But if you are stubborn on not using a framework, use ES Modules to segregate your code module wise.⚡️Give this amazing article a read

2. We don't know to use DOM operations

Yes. DOM operations are costly and pretty much differs from browser to browser. Manipulating and updating the DOM tree efficiently is not a piece of cake. And if your application is going to be big enough, you'll end up thinking about performance and scratch your heads.🤢

3. Direct access to DOM

It ain't a good thing to go and touch the DOM directly. So this depends on the scale of your project. If it's a smol news site which just displays the article from a CMS, cool. It's a one time change. If it's a social network where people fight their ass off and end up having millions of comments,🤕Oh boi don't touch the DOM with bare hands.

Because DOM updation is costly and only the specific DIV or a SPAN has to be updated. That's why libraries like React, Vue and so on make you create the document on their virtual DOM and they do the hard work for you using DOM diff techniques to calculate the dynamic parts of your views. At the end they too are going to query the DOM by using document.getElementById and create elements with document.createElement. So trust a framework on this.

4. You'll end up building your own framework.

When your application grows, it suffers from scalability. So you'll start building custom solutions for the problems and end up developing a half baked framework which might not work for the future cases coming to you.

Let's say you have a templating engine like EJS and got to put the data in a bucket store. First you'll start building a data store and then it requires a middleware rendering engine to get the data efficiently to EJS. So you'll build a rendering engine. Then the routing problem comes and so on. You'll end up investing most of your time reinventing the wheel and in building the infrastructure than the application you want to build. Picking a framework that already has solved the problem you have would be a smart choice.

Conclusion

So plan your architecture and the frameworks you want to use before starting building the application. If you are like if the application grows I'll use a framework, you might suffer from scaling.

Happy hacking 🚀

DEV Community: Sudharshaun Mugundan