MixRank

mixrank

50+ Useful Tools and Resources for Entrepreneurs to Ensure a Successful Product

Loading optimization is one of the most crucial topics in the Front-End field, and it’s no surprise—applications need to be fast to deliver a great user experience. One effective way to speed up loading times is by reducing the application size, and lazy-loading is a key technique to achieve this. Most developers are familiar with how lazy-loading works: it's commonly used in all modern Front-End frameworks to split applications by routes and load components only when needed. Another widely used method is dynamic imports. However, these techniques can be challenging to implement in certain scenarios. In this article, I’ll explore these scenarios and discuss how to address them in Angular 17. In my current application, there’s a significant amount of hidden content, such as tooltips and popups. While this isn’t a problem when the content is just text, it becomes a performance issue when it involves complex business features spread across the entire application. For instance, one of the tooltips is 320KB, filled with heavy components and services, all of which are required by the business. Additionally, these components are initialized multiple times in data tables—up to 100 times per table. The irony is that these components are often invisible until the user hovers over the tooltip, yet they still slow down the application. Most of the time, all we need to show is the text, not the hidden content. Before Angular 17, there wasn’t a convenient way to handle this, but now we have a powerful new tool: @defer. Let’s take a look at the code below: 
<span
    [pTooltip]="tooltipContent">
    <ng-content></ng-content>
</span>

<ng-template #tooltipContent>
    @defer {
      <some-heavy-component></some-heavy-component>
    }
</ng-template>


<info-popup>
  <span>I'm a label for the heavy tooltip</span>
</info-popup> In my current project, I use the PrimeNG library, which serves as the primary UI framework. PrimeNG is an excellent package with comprehensive documentation, making it a solid choice for building applications. In this solution, I use the [pTooltip] directive to create tooltips and pass references to templates. Additionally, I pass content externally, which is then rendered as the label for the tooltip.  Within the template, I utilize the @defer directive, which enables lazy-loading of components. Specifically, <some-heavy-component> is only loaded when the user hovers over the span element. This technique significantly reduces the initial loading size and improves overall performance by minimizing the load time. By deferring the loading of heavy components until they are actually needed, we can achieve a much more efficient and responsive application. I can't share the results just yet, as we're still in the implementation stage (we have enormous scenarios like this, and it will take some time to fully migrate to the new approach). We haven't run performance tests at this point, but it's important to remember that every project has its own unique stack and performance characteristics. What works well for us might yield different results in your specific context. However, I hope you found this article insightful and that it encourages you to explore and adopt the new features of Angular. While your outcomes may vary, these techniques have the potential to bring significant improvements to your project's performance. Loading optimization is one of the most crucial topics in the Front-End field, and it’s no surprise—applications need to be fast to deliver a great user experience. One effective way to speed up loading times is by reducing the application size, and lazy-loading is a key technique to achieve this. Most developers are familiar with how lazy-loading works: it's commonly used in all modern Front-End frameworks to split applications by routes and load components only when needed. Another widely used method is dynamic imports. However, these techniques can be challenging to implement in certain scenarios. In this article, I’ll explore these scenarios and discuss how to address them in Angular 17. In my current application, there’s a significant amount of hidden content, such as tooltips and popups. While this isn’t a problem when the content is just text, it becomes a performance issue when it involves complex business features spread across the entire application. For instance, one of the tooltips is 320KB, filled with heavy components and services, all of which are required by the business. Additionally, these components are initialized multiple times in data tables—up to 100 times per table. The irony is that these components are often invisible until the user hovers over the tooltip, yet they still slow down the application. Most of the time, all we need to show is the text, not the hidden content. Before Angular 17, there wasn’t a convenient way to handle this, but now we have a powerful new tool: @defer . Let’s take a look at the code below: @defer 
<span
    [pTooltip]="tooltipContent">
    <ng-content></ng-content>
</span>

<ng-template #tooltipContent>
    @defer {
      <some-heavy-component></some-heavy-component>
    }
</ng-template>


<info-popup>
  <span>I'm a label for the heavy tooltip</span>
</info-popup> 
<span
    [pTooltip]="tooltipContent">
    <ng-content></ng-content>
</span>

<ng-template #tooltipContent>
    @defer {
      <some-heavy-component></some-heavy-component>
    }
</ng-template>


<info-popup>
  <span>I'm a label for the heavy tooltip</span>
</info-popup> In my current project, I use the PrimeNG library, which serves as the primary UI framework. PrimeNG is an excellent package with comprehensive documentation, making it a solid choice for building applications. In this solution, I use the [pTooltip] directive to create tooltips and pass references to templates. Additionally, I pass content externally, which is then rendered as the label for the tooltip.  Within the template, I utilize the @defer directive, which enables lazy-loading of components. Specifically, <some-heavy-component> is only loaded when the user hovers over the span element. This technique significantly reduces the initial loading size and improves overall performance by minimizing the load time. By deferring the loading of heavy components until they are actually needed, we can achieve a much more efficient and responsive application. [pTooltip] @defer <some-heavy-component> span I can't share the results just yet, as we're still in the implementation stage (we have enormous scenarios like this, and it will take some time to fully migrate to the new approach). We haven't run performance tests at this point, but it's important to remember that every project has its own unique stack and performance characteristics. What works well for us might yield different results in your specific context. However, I hope you found this article insightful and that it encourages you to explore and adopt the new features of Angular. While your outcomes may vary, these techniques have the potential to bring significant improvements to your project's performance.

Implement Lazy Loaded Popups With @defer and PrimeNG

