DEV Community: Victor Tihomirov

Common mistakes that backend programmers make in Angular

Victor Tihomirov — Sun, 03 Sep 2023 16:29:05 +0000

Recently, I found myself in charge of upgrading our Angular application from version 12 to 15. In my current role, which I've held for just over a year, most of my focus has been on the backend, and I hadn't even touched the frontend apps until now. I've got to be honest; this upgrade process turned out to be a tougher nut to crack than I initially thought. It's not a knock on the Angular team's Angular Update Guide, though; they did a solid job. The real challenge came from the fact that we had a bunch of custom-made components that didn't quite follow the best practices playbook.

To provide a bit more context, our entire team primarily comprises .NET developers who possess some familiarity with HTML, CSS, and basic JavaScript. The rationale behind this choice stemmed from the belief that transitioning to Angular would be smoother for backend developers, possibly owing to the familiarity with the MVC (Model-View-Controller) pattern. At the time of this decision, Angular was also considered the go-to standard choice for frontend development.

Although I did manage to pull it off eventually, here's what tripped me up along the way and some insights into areas where improvements could be made. Here are the key points I'd like to highlight:

1. ESLint

While reviewing the codebase, I couldn't help but notice numerous inconsistencies and common mistakes that would have been easily caught by ESLint. After setting up and configuring it with recommended rules for Angular, TypeScript, and RxJS, I ran the linter. To my surprise, it uncovered over 5000 linting issues, with approximately 2000 of them being automatically fixable.

However, my primary goal wasn't to fix all these linting errors, as I couldn't guarantee that doing so wouldn't introduce unforeseen issues. Instead, I chose to install husky and set up linting and automatic fixing exclusively for committed files. In cases where automatic fixing wasn't feasible, I encouraged the developers to follow the "boy scout rule" and address the errors they encountered. As I delved into these improvements, I also took the opportunity to seamlessly integrate and configure prettier alongside ESLint. After all, who enjoys scrolling through diffs or pull requests with only formatting changes? It just makes the code review process smoother and more pleasant for everyone involved.

2. TypeScript

I found myself inspecting the codebase in sheer horror as I discovered that practically everything was marked as any. The most significant advantage of TypeScript seems to have been overlooked.

Picture writing C# code where everything is either an anonymous type or simply of type object – it's akin to a maintenance nightmare.

This is one of the factors that made me hesitate to automatically fix all the linting issues and approach the upgrade with caution.

3. Unit tests

This brings me to the second reason why I hesitated to automatically fix all the linting issues. There are numerous factors contributing to the absence of unit tests in our app, ranging from time constraints and knowledge gaps to a perceived low value, lack of a testing culture, and motivation. I won't delve too deep into each of these reasons, but I can say that the lack of unit tests significantly undermined my confidence in the app's stability following the upgrade. As it turned out, my concerns were justified, as various issues did arise and required subsequent fixes.

4. RxJS: observables and higher-order observables

I've noticed that our codebase includes a fair share of Promises, async/await, and RxJS usage. Let's establish one thing: RxJS not only covers all the functionality of Promises and async/await but does so with superior flexibility and maintainability. One of the standout features of RxJS is its inherent support for cancellation and resource cleanup. Promises and async/await don't provide these capabilities out of the box; you'd often need to resort to workarounds or third-party libraries to achieve similar functionality.

I've also come across a common mistake in the codebase where developers tend to nest subscriptions. This practice can introduce a lot of problems, including memory leaks, unpredictable behavior, challenges in error handling, code that becomes increasingly complex and hard to maintain, and a loss of control over the execution flow.

Adding to the mix, I also stumbled upon Promises and async/await nested within RxJS subscriptions. This not only heightened the complexity of the code but also made it significantly harder to understand and read. What's more, there's the looming threat of potential deadlocks because RxJS is tailored to function seamlessly with non-blocking, asynchronous operations, and introducing async/await or Promises into the mix can disrupt this delicate balance.

To steer clear of all these potential issues, I strongly recommend sticking to observables and higher-order observables as the primary means of chaining or flattening them.

5. Composition over inheritance

This one is probably my favorite. Angular favors composition over inheritance and it's easy to get caught up in the inheritance trap.

Let me illustrate this with an example. Imagine the business comes to me and says, "Hey, we need two forms for our new app." And I'm like, "Sure thing, here they are."

export class ContactComponent {
  errors: string[] = [];
  formData: FormGroup = new FormGroup()

  displayErrors() {}

  submitForm() {}
}

