Simple architecture of Angular applications

Introduction to Atomic Design

Can you tell at a glance what is inside a shared module? And, without opening another file, tell which components have dependencies or bindings to other components? Whatever your answer, I suggest you make some tea or coffee and figure out the basics with me. atomic design theory invented by Brad Frost!

Defining Atomic Design in Angular Context

Directory structure for atomic design in Angular
Directory structure for atomic design in Angular

When describing components, Angular developers often use the concept “Container – presenter” (aka “smart component – stupid component”). In this way, you can easily and easily explain dependencies and describe how components interact with each other, without focusing on the specifics of the user interface implementation.

Anything from a button to a layout can act as a “dumb” component. Atomic design can be used to supplement the component definition with detailed information about the user interface structure and relationships.

Atoms and molecules are “stupid” components

They are simple in nature and easy to test pieces of code that can be reused. They receive data as input (@Input) and can output something (@Output). Hence, they are ideal for describing user interface libraries.

  • Atoms – the smallest modules, reusable throughout the project. They are usually a single HTML element with a basic styling.

  • Molecules – a separate group of atoms.

Organisms and Templates – Simple Representation of Smart Components

Templates help reduce the amount of common HTML by simplifying smart components, and organisms are the TypeScript counterpart.

Based on my experience in project management, I can say that organisms and patterns are rarely used in practice, although they are the key to scalability of applications and effective team work.

And the thing is that you realize their necessity when it’s too late. When designing a complex “smart” component, we initially consider it as a whole. We create a complete page by gradually adding small snippets of code. And then suddenly this “smart” component swells to five hundred lines of TypeScript and a thousand lines of HTML-CSS. In the resulting swamp, each subsequent step is more difficult than the previous one. Even if the logic is simple, the file is difficult to handle because of its size.

Patterns and organisms remove noise from the code, structure the code, and make it scalable. Thus, it becomes easier to find and reuse the required pieces of code while developing similar functionality.

Templates

Treat templates like scaffolds and skins components. Plain HTML-CSS with element ng-content

Templates are used in high-level components (such as pages or organisms) to reduce style variability and reduce the amount of typical HTML code. Such components should not have any input or output, logic, or constructor dependencies.

Let’s take a look at a simple example:

A template component that groups common wrapper code alongside styling and has no logic.
A template component that groups common wrapper code alongside styling and has no logic.

A page or smart component based on a template component.  It has no styles, but it drives the logic.
A page or smart component based on a template component. It has no styles, but it drives the logic.

This approach pays off not only for small pieces of code like cards in Angular Material, but also for full-width layouts. It is useful in situations where you cannot get by with a single layout component with an element router-outlet or when you need to break the code into chunks. Once you stabilize the original code, refactoring it to use templates is a simple copy / paste operation and only takes a few minutes.

Organisms

It is a relatively complex group of molecules that behave like one module. On Brad’s site the title of the page is given as an example of an organism.

In my opinion, this approach offers more functionality than the structural one. I think of organisms as widgets. Segregated sections of an application can be reused across different pages and wrap certain logic within them.

Are these “smart” or “dumb” components? There is no unambiguous rule in this regard. I prefer to collect all service dependencies and logic in a page / controller whenever possible. But when dealing with complex pages, sometimes it makes more sense to structure them like a layout and split the logic into multiple child component organisms that have their own dependencies.

Pages are smart components

In the general case, it is considered functional components within the classic project structure like core / features / shared (basic modules / functional components / common components). Smart components control I / O that interact with the underlying application modules through services.


Translation prepared as part of the course “JavaScript Developer. Professional”.

We invite everyone to an open lesson “Async Patterns in JavaScript”… In this lesson, we’ll walk you through asynchronous programming in JavaScript, callbacks in programming, map functions, reduce functions, and more. Join us!

Similar Posts

Leave a Reply