Micro frontends architecture is still a hot topic in the Front-End field. Many projects are adopting or have already adopted this approach. However, it is one of the most controversial topics, and you should carefully consider the pros and cons before implementing it. Today, I will share how I dealt with this challenge and solved it in my application. Understanding Your Goals The first thing to consider is the business needs of the project and how your architecture will fit in. You can't build whatever you want – your decisions should align with the business direction. Secondly, evaluate the benefits of this architecture for your specific project. Don't rely solely on observations from others or follow trends without a cost-benefit analysis. Determine if the advantages are worth the cost. Thirdly, address these common concerns before making the shift: What is my current architecture?
How is the application deployed, and how will it deploy in the new architecture?
Can a micro frontend application be integrated into other applications? What stack do they use?
What is the complexity of the application? Does it involve routing or state management?
How will communication between apps be handled?
Is your team technically ready for this shift? These are the minimal recommendations before you start development. Solving the Problem If you have answers to the above questions, you're ready to proceed with the technical implementation for Angular apps. Historically, Angular apps are built using Webpack. This is not a significant issue until you face the micro frontend topic. Different bundlers can have runtime compatibility issues. For example, integrating an Angular app into a React app built with Vite and esbuild can be problematic. It makes more sense to follow web standards (ES Modules) rather than locking your projects to a specific bundler like Module Federation and Webpack. Fortunately, since Angular 16, the Angular team has included esbuild out of the box. I recommend updating beyond version 16. Now, it's enough to update your angular.json file with the new builder and other fields: {
  "build": {
    "executor": "@angular-devkit/build-angular:browser-esbuild",
    "options": {
      "stylePreprocessorOptions": {
        "includePaths": [""]
      },
      "outputPath": "dist",
      "index": "src/index.html",
      "main": "src/main.ts",
      "polyfills": ["zone.js"],
      "tsConfig": "./tsconfig.app.json",
      "inlineStyleLanguage": "scss",
      "assets": ["src/favicon.ico", "src/assets"]
    },
    "configurations": {
      "production": {
        "budgets": [
          {
            "type": "initial",
            "maximumWarning": "1mb",
            "maximumError": "2mb"
          },
          {
            "type": "anyComponentStyle",
            "maximumWarning": "1mb",
            "maximumError": "2mb"
          }
        ],
        "outputHashing": "none",
        "baseHref": "/"
      },
      "development": {
        "optimization": false,
        "extractLicenses":false,
        "sourceMap": true
      }
    },
    "defaultConfiguration": "production"
  }
} It's a good practice to integrate the micro frontend with minimal effort. For example, you can expose a component that accepts the remote app name and link. This makes it easier for consumers, as they don't need to worry about the underlying processes. Consider the following example: import { Component, Input, OnInit } from '@angular/core';

const MFE_CACHE_KEY = '__mfe-cache';

@Component({
    selector: 'mfe-wrapper',
    template: '<div id="mfe-root"></div>'
})
export class MfeWrapperComponent implements OnInit {
    @Input() public url: string;
    @Input() public appName: string;

    public ngOnInit(): void {
        const importFn = async (path: string): Promise<string> => {
            if (window[MFE_CACHE_KEY]?.[path]) {
                return window[MFE_CACHE_KEY][path];
            } else {
                const response = await fetch(path);
                const scriptContent = await response.text();
                window[MFE_CACHE_KEY] = { ...window[MFE_CACHE_KEY], [path]: scriptContent };
                return scriptContent;
            }
        };
        const element = document.getElementById('mfe-root');

        const executeScript = (scriptContent: string): void => {
            const scriptElement = document.createElement('script');
            scriptElement.type = 'module';
            scriptElement.async = true;
            scriptElement.textContent = scriptContent;
            element.appendChild(scriptElement);
        };

        element.appendChild(document.createElement(this.appName));

        (async (): Promise<void> => {
            const mainScript = await importFn(`${this.url}/main.js`);
            executeScript(mainScript);
            const polyfillsScript = await importFn(`${this.url}/polyfills.js`);
            executeScript(polyfillsScript);
        })();
    }
} In this example, we download the necessary scripts (main.js and polyfills.js) from the provided source. You must deploy your Angular build to the URL that you expose to the consumers. We convert the script into text and insert it into the script tag to avoid caching issues. You can extract the logic of downloading and script creation into separate scripts and reuse it for a React component wrapper for React app integrations – the approach remains the same. One important note is dealing with styles. You may notice that angular.json doesn't have a styles field. This is intentional. If you leave this field, the builder creates a style.css file, which can override the host application’s styles. By removing this field, the styles are added to the main.js file. Additionally, you can wrap the app in ShadowDOM to ensure that your styles don't override the host styles. If you use UI libraries and components without styles encapsulation, these approaches won't help – the styles will leak into the host application’s head. Carefully choose the components you use. Advantages: Your Angular application can be integrated into any other application regardless of the framework. Easy integration with the host by providing a component with only two inputs – URL and app name (you can omit the name if the URL has only one application). In most cases, your application’s styles are encapsulated and don't override the host’s styles. Disadvantages: This approach is compatible with Angular 16 and above. Version upgrades can be challenging. Path resolution issues. If the host and remote app are on different domains, import paths will resolve within the host domain. You can either remap all your imports after the build (use this only if necessary) or host the remote app on the same domain (or use emulation). The styles encapsulation problem is not fully solved. Conclusion Adopting a micro frontend architecture requires careful planning and consideration of both business and technical factors. The approach described here provides a way to integrate Angular applications into various host environments with minimal effort. While it offers significant advantages, such as framework-agnostic integration and style encapsulation, there are also challenges to address, including compatibility with older Angular versions and path resolution issues. By understanding these trade-offs and planning accordingly, you can effectively implement a micro frontend architecture that meets your project’s needs. Micro frontends architecture is still a hot topic in the Front-End field. Many projects are adopting or have already adopted this approach. However, it is one of the most controversial topics, and you should carefully consider the pros and cons before implementing it. Today, I will share how I dealt with this challenge and solved it in my application. Understanding Your Goals The first thing to consider is the business needs of the project and how your architecture will fit in. You can't build whatever you want – your decisions should align with the business direction. Secondly, evaluate the benefits of this architecture for your specific project. Don't rely solely on observations from others or follow trends without a cost-benefit analysis. Determine if the advantages are worth the cost. Thirdly, address these common concerns before making the shift: What is my current architecture? How is the application deployed, and how will it deploy in the new architecture? Can a micro frontend application be integrated into other applications? What stack do they use? What is the complexity of the application? Does it involve routing or state management? How will communication between apps be handled? Is your team technically ready for this shift? What is my current architecture? How is the application deployed, and how will it deploy in the new architecture? Can a micro frontend application be integrated into other applications? What stack do they use? What is the complexity of the application? Does it involve routing or state management? How will communication between apps be handled? Is your team technically ready for this shift? These are the minimal recommendations before you start development. Solving the Problem If you have answers to the above questions, you're ready to proceed with the technical implementation for Angular apps. Historically, Angular apps are built using Webpack. This is not a significant issue until you face the micro frontend topic. Different bundlers can have runtime compatibility issues. For example, integrating an Angular app into a React app built with Vite and esbuild can be problematic. It makes more sense to follow web standards (ES Modules) rather than locking your projects to a specific bundler like Module Federation and Webpack. Fortunately, since Angular 16, the Angular team has included esbuild out of the box. I recommend updating beyond version 16. Now, it's enough to update your angular.json file with the new builder and other fields: {
  "build": {
    "executor": "@angular-devkit/build-angular:browser-esbuild",
    "options": {
      "stylePreprocessorOptions": {
        "includePaths": [""]
      },
      "outputPath": "dist",
      "index": "src/index.html",
      "main": "src/main.ts",
      "polyfills": ["zone.js"],
      "tsConfig": "./tsconfig.app.json",
      "inlineStyleLanguage": "scss",
      "assets": ["src/favicon.ico", "src/assets"]
    },
    "configurations": {
      "production": {
        "budgets": [
          {
            "type": "initial",
            "maximumWarning": "1mb",
            "maximumError": "2mb"
          },
          {
            "type": "anyComponentStyle",
            "maximumWarning": "1mb",
            "maximumError": "2mb"
          }
        ],
        "outputHashing": "none",
        "baseHref": "/"
      },
      "development": {
        "optimization": false,
        "extractLicenses":false,
        "sourceMap": true
      }
    },
    "defaultConfiguration": "production"
  }
} {
  "build": {
    "executor": "@angular-devkit/build-angular:browser-esbuild",
    "options": {
      "stylePreprocessorOptions": {
        "includePaths": [""]
      },
      "outputPath": "dist",
      "index": "src/index.html",
      "main": "src/main.ts",
      "polyfills": ["zone.js"],
      "tsConfig": "./tsconfig.app.json",
      "inlineStyleLanguage": "scss",
      "assets": ["src/favicon.ico", "src/assets"]
    },
    "configurations": {
      "production": {
        "budgets": [
          {
            "type": "initial",
            "maximumWarning": "1mb",
            "maximumError": "2mb"
          },
          {
            "type": "anyComponentStyle",
            "maximumWarning": "1mb",
            "maximumError": "2mb"
          }
        ],
        "outputHashing": "none",
        "baseHref": "/"
      },
      "development": {
        "optimization": false,
        "extractLicenses":false,
        "sourceMap": true
      }
    },
    "defaultConfiguration": "production"
  }
} It's a good practice to integrate the micro frontend with minimal effort. For example, you can expose a component that accepts the remote app name and link. This makes it easier for consumers, as they don't need to worry about the underlying processes. Consider the following example: import { Component, Input, OnInit } from '@angular/core';