export class RegistrationComponent {
  errors: string[] = [];
  formData: FormGroup = new FormGroup();

  displayErrors() {}

  submitForm() {}
}

Later on, they throw in a request for a new login form. That's when I begin to notice some code repetition. So, I decide to follow the DRY principle and create a base class to handle all this shared functionality.

export class BaseFormComponent {
  errors: string[] = [];
  formData: FormGroup = new FormGroup();

  displayErrors() {}

  submitForm() {}
}

export class ContactComponent extends BaseFormComponent {}
export class RegistrationComponent extends BaseFormComponent {}
export class LoginComponent extends BaseFormComponent {}

Everything seems to be shaping up nicely. I've gone ahead and refactored the code, successfully eliminating those pesky code duplications.

Now, here comes the business again, this time requesting a rating widget to be added. "No worries," I think, "I've got this covered."

export class RatingComponent extends BaseFormComponent {}

Somewhere in the back of my mind, I can't help but think that the rating form doesn't need any validations. But hey, for the sake of consistency, I'll stick to using that trusty base class. Who knows, even if it doesn't need those features right now, it might come in handy down the road, right? Better safe than sorry.

And then, the business strikes once more, this time requesting a new email notification feature. They want users to receive a thank-you email after every contact, registration, or rating submission.

This seems like a straightforward task. I'll just inject an SMTPClient into the base class, and then I can easily share the email notification logic with all its subclasses.

export class BaseFormComponent {
  errors: string[] = [];
  formData: FormGroup = new FormGroup();

  constructor(private smtpClient: SMTPClient) {}

  displayErrors() {}

  submitForm() {}
}

export class ContactComponent extends BaseFormComponent {
  constructor(private smtpClient: SMTPClient) {
    super(smtpClient);
  }
}
export class RegistrationComponent extends BaseFormComponent {
  constructor(private smtpClient: SMTPClient) {
    super(smtpClient);
  }
}
export class LoginComponent extends BaseFormComponent {
  constructor(private smtpClient: SMTPClient) {
    super(smtpClient);
  }
}

export class RatingComponent extends BaseFormComponent {
  constructor(private smtpClient: SMTPClient) {
    super(smtpClient);
  }
}

After going through my changes, something just doesn't sit right. Why on earth should my LoginComponent have to deal with injecting the SMTPClient? This is a significant code smell, no doubt about it.

In a nutshell, here's what I've managed to accomplish so far:

Created code that's less flexible and harder to maintain.
Introduced tight coupling between components.
Achieved a delightful level of code duplication.
Made writing tests feel like an Olympic event.
And let's not forget the introduction of the notorious fragile base class problem.

Quite the list, isn't it? 😅

Sadly, this is precisely the situation I'm grappling with in the codebase I'm currently working on.

To address these issues effectively, we need to shift our focus to composition instead. Remember the is-a vs has-a?

A RatingComponent has an SMTPClientService
A LoginComponent has a ValidationEngineService
A RegistrationComponent has a ValidationEngineService and an SMTPClientService

By using services in this manner, we can craft reusable code that's not only easier to maintain but also decoupled. Plus, writing unit tests becomes a breeze. This approach offers a fresh perspective and a cleaner path forward.

That's a wrap for my rant. Time to go brew some coffee. If any of you have questions or want more examples, feel free to ask in the comments – I'm here to help and answer them all! ☕😊

If you liked my article and would like to buy me a coffee, you can do it here.

A simple Angular folder structure that makes development feel natural and easy.

Victor Tihomirov — Sat, 11 Mar 2023 20:06:49 +0000

After years of working on multiple Angular projects, I have had firsthand experience with the difficulties of poorly thought out designs. Projects that were supposed to be scalable were unscalable, had unreadable code, and did not adhere to the Angular coding style guide. Luckily, the coding style guide already gives us a place to start when it comes to project structure, with a shared module and a module for each feature.

In this guide, I will go over the feature-based approach in greater detail and explain the whys and hows.

First of all, why is a well-designed folder structure important?

It allows us to be more flexible with our application. We can add new functionality without breaking anything.
A well-designed system is simple to understand and navigate.
It improves testing, maintainability, and reusability.

I like to split the project into six main folders, each with its own responsibility: core, features, shared, apis, types, and store.

Core folder

The CoreModule is located in the core folder and contains essential services, components, and other functionality that are required by many parts of the application, either once (components) or as a singleton (services). Here are some examples of such components and services:

Components (header, footer, navbar, error, etc.)
Logging service
Exception handling service
Configuration service
Localization service
Auth service
Http interceptors
Guards

