Effective Use of Angular Framework
Disclaimer : The content of this blog are my views and understanding of the topic. I do not intend to demean anything or anyone. I am only trying to share my views on the topic so that you will get a different thought process and angle to look at this topic.
Angular framework ( Version : 2.x ) is made to create web components, which is not something new in the industry. Many attempts were made in the past for creating web components like Java Portlets and JSF ( Java Server Faces ). It lacked the key ingredient of pure isolation of the component boundary in the DOM.
The main intention of creating web components is to ensure that wherever the component is placed in the UI it behaves the same and is not affected by its surroundings like CSS rules, etc. Angular 2 onwards Google ensured that this philosophy is materialized. Philosophy of web-components is something we need to understand. We have so many frameworks and libraries available in the market but we hardly understand their intention and how that will benefit us in delivering the business case at hand. Let’s try to understand the philosophy of Angular.
Exuberant developers are always looking forward for new frameworks and libraries. In our excitement we always try to hammer the nail of business use case using a brand new hammer of the latest framework or library. We need to understand the philosophy behind the framework and library to effectively use it. Creating web-components via angular is a way to create reusable components.
Keeping the component philosophy in mind I would suggest these three approaches to effectively use Angular Framework:
1. Complex UI Management
2. Reusable Components in the same Application
3. A shared component library across teams in an Organization
Complex UI Management
Complex UI of the applications like Facebook and Gmail are perfect candidates for this. The DOM tree of these applications, if they were developed using basic HTML elements like div, span, etc., would be very cluttered, difficult to understand and manage. Facebook shows many posts and each post has many comments, likes, etc. Gmail has list of mails displayed and grouped by sections and on clicking an email we see the details. Creating angular components and replacing basic html tags with angular selectors will not only make the UI readable but also maintainable.
Reusable Components in the same Application
A typical case for this would be a web-ui which has same ui component being shown on multiple pages. An E-Commerce website having product card shown on the product search page. Similarly, if your business use case is having similar UI sections being shown on various pages then go for Angular. If all the views are having disparate sections which cannot be grouped then I would not recommend Angular framework for that since you end up creating components without any reusability in other views of your application. It’s like creating a mould and moulding a single statue using it.
A Shared Component Library Across Teams in an Organization
A product-based organization or even software development outsourcing companies which are catering to multiple clients, would always need faster time to market. In the current era of digital transformation, all of the companies want to deliver faster product to market. In those cases having off-the-shelf web-components, which are tested and configurable, is definitely going to give an edge to outsourcing companies. Product-based companies, which are looking for options to divide their product UI into small web components, can be enhanced in isolation and upgraded with newer features and functionalities, should go for Angular. It will make their product more like LEGO blocks. Once the components are ready all they have to do is assemble and sell.
Still, if you want to use Angular only because your business clients want it, then I would recommend the component philosophy while developing Angular code.
Divide the UI into small modules first, identify the components module they fit in, define the component boundaries, think how inter-component communication is going to happen, define the data model for the application UI and how that data model transformation would take place due to various events.
I would not recommend to use a framework, only because its new and popular, instead understand the problem statement which that framework solves and compare to the problem statement you are solving.
No matter how popular or branded a toothpaste is, cannot be used to heal a wound or a rash. Instead, a good antiseptic cream is what we should look for, and use toothpaste only to brush teeth.