const MFE_CACHE_KEY = '__mfe-cache';

@Component({
    selector: 'mfe-wrapper',
    template: '<div id="mfe-root"></div>'
})
export class MfeWrapperComponent implements OnInit {
    @Input() public url: string;
    @Input() public appName: string;

    public ngOnInit(): void {
        const importFn = async (path: string): Promise<string> => {
            if (window[MFE_CACHE_KEY]?.[path]) {
                return window[MFE_CACHE_KEY][path];
            } else {
                const response = await fetch(path);
                const scriptContent = await response.text();
                window[MFE_CACHE_KEY] = { ...window[MFE_CACHE_KEY], [path]: scriptContent };
                return scriptContent;
            }
        };
        const element = document.getElementById('mfe-root');

        const executeScript = (scriptContent: string): void => {
            const scriptElement = document.createElement('script');
            scriptElement.type = 'module';
            scriptElement.async = true;
            scriptElement.textContent = scriptContent;
            element.appendChild(scriptElement);
        };

        element.appendChild(document.createElement(this.appName));

        (async (): Promise<void> => {
            const mainScript = await importFn(`${this.url}/main.js`);
            executeScript(mainScript);
            const polyfillsScript = await importFn(`${this.url}/polyfills.js`);
            executeScript(polyfillsScript);
        })();
    }
} import { Component, Input, OnInit } from '@angular/core';

const MFE_CACHE_KEY = '__mfe-cache';

@Component({
    selector: 'mfe-wrapper',
    template: '<div id="mfe-root"></div>'
})
export class MfeWrapperComponent implements OnInit {
    @Input() public url: string;
    @Input() public appName: string;