By encapsulating this functionality into a single module, we gain a centralized location for managing dependencies and configuring the application at a high level.

The CoreModule is typically imported once in the application's root module. Its components and services are made available to other modules via dependency injection.

To avoid accidentally importing the CoreModule more than once, include the following code in the constructor:

constructor(@Optional() @SkipSelf() parentModule: CoreModule) {
    if (parentModule) {
      throw new Error(`CoreModule has already been loaded. Import it in the AppModule only.`);
  }
}

This is how the core folder might look.:

|-- core
|   |-- components
|   |   |-- header
|   |   |   |-- header.component.ts
|   |   |   |-- header.component.html
|   |   |   |-- header.component.scss
|   |   |-- footer
|   |   |   |-- footer.component.ts
|   |   |   |-- footer.component.html
|   |   |   |-- footer.component.scss
|   |-- services
|   |   |-- auth.service.ts
|   |   |-- logging.service.ts
|   |   |-- exception.service.ts
|   |-- interceptors
|   |   |-- auth.interceptor.ts
|   |-- guards
|   |   |-- auth.guard.ts
|   |-- core.module.ts

Shared folder

The shared folder contains the SharedModule which typically contains reusable UI components used throughout the application, such as buttons, form fields, and input validation. It may also include directives and pipes that are used by numerous modules.

Developers can avoid code duplication across multiple modules by encapsulating these shared components in the 'SharedModule,' which would otherwise result in code bloat and maintenance issues. It also helps to enforce UI consistency because all modules will be using the same shared components.

Bonus: Create a ThirdPartyModule to differentiate between own components and vendor components such as NgbModule. This module should be imported into the SharedModule.

The shared folder might look like this:

|-- shared
|   |-- components
|   |   |-- spinner
|   |   |   |-- spinner.component.ts
|   |   |   |-- spinner.component.html
|   |   |   |-- spinner.component.scss
|   |   |-- modal
|   |   |   |-- modal.component.ts
|   |   |   |-- modal.component.html
|   |   |   |-- modal.component.scss
|   |-- directives
|   |   |-- highlight.directive.ts
|   |-- pipes
|   |   |-- capitalize.pipe.ts
|   |-- shared.module.ts
|   |-- third-party.module.ts

Features folder

This folder contains the features of the application. Each feature has its own module that contains a collection of components, services, directives, pipelines, and other code that encapsulates a specific aspect of the application's functionality.

I like to think of a feature as a slice of pie. You should be able to easily remove a slice of pie without making a mess. This means that our features should not be dependent on one another.

The features folder can look like this:

|-- features
|   |-- products
|   |   |-- components
|   |   |   |-- product-list
|   |   |   |   |-- product-list.component.ts
|   |   |   |   |-- product-list.component.html
|   |   |   |   |-- product-list.component.scss
|   |   |   |-- product-details
|   |   |   |   |-- product-details.component.ts
|   |   |   |   |-- product-details.component.html
|   |   |   |   |-- product-details.component.scss
|   |   |-- product-root.component.html
|   |   |-- product-root.component.ts
|   |   |-- product-routing.module.ts
|   |   |-- product.module.ts

Apis folder

The apis folder is used to store files related to consuming RESTful APIs or other web services. These files may include service classes, models or interfaces, and helper functions related to working with the APIs.

|-- apis
|   |-- product.service.ts

Types folder

The types folder is a location for storing type definitions that are used across the application.

|-- types
|   |-- user
|   |   |-- user.ts
|   |   |-- user-status.enum.ts
|   |-- product
|   |   |-- product.ts
|   |   |-- product-type.enum.ts

Store folder

If you're using NgRx for state management, the store folder is ideal for providing a centralized location for managing application state, which can help to simplify the codebase and make complex state interactions easier to manage.

|-- store
|   |-- user
|   |   |-- actions
|   |   |   |-- user.actions.ts
|   |   |-- reducers
|   |   |   |-- user.reducers.ts
|   |   |-- selectors
|   |   |   |-- user.selectors.ts
|   |-- product
|   |   |-- actions
|   |   |   |-- product.actions.ts
|   |   |-- reducers
|   |   |   |-- product.reducers.ts
|   |   |-- selectors
|   |   |   |-- product.selectors.ts
|   |-- store.module.ts

In conclusion, the Angular world and the best practices are evolving, and so do we. I will come back again in a year and revise what can be improved (hello, signals!).

Keep learning, stay curious, and never stop coding!

If you liked my article and would like to buy me a coffee, you can do it here.