Why did I make the npm library?

#angular #typescript #npm #tooling

First of all, many thanks for showing the interest in this article. 👀

In the next few passages, I will try to explain why in many Angular projects it is important to have good modal and notification features as well as why I wrote the npm library on that subject.

In the professional world, I have several years as an Angular developer behind me and a few more of developing in other technologies.

Web development abstract

Angular is for sure one of the worthy things that improved web development in the last ten years. The way it handles the view of the HTML and how it binds it with typescript is great.

The small minus is, like in almost any other framework which imposes their own structures, that the developers can be brought into the situation to just follow the basic imposed way of creating things. Often a framework dominates with architecture and the intended paths that should be followed. That does not mean that we should not think out of the box.

How is Angular doing it, out-of-the-box

As we know, Angular is providing an easy way to call another component from HTML with the tag selector to be rendered into the DOM. It also provides a way to call another component and render its view to the DOM, but only from typescript, which is called dynamic component creation and it's a bit more complicated way, but that does not mean it is not a good way, it's just harder.
That is where out-of-the-box thinking comes to the foreground, of course, it is not bad to use HTML component selectors but there are some use cases where it is better to use dynamic component creation. Under the hood, the Angular itself uses that same way, and we can choose how and from where we will evoke the component in the way the angular engine does it.

What can we do?

Here comes the modal story; what if we create a modal from the typescript method, what if the object itself can evoke the modal with a form to edit itself? That is a really nice use case now, and how is that good? For example, if we have a list of items and every item object has an update method, it can evoke the edit form component in the modal from any part of the application, and there is no need for an HTML selector. Wherever the "item object" is, and while it has an update method, it can evoke its own form and bring the popup to a predefined place on the screen.

There are more use cases. A similar thing is with notifications and confirm boxes. The app business logic is not always in angular components, we often make custom classes, services, or in redux architecture, for example, ngrx-effects. Take a look at an example in a service that has an HTTP server request, in case it returns an error it would be nice to evoke some kind of error message directly from there, and not coupling the logic with the component, the view.

Or another example when we want to delete an item, we need some kind of security system as a confirmation box and all we want to know what button is clicked by the user. Is it confirmed or declined so we know wether to delete the item. In the same way, confirm box can be called from any typescript method, and in that way it is more decoupled, it relies on the SOLID principles.

How it started?

In one period of my Angular work, I was requested to find the solution for one specific design pattern. It needed to keep the object reference while the object can be edited from any part of the application, to be modular and callable from typescript. I had read, spent many nights exploring how Angular material is handling the dynamic components, and after a while I got some knowledge about that topic and delivered the idea.

Time passed and I continued to research the topic from time to time and I decided to write a fully extendable library from scratch which rests on my knowledge of dynamic component creation in Angular.

I decided I want to make it modular and make three modules: Toast notification module, Confirm box module, and Dialog module. Every one of them will have its own logic but common inheritance; It will be highly scalable and easy to change without breaking the public API, and easy to extend with a new functionality; The uncompiled code will be publicly available, intuitive, open to contribution and understanding; It will have high-quality documentation and code examples to make it easy for other developers who will use it.

The library

With good motivation, and little more than a few nights, the code became the usable product, and code comments became the documentation.

I am happy to announce the library ngx-awesome-popup and invite every positive mood developer to contribute with any constructive suggestion, improvement, or bug finding.

Modules are separated as planned, it is a highly customisable and extensible solution, SOLID principles are respected in solid amount, it could even be more optimised in future. It implements a predefined user interfaces with many options for customisations, as well as public API exports such as enums, interfaces, d.ts files to help and make usage nice and easy.

The package is created with "ng-packagr" and API documentation is generated with "TypeDoc", the GitHub repo could be found here.

If you have endured up to there, WOW 😁 thank you for reading, and welcome to playground or StackBlitz.