    public ngOnInit(): void {
        const importFn = async (path: string): Promise<string> => {
            if (window[MFE_CACHE_KEY]?.[path]) {
                return window[MFE_CACHE_KEY][path];
            } else {
                const response = await fetch(path);
                const scriptContent = await response.text();
                window[MFE_CACHE_KEY] = { ...window[MFE_CACHE_KEY], [path]: scriptContent };
                return scriptContent;
            }
        };
        const element = document.getElementById('mfe-root');

        const executeScript = (scriptContent: string): void => {
            const scriptElement = document.createElement('script');
            scriptElement.type = 'module';
            scriptElement.async = true;
            scriptElement.textContent = scriptContent;
            element.appendChild(scriptElement);
        };

        element.appendChild(document.createElement(this.appName));

        (async (): Promise<void> => {
            const mainScript = await importFn(`${this.url}/main.js`);
            executeScript(mainScript);
            const polyfillsScript = await importFn(`${this.url}/polyfills.js`);
            executeScript(polyfillsScript);
        })();
    }
} In this example, we download the necessary scripts ( main.js and polyfills.js ) from the provided source. You must deploy your Angular build to the URL that you expose to the consumers. We convert the script into text and insert it into the script tag to avoid caching issues. You can extract the logic of downloading and script creation into separate scripts and reuse it for a React component wrapper for React app integrations – the approach remains the same. main.js polyfills.js One important note is dealing with styles. You may notice that angular.json doesn't have a styles field. This is intentional. If you leave this field, the builder creates a style.css file, which can override the host application’s styles. By removing this field, the styles are added to the main.js file. Additionally, you can wrap the app in ShadowDOM to ensure that your styles don't override the host styles. angular.json styles style.css main.js ShadowDOM If you use UI libraries and components without styles encapsulation, these approaches won't help – the styles will leak into the host application’s head. Carefully choose the components you use. If you use UI libraries and components without styles encapsulation, these approaches won't help – the styles will leak into the host application’s head. Carefully choose the components you use. Advantages: Advantages: Your Angular application can be integrated into any other application regardless of the framework. Your Angular application can be integrated into any other application regardless of the framework. Easy integration with the host by providing a component with only two inputs – URL and app name (you can omit the name if the URL has only one application). Easy integration with the host by providing a component with only two inputs – URL and app name (you can omit the name if the URL has only one application). In most cases, your application’s styles are encapsulated and don't override the host’s styles. In most cases, your application’s styles are encapsulated and don't override the host’s styles. Disadvantages: Disadvantages: This approach is compatible with Angular 16 and above. Version upgrades can be challenging. This approach is compatible with Angular 16 and above. Version upgrades can be challenging. Path resolution issues. If the host and remote app are on different domains, import paths will resolve within the host domain. You can either remap all your imports after the build (use this only if necessary) or host the remote app on the same domain (or use emulation). Path resolution issues. If the host and remote app are on different domains, import paths will resolve within the host domain. You can either remap all your imports after the build (use this only if necessary) or host the remote app on the same domain (or use emulation). The styles encapsulation problem is not fully solved. The styles encapsulation problem is not fully solved. Conclusion Adopting a micro frontend architecture requires careful planning and consideration of both business and technical factors. The approach described here provides a way to integrate Angular applications into various host environments with minimal effort. While it offers significant advantages, such as framework-agnostic integration and style encapsulation, there are also challenges to address, including compatibility with older Angular versions and path resolution issues. By understanding these trade-offs and planning accordingly, you can effectively implement a micro frontend architecture that meets your project’s needs.

One More Way to Build and Expose Your Angular Application as a Micro Frontend

RxJS for Beginners:  Mastering Observables, Subjects, and Operators for Reactive Programming

How to Publish Your First Angular Library Into a Package Registry

