Forem: Mikhail Potapov

Optimizing Angular Applications: Removing NgRx DevTools in Production 🚀

Mikhail Potapov — Tue, 23 May 2023 04:49:03 +0000

When developing an Angular application with NgRx, the NgRx DevTools can be incredibly useful for debugging and monitoring state changes. However, when it comes to deploying your application to production, it's a good idea to remove the devtools from your bundle and avoid loading them unnecessarily. This article will guide you through the process of configuring target-specific file replacements to achieve this.

To begin, you'll need to create two files that handle the NgRx DevTools providers. Let's call them ngrx-devtools.development.ts and ngrx-devtools.ts.

In the ngrx-devtools.development.ts file, import the necessary functions from @ngrx/store-devtools and @angular/core. Then, define a constant named ngrxDevtools that provides the NgRx DevTools configuration.

Here's an example of what the ngrx-devtools.development.ts file may look like:

import { provideStoreDevtools } from "@ngrx/store-devtools";
import { isDevMode } from "@angular/core";

export const ngrxDevtools = provideStoreDevtools({
  maxAge: 25,
  logOnly: !isDevMode()
});

Next, in the ngrx-devtools.ts file, define a constant named ngrxDevtools as an array of EnvironmentProviders. This step ensures that when file replacement is applied in production, an empty array is used instead of the actual devtools configuration.

Here's an example of what the ngrx-devtools.ts file may look like:

import { EnvironmentProviders } from "@angular/core";

export const ngrxDevtools: EnvironmentProviders[] = [];

Now, you can provide the NgRx DevTools configuration in your application's bootstrap file, such as main.ts or app.module.ts. Import the ngrxDevtools constant from the ngrx-devtools.ts file.

Here's an example of how you can provide the NgRx DevTools configuration in your bootstrap file:

import { ngrxDevtools } from "./devtools/ngrx-devtools";

bootstrapApplication(AppComponent, {
  providers: [..., ngrxDevtools]
}).catch(err => console.error(err));

Additionally, don't forget to add the configuration to the angular.json file for file replacements.

"projects": {
  "app-name": {
    "architect": {
      "build": {
        "configurations": {
          "development": {
            "fileReplacements": [
              {
                "replace": "src/devtools/ngrx-devtools.ts",
                "with": "src/devtools/ngrx-devtools.development.ts"
              }
            ]
          }
        }
      }
    }
  }
}

During development, when you are in the development mode, the NgRx DevTools will be included and function as expected. However, when you switch to production mode, the file replacement configuration takes effect. The appropriate file is replaced, and the NgRx DevTools are not included in your production code, resulting in smaller bundle sizes and potentially saving a couple of kilobytes.

Remember to adjust the paths and file names according to your project structure. With this setup, you can enjoy the benefits of NgRx DevTools during development while keeping your production bundles streamlined and efficient.

🔥 Naming Interfaces in TypeScript: IUser vs User

Mikhail Potapov — Wed, 17 May 2023 17:14:42 +0000

In TypeScript, it is common for developers to prefix their interfaces with "I" (e.g., IUser) following the Hungarian notation. However, not all developers adhere to this convention.

I used to prefer using the "I" prefix for my interfaces as I believed it improved the reliability and clarity of my code. I also extended this convention to types, like TUser.

However, I encountered an issue when I needed to convert some interfaces into types, specifically when my interface became a union type of other interfaces. This necessitated replacing all the "I" prefixes with "T" throughout the codebase. These changes proved to be cumbersome, unnecessary. This issue has occurred multiple times for me and my colleagues, leading us to abandon the use of the "I" prefix.

I would like to know your thoughts on this matter. Do you also use prefixes for your interfaces?

ChatGPT, Copilot and Programmers: Collaboration or Substitution?

Mikhail Potapov — Tue, 16 May 2023 17:30:22 +0000

Generative neural networks such as ChatGPT can create text, code, and images based on given queries. ChatGPT, developed by OpenAI, has gained enormous popularity and attracted one million users in just 5 days. It stands out for its ability to understand context and engage in meaningful dialogues.

The success of ChatGPT led Microsoft to invest $10 billion in OpenAI, recognizing the future potential of generative neural networks. However, while these networks have proven their usefulness in writing code, they are not expected to completely replace programmers. Programmers still play a critical role in formulating tasks, testing code, and ensuring maintainability.

Programmers must create error-free and readable code because changes may be needed at any time. They must also understand the project's context, including existing code, business logic, code design standards, and interactions with other services and APIs. Training a neural network to fully understand these aspects requires a significant amount of time, specific context, and a lot of data.

Generative neural networks such as Copilot have the potential to change the programming profession. They force programmers to break down tasks into smaller components for which code can be generated by a neural network, and programmers are responsible for testing and combining those pieces of code. Copilot has already attracted more than a million programmers and improved their efficiency.

The introduction of Copilot and similar tools may raise concerns about job cuts in programming. However, history shows that increases in programmer efficiency caused by advances such as high-level programming languages have not led to massive job losses. The demand for code continues to grow, and there are still many unresolved problems that require human expertise.

While Copilot can be a useful tool for automating routine tasks in development, its use as a mandatory tool can also make it difficult to get started in the profession. Automating routine tasks reduces their volume, but more complex tasks require greater understanding and expertise.

In conclusion, the interaction between generative neural networks such as ChatGPT and Copilot and programmers is a collaboration, not a complete replacement. Programmers will continue to play a key role in development because they have the necessary contextual understanding of the project and can provide flexibility and development.

Solving the mystery: where are the promises in the Node.js event loop?

Mikhail Potapov — Tue, 16 May 2023 06:12:10 +0000

When I started learning Node.js and became familiar with the event loop, I asked myself the question: In what phase is the promise fulfilled? I could not find an explicit answer to this question in the documentation.

The event loop in Node.js consists of several phases, each responsible for handling different types of asynchronous operations. Promises, which are a fundamental part of asynchronous programming in JavaScript, are executed in the corresponding phase of the event loop.

The diagram below shows the phases of the event loop:

Timers: In this phase, callbacks to scheduled timers are executed. These timers can be created with functions like setTimeout() or setInterval().

Pending callbacks: This phase performs callbacks for system operations. It includes callbacks for I/O events, network operations, or other asynchronous tasks that have completed but are waiting to be processed.

Idle, prepare: These phases are used internally by Node.js (libuv in particular) and are not managed directly.

Poll: The polling phase is responsible for timing and processing I/O events. It waits for new I/O events and calls them back. If there are no pending I/O events, it may block and wait for new events to arrive.

Check: This phase handles callbacks scheduled with setImmediate(). It makes immediate callbacks immediately after the polling phase, regardless of whether the polling phase was active or blocked.

Close callbacks: In this phase, callbacks associated with "close" events are executed. For example, when a socket or file is closed, the corresponding close event callback is executed in this phase.

So, what about promises?

While the main phases were mentioned earlier, it is important to note that there are other tasks that occur between each of these phases. These tasks include process.nextTick() and the microtask queue (which is where promises appear).

Our schema now looks like this:

The microtask queue is processed as soon as the current phase of the event loop ends, before moving on to the next phase. This ensures that promise callbacks are completed as quickly as possible without waiting for the next iteration of the event loop.

If you, like me, have been looking for an answer to this question, I hope this article has given you the clarity you were looking for. Understanding when promises are executed in the Node.js event loop is essential to effective asynchronous programming. I hope this explanation was helpful to you, allowing you to use promises confidently in your Node.js applications.