My journey on the current project started in October 2022 and this one is quite challenging. One of these challenges was the performance optimization area. Today, I would like to shine some light on this topic and share my experience. We will start from the basic concepts, look into the Web Vitals and core metrics for measuring the page loading, briefly walk through the topic of how a browser makes pixels on the screen from your code, and talk about optimization techniques. Importance of Application Loading Speed in User Experience First things first - let's explore the reasons why we should care about loading optimization: Improved load time enhances the user experience, keeps them engaged, and makes them less prone to shifting to another site. There are a lot of similar applications, and if you want to engage a user in your application, you have to have a fast-loaded application; Sites with faster loading times have higher conversion rates, impacting sales and registrations in e-commerce and other online businesses. Some companies researched how loading speed impacts sales for a business, and the results were quite impressive. Even a one-second delay can result in a 7% reduction in conversions, and 40% of users will abandon a website if it takes more than three seconds to load; Search engines like Google consider page load speed as a ranking factor in their algorithms, affecting the site visibility in search engine results. You have to be fast if you want to be at the top of Google search. This is one of the many factors impacting the website rank. Basic Concepts Overview of Web Vitals The first thing to discuss is Web Vitals. It's a pack of three metrics that the Google team formed. They are considered to be the most important metrics and vectors for improvement in the performance landscape. These metric values are fair only for the 75th percentile of users. It means that most of your users meet these metrics. The first one - the Largest Contentful Paint. In our topic, it is the most important one, and we will explore it in detail a little bit later. The Interaction to Next Paint is a metric showing how fast your page responds to a user's actions - click with the mouse, tap on the touchscreen, press a key on a keyboard or onscreen keyboard. This is the time when the browser begins processing event handlers in response to that action. And last but not least is the Cumulative Layout Shift. This metric shows how is unstable your UI - how many element shifts you have. The values are calculated with a special formula, but we are not going to reveal it. Understanding Largest Contentful Paint (LCP) and why it matters Okay, let's dive into the LCP metric and why it matters. It reports the render time of the largest image or text block visible in the viewport, relative to when the user first navigated to the page. To provide a good user experience, sites should strive to have the LCP of or less. LCP includes any unload time from the previous page, connection setup time, redirect time, and Time To First Byte, which can all be significant when measured in the field and can lead to differences between field and lab measurements. Let's see some examples of LCP calculation. You can see the loading page, and most of the time the LCP element is considered a big text block. However, after the image loading, the LCP element changed to the image. 2.5 seconds The second example is pretty much the same - while the future LCP elements are loading, some other text blocks are considered the largest on the page. In these examples, there are two similar situations - the LCP element loaded faster than other elements. Quick Look into the Critical Rendering Path (CRP) The Critical Rendering Path, or CRP, is the sequence of steps the browser goes through to convert the code of a web page into actual pixels on the screen. Understanding the CRP is essential for improving a page's load speed and overall performance. So, let's break it down further: When a user opens a web page, the browser starts by fetching the HTML content; The HTML is then parsed into a tree-like structure called the Document Object Model (DOM). This represents the structure of the webpage; Parallel to this, the browser fetches and parses style information, which includes CSS linked within the HTML, building the CSS Object Model (CSSOM) - which is a map of the site's visual rules; Once both DOM and CSSOM are built, the browser combines them into a Render Tree. This structure only includes visible elements and their styles; Based on the Render Tree, the browser then performs the Layout process, also known as reflow, calculating where each element should appear on the screen; The final step is the Painting, where the browser turns each node in the Render Tree into actual on-screen pixels; Any slowdown or blockage in these steps can delay the rendering of the page, causing a poor user experience. That's why it's crucial to optimize the CRP; Strategies & Techniques Now, we will look into the strategies and techniques, that can help us optimize our application. These are not all techniques in the world - just a part of them. Discussion of different caching methods We are starting from the cache. So, what exactly is caching? Think of caching as a high-speed memory storing temporary data that you're likely to need again. By storing this information in a cache - it drastically reduces the need to re-fetch the data from its source or reprocess a computation, hence saving precious time. There are several types of caching: . This stores static files, like CSS, JavaScript, and images, right in the user's browser; Browser Caching . This involves serving pre-generated responses to identical API requests straight from the cache rather than executing database queries each time; Server-Side Caching . This involves temporarily storing the results of a database query so that if identical queries are made, the result can be quickly retrieved from the cache rather than executing the query all over again; Database Caching How do we implement caching? We begin by identifying which assets or computations are costly and don't change frequently, making them ideal candidates for caching. Then, we choose the caching technique best suited based on our findings. Using CDN for faster content delivery Let's switch gears for a moment and discuss another effective strategy for speeding up web application performance - the use of a Content Delivery Network, commonly known as a CDN. So, what exactly is a CDN? At its simplest, a CDN is a network of servers spread out geographically, designed to deliver web content to users more quickly and efficiently. The content that a CDN caches usually includes images, stylesheets, JavaScript files, and more. So you might ask, how does a CDN actually work? The principle behind it is quite straightforward: the CDN will deliver the content from the server closest to the end user, significantly reducing the response time. Imagine you have users accessing your application from different parts of the world, and your server is somewhere in the US, and your application is accessible from any part of the world. Without a CDN, every request has to travel all the way to the US. But with a CDN, if a user is accessing from Spain, their request will be served by a server closest to Spain, drastically reducing the latency. Explaining asynchronous loading Normally, when a browser processes a webpage, it goes line by line, executing each function or loading every resource as it comes across them. This method is what we refer to as 'synchronous' because everything is happening in a specified order, one after the other. Asynchronous, on the other hand, fundamentally breaks this chain. It allows the browser to continue processing other elements of your webpage while it has kicked off resource-intensive operations, like fetching data from an API or loading images. Remember CRP? Actually, JavaScript is a render-blocking resource as a CSS, and this is why it's important to load JavaScript asynchronously. Here we have several examples of how can you connect our scripts to the webpage. As a default behavior, our script interrupts the HTML parsing, hence the DOM construction. And if you remember the CRP process, the DOM construction must be completed if we want to get actual on-screen pixels - we need to do it as fast as we can to provide a good user experience. A browser meets the script and starts to load it, and right after it has been loaded - executes. So, for this problem, we have two solutions - and attributes. As you can see, the script with both attributes loads asynchronously, but there is a pitfall - we still interrupt our HTML parsing with script execution, so for this purpose, it’s better to use because the script will be executed only after the HTML parsing is finished. async defer async defer Image and Video Optimal Formatting and Loading Moving on to another essential aspect of web performance - the optimal formatting and loading of images and videos. Multimedia content like images and videos can significantly impact the loading speed of your application due to its usually large file size. Therefore, optimizing these elements is crucial to enhance speed and performance. For images, we need to consider the most suitable format for a particular case. It can be JPEG, PNG, or SVG. For any media file, use compression tools to reduce file sizes without losing too much quality, or use files with less size. Do not forget to use lazy loading - it helps to not load files until they appear on the user's viewport. Importance of Minifying CSS, JavaScript, and HTML Minification is a simple and effective method to increase your web application performance without affecting its functionality and it must be included as a part of an application build process. Minification refers to the process of removing unnecessary or redundant data from your code files without affecting their functionality. This can include white spaces, line breaks, comments, and even variable names in some cases. So, why is minification so important? The primary benefit of minification is decreasing your file sizes. Smaller files mean less data needs to be transferred over the network, leading to quicker load times and less data usage for the end user. If your files are small, the browser can parse and compile them more quickly, improving the overall performance. In addition to this, it helps to reduce network bandwidth usage. Bundle reduction and dependencies management An important factor impacting the performance of your web application is the size of your JavaScript bundles. Your final bundle consists of your code and application dependencies/packages. And if you do not manage them properly, in the future, it becomes a big problem. This is an important part of the optimization of loading time. Here we have some techniques, which can help to reduce a bundle and helps to manage application dependencies: . Here, you divide your code into smaller chunks which are then loaded on demand or in parallel. By only loading the minimum necessary code for a particular page, you can drastically speed up the initial load time. This technique is also called lazy loading; Code Splitting . This technique helps you eliminate dead or unused codes from the final bundle. Modern bundlers offer built-in support for tree shaking. However, it mainly works with ES6 module syntax — so make sure you’re using and , not ; Tree shaking import export require . Try to only import the functions or components you need, rather than the entire library; Only import what you need . Updates often include optimizations and the removal of unnecessary or deprecated features; Regularly update dependencies . Use tools such as Webpack Bundle Analyzer to determine which dependencies are adding significant weight to your bundles, and consider whether they are truly necessary; Audit your dependencies . Use lighter alternatives of the libraries you use. For example, Preact is a lighter alternative to React, and day.js is a compressed version of moment.js, which is much bigger. For smaller projects or individual components, this approach can significantly reduce bundle size; Use lighter alternatives Make sure that there are no duplicate dependencies in your bundle. My personal experience and results Now, after all of the theory, I will present my personal experience in this field. For example, we will take a look at a project where I'm currently working on. When I entered the project, it was about October 2022, the LCP was at the 75th percentile. As we discussed earlier, it's not so good. Then, our management team set a goal to be in the green zone for LCP - it's up to 2.5 seconds. I took this task and started analyzing what was going on. The first thing that I revealed was the enormous size of a bundle - . The reason was simple - there was no code splitting and lazy loading, it was just one big JS file with all project code. Only our project code was 6 MB and 2 MB for dependencies. After the optimizations, it was really hard, I reduced the initial script to . What did we do with dependencies? We migrated some packages to more lightweight ones, some of them were deleted, and another part was removed from the initial script due to code splitting and tree shaking. So, it was reduced to . Plus to this, we cached all static resources for several weeks, due to our releases and enhanced our geographical distribution. And one more thing, we did some code optimizations to reduce long tasks that block our main thread. Finally, after a long way, we got LCP for the 75th percentile of users. 3.3 seconds almost 8 MB 300 KB 1.1 MB 1.9-second Possible questions you might ask Q: If I have a small project, that has already started, how much effort should I put into the possible optimizations bailouts in the future? A: Even for small projects, it's beneficial to set a good foundation for possible optimizations in the future. However, the level of effort would depend on your project's complexity, business domain, and future growth projections. If there's potential for your project to scale or complex features to be added, it's better to consider optimization early on. Conversely, if the project is expected to remain small and simple, you might choose to apply basic optimization practices without heavily investing time upfront. Q: How to sell the idea of optimization to a business? A: You can emphasize the direct benefits to the business. For instance, website optimization can lead to faster loading times, which can enhance user satisfaction and experience, reduce bounce rates, and potentially increase conversions and business profits. Furthermore, it's beneficial to the business's SEO efforts as search engines factor in page load speed in their ranking algorithms. In addition to this, it's better to provide measurable results rather than hypothetical ones. Q: How small my bundles should be to achieve code splitting benefits? A: There isn't a one-size-fits-all answer to this as it can depend largely on your application's needs and structure. However, a general rule of thumb provided by the Webpack documentation suggests aiming for an initial bundle split point of under 244KB (compressed). But remember, the ultimate goal is to only load what's required at any given time, improving the initial page load. Q: Which else tools can be helpful for analyzing my current statement? A: I have mentioned two of them: Webpuck Bundle Analyzer and Lighthouse. But it's good to know that Chrome DevTools can also be useful. For a performance tab that gives you more insight into what's happening when your site loads. But use it only for investigations, not for the source of truth - real data should be collected from real users. Conclusions Today we have discussed a little part of the big picture of optimizations. We have seen some important metrics and ways to enhance the user experience and loading application. In conclusion to my speech, I would like to give some advice or some kind of a roadmap if you want to improve the loading speed of your application: . The Lighthouse extension and Webpuck bundler analyzer can help you; Analyze your project . We discussed some of them but the world of optimizations does not only consist of them; Apply the most suitable techniques for your case . Store the core metrics for your project and regularly check them. It's very important to collect them from real users rather than local testing. Continuously measuring Remember, optimizing application load speed is an ongoing process and requires continuous monitoring.

How to Optimize the Loading of Your Web Application

Every application is built from the same type of components - buttons, inputs, dropdowns, etc., and modal windows are in this list. The reason is simple - modal windows allow us to communicate with a user and do not overwhelm a UI with additional information until it becomes needed. In this article, I will explore one of the approaches to managing modal windows in apps. Angular We use the primeng library for modals in the article's examples. Your case can be different. The general idea will be the same despite the libraries, but API can be different; be aware of it. Modal windows are just regular components - they have markup, style, and selector. But in contrast to regular components, they usually don't have to be shown on the page immediately. We need them only for the result of users' actions - confirm, discard, fill a form, etc. That's why we won't include them in our build - we will download them dynamically only if we require them. Let's see an example: public openModal(): void {
    const modalComponent = async (): Promise<any> => import('./path-to-your-modal');
    this.modalService.open(modalComponent());
} Here, we have the dynamic import approach. It means that our component will be loaded when we invoke the method. It's quite useful because we don't load the modal immediately in our chunk - only when the user needs it. This approach can help you to slightly reduce the bundle size, especially if your modals are full of logic and components. openModal In general, this is the working solution. But we can go further. Let's make a service that will handle the dynamic imports and return an instance of the modal: import { Injectable } from '@angular/core';
import { DialogService } from 'primeng/dynamicdialog';

@Injectable({ providedIn: 'root' })
export class CustomModalService {
    public modalWindowComponents: { [key: string]: () => Promise<any> } = {
        ConfirmModalComponent: () =>
            import('your-path/to-component').then((component) => component.ConfirmModalComponent),
    };

constructor(private modalService: DialogService) {}

    public async openDynamicDialogModal({
        componentName,
        data,
    }: {
        componentName: string;
        data?: { [key: string]: any };
    }): Promise<any> {
        const modalComponent = this.modalService.open(await this.modalWindowComponents[componentName](), { ...data });

        modalComponent.onClose.subscribe(() => {
            // some logic
        });
        return modalComponent;
    }
} Here, we can see several important things: We use an object to store modal windows imports where the key is the component name, and the value is an import function that returns Promise; Our method is taking the params object with the component's name (to take the import function from the object) and some additional data, which contains whatever you want for a component or its appearing configuration. Also, we have a subscription for close events. It is more convenient to handle window closing in one place; We return a Promise with the imported component. It allows us to handle the logic for each modal. Here is an example of the usage of this service: public async handleOpeningModalWindow(): Promise<void> {
    const dialogRef = await this.primengModalService.openDynamicDialogModal({
        componentName: 'DeleteStreamModalComponent',
        data: {
           // your params
        },
    });

    dialogRef.onClose
        .pipe(
            // your pipes
        )
        .subscribe(() => {
            // your logic
        });
} Conclusion By adopting the approach outlined above, Angular developers can achieve a leaner, more manageable modal window system. This strategy not only reduces bundle size but also offers a unified method for modal control and customization. Embracing dynamic imports and service-based architecture empowers developers to optimize user experiences while maintaining code scalability and efficiency.

How to Manage Modal Windows in Angular Apps

Form manipulation is a typical task for a Front-End engineer. They are used everywhere - from simple feedback forms to a complex ones for creating something big. While you are using any of the UI frameworks or libraries, they offer us a convenient way to create forms of any complexity easily and quickly. With Angular, we have two options for form building: template-driven and reactive forms. Both of them can be applied in different scenarios. For example, if we need to create some simple form with primitive (or even without) validation, we can consider a template-driven form as a good candidate. Another case is when we need to build something more complex than a login form, with tons of validation, field dependencies from another field, etc. In this way, reactive forms come on the stage. But even with this powerful tool, we sometimes need to build some functionality that is not available from the box. In this article, I will show one of the possible cases, and you can apply this approach to your project. Let's cut to the chase and move to the problem: we need to update a form field based on a value from another form field. Moreover, to enhance the application experience and not confuse a user, we want to highlight (put some message and color the field) the updated field. The fields can be any kind of element (input, dropdown, date picker, etc.), and any combination of field values can lead to the updation of another field. How can we solve this problem? There are some possible ways: We can write a directive for it. It will be used in any control you want despite your choice of form type. But it's quite a complicated task to support this directive in the future, and possibly, it will go for an awkward legacy code that nobody would like to extend or fix some issue related to this; Use EventEmitter. We can observe the expected condition for updating a target field and emit a value. When we do it - update the target field with the emitted value (or you can use this like a trigger and set any value you want). This option is better than the previous one, but it still requires a lot of manual work, and it won't be easy to reuse it somewhere - we will have to implement this mechanism for each case by hand; Extend the FormControl class. In functionality, which is available from the box, we won't find any methods or fields (or even a combination of them) to check that the form control was updated by another one. Let's create it! First things first, we need to create a class for our new control, which extends the FormControl class: import { FormControl } from '@angular/forms';

export class AutoUpdateFormControl<TValue> extends FormControl {
  constructor() {
    super();
  }
} Then, to add a new functionality, we need to write our method for the control updating and mark the inner state as auto-updated: import { FormControl } from '@angular/forms';

export class AutoUpdateFormControl<TValue> extends FormControl {
    public isAutoUpdated: boolean = false;

    constructor() {
        super();
    }

    public autoUpdateValue(value: any, options?: { emitEvent: boolean }): void {
        super.setValue(value, options);
        this.markAsAutoUpdated();
    }

    public setValue(
        value: TValue,
        options?: {
            onlySelf?: boolean;
            emitEvent?: boolean;
            emitModelToViewChange?: boolean;
            emitViewToModelChange?: boolean;
        },
    ): void {
        super.setValue(value, options);
        this.markAsNotAutoUpdated();
    }

    public markAsAutoUpdated(): void {
        this.isAutoUpdated = true;
    }

    public markAsNotAutoUpdated(): void {
        this.isAutoUpdated = false;
    }
} An example of usage: Create a form: interface IForm {
  sourceField: AbstractControl<string>;
  targetField: AutoUpdateFormControl<string>;
}

const form = new FormGroup<IForm>({
    sourceField: new FormControl(''),
    targetField: new AutoUpdateFormControl(),
}); Subscribe to the control and check the required value. If matches - call the autoUpdateValue method. It sets the control value and updates the control field: sourceField form.controls.sourceField.valueChanges.subscribe((value) => {
    if (value === 'test') {
        this.form.controls.testField.autoUpdateValue('updated field');
    }
}); We can add mark-up for handling field highlighting and showing the text depending on the control field: <span *ngIf="form.controls.targetField.isAutoUpdated">Auto-updated</span> If you use some custom components or the wrappers around the third-party ones, you can directly add this kind of template into the component to not repeat it again and again. I found this solution perfect for my needs and decided to share it. Perhaps, it will help someone. But if you want to go further, remember: Your custom form control should remain compatible with Angular's forms API. Avoid altering the existing behavior of FormControl unless necessary; Test your custom form control thoroughly, especially if you're also overriding any of the existing methods; Document your custom methods and any changes to standard behavior to help other developers in your team understand your custom control. With these bits of advice, you can create your custom controls safely and with pleasure.

How to Extend the FormControl Functionality in Angular

There are many helpful tools in the programming world that can simplify, speed up, and make your work more comfortable. One of these instruments is ESLint. ESLint is a static code analyzer for your JavaScript code, which helps to create and support the project's code style, prevents some code issues, and also enforces the best practices for code writing. ESLint is easily and highly configurable, so you can build up your own project-specific rules. In this article, I will tell about 10 base rules that I personally use in my projects and why they matter. camelCase This rule enforces to use for your names which is the common practice for JavaScript. camelCase quotes Double (““) and single (‘‘) quotes in JavaScript are the same from the functional and performance perspective, so you need to choose between them based on your project rules and personal preferences. But you must choose something, do not mix them in your code base. I prefer single quotes no-multiple-empty-lines You can easily restrict the count of empty lines between code lines. Yes, it is very convenient to divide the code into logical areas, but you should not get too carried away with it - one empty line is enough. It ensures code consistency and reduces vertical scrolling a little @angular-eslint/component-selector/@angular-eslint/directive-selector These two rules are from Angular world and quite similar so I combined them into one. They suggest writing selectors for your components and directives with a project prefix and in one style. For example, the directives should be written in a , meanwhile the components in . The prefix is helpful to distinguish your components/directives from the third-party or native ones. camelCase kebab-case no-plusplus There are several reasons to enable this rule and perhaps the most valuable is the Automatic Semicolon Insertion (although can easily be leveraged by rule). It is not technically necessary to put the semicolon at the end of each line - just start writing your code from the new line and the interpreter will manage it by itself (usually, it will put the semicolon at the end of the line). And this can be a spot of issues. For example: semi let i = 1;
let j = 2;

i
++
j

// will be i = 1; j = 3 let i = 1;
let j = 2;

i++
j

// will be i = 2; j = 2 Also, this rule enforces using the same style of increment/decrement for the whole project, which keeps your code in one style. You can add { "allowForLoopAfterthoughts": true } for this rule if you want to use unary increment/decrement for the loops. for ban/ban This rule is quite useful for scenarios when you need to restrict the usage of deprecated functions or some others. One more case - and in unit tests. All tests, except tests with this function, will be skipped from the run. It is useful when you need to run several tests in one big (or not so much) suite for debugging purposes, but it's not a good idea to push them into a remote repository. fit fdescribe no-console The simple is that - we forbid the usage of the to eliminate the chances of pushing it into a remote repository. All of the debugging tools should be kept on the local machine console.log no-unused-vars The rule is self-describing - forbidding the usage of unused variables. Sometimes, while developing a new functionality or refactoring an existing one, we leave some unused code that should be cleaned up. If you are in for a long time in this context it is quite difficult to notice such details. This rule will hint you such places that you can remove unused-imports/no-unused-imports In addition to the above rule - restrict the usage of unused imports. Yes, we can easily notice it locally (since it will be with a gray color in most IDEs), but in code review, it is challenging to do it no-duplicate-imports The most of time we need to import something from the same place. It can be done in two ways: One line import: import { a, b, c } from 'module'; In several lines: import { a } from 'module';
import { b } from 'module';
import { c } from 'module'; This rule enforces importing in one line which improves readability because you can find all your imported staff in one place Conclusion ESLint helps you to make your development process a little bit faster, and simpler and supports your code in one code style that you can create by yourself. It allows aiming at the important things - the application business logic and not paying attention to a code style (respect your code reviewers). The described rules definitely help you in this journey and remember, that you have almost unlimited rules, configs, and settings variations. You should use the rules that are perfectly suitable for your team and project requirements.

10 ESLint Rules You Should Use

Intro Every Front-End application includes a lot of media content. Today, I would like to talk about a small part of media content management - how to deal with icons in your application. Why should you use SVG in your application? Well, there are some advantages in comparison with raster one: SVG SVG icons can shrink and grow at any size you want without quality loss; Scalability: Customization. You can colorize your icons by simply adding a property and voilà - you have it; color CSS Usually, SVG icons are very tiny, and this fact positively impacts the vital performance metrics; Size: Since SVG is XML-based, you can put their description or title for elements inside, which enhances the experience for people with disabilities and makes your application more friendly for search engines. Accessibility: Problem statement Let's look into the ways of using SVG icons in an application. Generally, we can handle it in different ways: Use CSS property. One of the easiest ways to use any type of content in an application; background Create a script that will collect all of your icons and put them into an index.html file. Then, create a component that uses icons via tag and attribute like this: use href <svg>
  <use [attr.xlink:href]="'#app-icon-' + iconName" />
</svg> This approach isn't obvious and can lead to performance issues since you can add some icons with large sizes, and they will be included (even if they aren't used) in your after an application build. This approach has been used for a long time in my current project. It became an issue when we added some icons with a size of about 350 KB, and it increased our index.html by more than three times (from 130KB to 430KB) index.html Create a component that will load an icon from the icons folder when you need it by passing only an icon name. This solution will be described below in detail Solution There is a code of a shared component: import { HttpClient } from '@angular/common/http';
import { ChangeDetectionStrategy, ChangeDetectorRef, Component, Input, OnInit } from '@angular/core';
import { DomSanitizer, SafeHtml } from '@angular/platform-browser';
import { map, shareReplay } from 'rxjs/operators';

import { SvgIconService } from './svg-icon.service';

@Component({
    changeDetection: ChangeDetectionStrategy.OnPush,
    selector: 'app-svg-icon',
    styleUrls: ['./svg-icon.component.less'],
    // *1
    template: ` <div [innerHTML]="sanitizedSvgContent"></div>`,
})
export class SvgIconComponent implements OnInit {
    @Input() public iconName!: string;

    public sanitizedSvgContent: SafeHtml;

    constructor(
        private cdr: ChangeDetectorRef,
        private sanitizer: DomSanitizer,
        private http: HttpClient,
        private svgIconService: SvgIconService,
    ) {}

    // *2
    public ngOnInit(): void {
        this.loadSvg();
    }

    // *3
    private loadSvg(): void {
        // Exit from the method in case of icon absence
        if (!this.iconName) return;
        // Construct your path to an icon
        const svgPath = `/icons/svg/${this.iconName}.svg`;

        // Check if the icon is already cached
        if (!this.svgIconService.svgIconMap.has(svgPath)) {
            // *4
            const svg$ = this.http.get(svgPath, { responseType: 'text' }).pipe(
                map((svg) => this.sanitizer.bypassSecurityTrustHtml(svg)),
                shareReplay(1),
            );

            // Cache the result: iconName as a key and Observable as a value
            this.svgIconService.svgIconMap.set(svgPath, svg$);
        }

        // Get an Observable with sanitized SVG from the Map
        const cachedSvg$ = this.svgIconService.svgIconMap.get(svgPath);

        // Subscribe to the Observable to get the content
        cachedSvg$.subscribe(
            (svg) => {
                // Set it to the property
                this.sanitizedSvgContent = svg;
                // Trigger the 'detectChanges' method for UI updating
                this.cdr.detectChanges();
            },
            // Simple error handling in case of any issue related to icon loading
            (error) => console.error(`Error loading SVG`, error),
        );
    }
} Some important comments for this code snippet: For the template, we use just element with the property, which allows us to insert any HTML as a string. In this place, we insert our SVG icons; div innerHTML In the method we invoke the method, which handles the whole logic of getting a particular icon; ngOnInit loadSvg We must use caching to store already loaded icons. It will prevent unnecessary repeating loading (you can notice it when you use this component for repeated content generation - dashboard rows, tiles, list options, etc.). For this, we use a separate service with only one field - which is ; SvgIconService svgIconMap Map @Injectable({
    providedIn: 'root',
})
export class SvgIconService {
    public svgIconMap: Map<string, Observable<SafeHtml>> = new Map<string, Observable<SafeHtml>>();
} We use for loading an icon by path. For operators, we use function, which returns sanitized content (we simply skip checking this content since we trust the source. If you load icons from sources that you do not trust 100% - it's better to use the function), and to ensure that the HTTP request is made only once, and future subscribers to this will immediately retrieve an icon. HttpClient map sanitize shareReplay Observable Let's see the styles for this component: :host {
    display: inline-block;
    height: 18px;
    width: 18px;
    color: inherit;
}

div {
    &::ng-deep svg {
        display: block;
        height: 100%;
        width: 100%;
        color: inherit;
        fill: currentColor;
    }
} We set the and the to a element for the easiest way of size overriding - you can set any size you want outside by simply adding the and properties; width height host width height For the SVG element, we set and for the same purpose - to get an opportunity for style override outside the component. Adding the , , and properties ensures that the icon will take all available space. color fill display height width With this solution, the has been reduced from 430KB to 6KB, which index.html improved Page Load Time for 100-150ms in average. Before using this component make sure that your icons are in the folder. You can make it by adding them to the property of the . dist assets angular.json Usage example Just add the new component by selector and pass an icon name as an input property: <app-svg-icon icon="yourIconName"></app-svg-icon> Make sure that you put the correct name and icon in the required folder. For size and color changes, you can add a class or an ID. Specify your rules and enjoy the result! Conclusion In this article, you have learned about a simple way of creating a shared for handling SVG icons. Remember that every application has its own specific and required application-fit solution. Hope you have found this article helpful and interesting. Angular component

Stories, News & Mentions about MIXRANK

Mixrank’s Stories on HackerNoon