A developer needs to manually check out the renovate PR, run the changelog command e.g. yarn change, and commit the generated change files.

This is tedious and slows down the update process.

Renovate postUpgradeTasks

Renovate provides a postUpgradeTasks feature that allows running commands after an upgrade.

We can leverage this to automate changelog updates.

Please note this is only available in self-hosted renovate instances. If you are using the hosted version of renovate, a custom pipeline/action can be created to automatically add the changeset commits.

Configuration

Add the following to your Renovate configuration file (renovate.json):

  "postUpgradeTasks": {
    "commands": [
      "yarn change --type patch --message \"$(git show -s --format=%s | sed 's/\"/\\\"/g')\""
    ],
    "fileFilters": ["**/package.json"]
  },

Explanation

• postUpgradeTasks.commands: Runs yarn change automatically, using the latest commit message as the changelog entry.
• fileFilters: Ensures the command runs only when package.json changes.
• Escaping Quotes: The sed command prevents issues with double quotes in commit messages.

Benefits

✅ No more manual changelog updates for dependency upgrades.
✅ Faster PR handling and merging.
✅ Consistent changelog entries.

With postUpgradeTasks, Renovate can handle dependency updates more efficiently by automating changelog generation. Try adding this to your workflow and eliminate the manual effort!

The post Automating Changelog Updates in Renovate Bot PRs appeared first on onthecode.

Before you know it, your app looks like a patchwork of mismatched components.

What is a Design System?

A design system is a collection of reusable components, design principles, and guidelines that help teams build consistent and scalable user interfaces.

It serves as a single source of truth for both designers and developers.

Key Elements of a Design System

Design Tokens

The smallest reusable design properties, such as colors, typography, spacing, and shadows. Instead of hardcoding #FF5733 as a color, you define primary-color and apply it everywhere.

Component Library

A set of reusable UI elements like buttons, forms and modals that adhere to design and accessibility standards.

And to enforce design standards in code, we need a front-end framework (React, Angular, Vue, etc.).

Documentation

Usage instructions, design principles, and accessibility rules to ensure consistency.

How It Works in Practice

Imagine you work at a company with multiple teams working on a single product.

Instead of every team creating their own version of a “Submit” button with slightly different padding, font sizes, and colors, you define a standard button component in your design system.

This button is:

• Styled according to brand guidelines.
• Accessible by default (keyboard navigation, proper contrast, etc.).
• Easily updated — fix it once, and every instance updates automatically.

Why Do Companies Use Design Systems?

The world’s leading companies — Google, Airbnb, IBM, and Microsoft — all use design systems to scale their products.

Here’s why:

Scalability for Large Teams

As products grow, maintaining UI consistency becomes harder.

A design system provides a structured foundation that scales.

Faster Development

Developers don’t have to reinvent the wheel every time they build a new feature.

With a component library, they can reuse existing components, reducing development time significantly.

Consistent UI

A design system ensures that every product maintains a cohesive look and feel.

Without one, different teams may implement slightly different versions of the same components.

Improved Collaboration

Designers define the system.

Developers implement it.

Everyone works from a shared set of rules rather than treating design and development as separate silos.

Accessibility and Usability Standards

All users, including those with disabilities, should be able to use the product effectively.

A design system integrates accessibility best practices into the components from the start.

Design System Examples

These are some of the great examples of solid design systems that power thousands of apps:

• Google’s Material Design
• IBM’s Carbon
• Microsoft’s Fluent
• Atlassian Design

Google created Material Design as a design system to unify the user experience across Android, web, and mobile apps.

It includes everything from typography guidelines to pre-built UI components.

Result? Hundreds of apps now have a consistent and user-friendly UI.

How to Build a Design System

Creating a design system isn’t an overnight task. Here’s a simplified roadmap to get started:

Step 1: Audit Your Existing UI

• Identify inconsistencies in design and code.
• Take inventory of UI components used across your product.

Step 2: Define Design Tokens

• Establish a set of global styles for colors, typography, spacing, and shadows.
• Use a tool like Style Dictionary or CSS variables to manage tokens.

Step 3: Create a Component Library

• Build and document reusable UI components using Storybook.
• Ensure each component meets accessibility standards (ARIA roles, keyboard navigation, etc.).

Step 4: Document Everything

• Write clear usage guidelines for each component.
• Explain when and how components should be used.
• Provide code snippets and design mocks.

Step 5: Adopt a Versioning Strategy

• Use Semantic Versioning (SemVer) to track updates.
• Assign ownership — who maintains the design system?
• Schedule regular audits to ensure it stays relevant.

Common Challenges (and How to Overcome Them)

Even the best design systems face hurdles. Here’s how to tackle them:

“Teams resist adoption.” 

💡 Solution: Educate stakeholders on the time saved by using pre-built components. Offer workshops or demos.

“Keeping the system updated is hard.” 

💡 Solution: Assign a dedicated design system team responsible for maintenance and updates.

“One-size-fits-all doesn’t work.” 

💡 Solution: Allow for controlled flexibility. Some components may need customisation per product.

Conclusion

If your product is growing without a design system, you’re setting yourself up for technical debt and UI inconsistency.

A well-structured design system helps teams move faster, collaborate better, and ship high-quality, scalable UI.

Whether you’re a designer, developer, or product manager, investing in a design system will make your workflow smoother and more efficient.

The post What is a Design System? appeared first on onthecode.

Let’s understand what defaultProject is and when you might need it.

What is default project in Angular?

In Angular, a “default project” refers to the primary application or module within an Angular workspace.

An Angular workspace is essentially a project container that can hold multiple projects, each of which can be an Angular application, library, or other related modules.

When you create a new Angular workspace using the Angular CLI, it automatically generates a default project for you.

ng new my-angular-app

This default project is often named “app” by default.

It serves as the main entry point for your application and includes the initial components, modules, services, and other files necessary to get your Angular application up and running.

You can also specify a different name for the default project during the creation of the workspace using the --defaultProject flag:

ng new my-angular-app --defaultProject=my-default-app

In this case, the default project is going to be “my-default-app” instead of the usual “app.”

Why do we need to specify defaultProject in Angular?

You can have multiple projects within a single Angular workspace e.g., an admin panel and a user-facing frontend.

Each project can have its own configuration, dependencies, and codebase.But they can also share common resources and libraries within the workspace.

Angular CLI assumes you may create multiple projects in your workspace. And tries to help you by specifying the default project for you.

Does angular require defaultProject in angular json file?

Angular itself does not require a defaultProject in the angular.json file.

The defaultProject property is completely optional. It specifies which project to build & serve when a project name is not provided in the command line.

However, there is an exception.

If you have multiple projects in your workspace and you’re running a command that requires a project name (like ng serve or ng build) without specifying a project, then defaultProject is needed to tell Angular which project to apply the command to.

If you only have one project in your workspace, or you always specify your project when running commands, then you don’t need defaultProject.

In conclusion, Angular 14 (or any version) does not require defaultProject, but it can be helpful in multi-project workspaces.

The post Does Angular require defaultProject property? appeared first on onthecode.

In this article, I’ll show you the process of creating a bean of class from a Java library.

What is a Java library and why use it in Spring Boot?

Before we dive in, let’s understand what a Java library is and why it’s beneficial to use one in your application.

A Java library is a collection of pre-compiled classes, methods, and other resources that provide additional functionality and features to your application. These libraries are created by developers to solve common problems and offer reusable code that can be easily integrated into projects.

Using a Java library in your Spring Boot application can save you a significant amount of time and effort. Instead of reinventing the wheel and writing code from scratch, you can leverage the functionality provided by the library, allowing you to focus on the core logic of your application.

This approach promotes code reusability and modularity, enabling you to build robust and scalable applications.

Creating a bean of a class from a Java library

Let’s explore the steps required to create a bean for a class from the library.

The first step is to add the Java library as a dependency in your project. This can be done by updating the build.gradle file for Gradle projects. Once the dependency is added, you’ll need to refresh your project to ensure the library is downloaded and available for use.

Next, you’ll need to configure the bean in the application context. The application context is where you define the entry point with @SpringBootApplication. It is responsible for managing the beans in your application.

@Bean annotation allows you to define the bean directly in your Java code. We will simply annotate a method with @Bean and specify the class of the bean.

Spring Boot will automatically create and manage the bean for you.

@Configuration
@SpringBootApplication()
public class MyServiceApp {

    public static void main(String[] args) {
        SpringApplication.run(MyServiceApp .class, args);
    }

    @Bean
    public PdfConverter pdfConverter() {
        return new PdfConverter();
    }
}

Start with annotating the entry point of your Spring Boot application with @Configuration as shown above.

Next, simply create a method and annotate it with @Bean. Specify the return type of the method as the class of the bean.

Injecting the bean into other components

Now that we have successfully configured the bean in the application context, let’s explore how to inject the bean into other components of your Spring Boot application.

Dependency injection is a key feature of Spring Boot that allows you to easily manage and wire together the components of your application. By injecting the bean into other components, you can utilise its functionality and leverage its capabilities.

There are several ways to inject the bean into other components. The most common approach is to use constructor injection. This involves adding a constructor to the component class and specifying the bean as a parameter. Spring Boot will automatically inject the bean when creating an instance of the component.

    public DocumentFormatter(PdfConverter pdfConverter) {
        this.pdfConverter = pdfConverter;
    }

Another approach is to use field injection. This involves adding a field to the component class and annotating it with @Autowired. Spring Boot will automatically inject the bean into the field when creating an instance of the component.

public class MyService {

    @Autowired
    private PdfConverter pdfConverter;
}

You can also use setter injection, where you add a setter method to the component class and annotate it with @Autowired. Spring Boot will invoke the setter method and inject the bean before initialising the component.

public class MyService {

    private PdfConverter pdfConverter;

    @Autowired
    public void set(PdfConverter pdfConverter) {
        this.pdfConverter = pdfConverter;
    }
}

Using the bean in Spring Boot applications

Now that we’ve covered the process of creating and configuring a bean from a Java library in Spring Boot, let’s explore how to use the bean in your applications.

Once you configure and inject the bean into your components, you can access its methods and properties just like any other object in your application. This allows you to leverage the functionality provided by the Java library within your Spring Boot application.

To use the bean, simply call its methods or access its properties in your code. You can also pass the bean as a parameter to other methods or components, allowing you to utilise its functionality throughout your application.

It’s important to note that the bean’s lifecycle is managed by Spring Boot, so you don’t need to worry about creating or destroying the bean yourself. Spring Boot will handle the instantiation, initialisation, and destruction of the bean automatically.

Common challenges and troubleshooting when creating a bean from a Java library

While creating a bean from a Java library in Spring Boot is generally straightforward, there may be some challenges or issues that you encounter along the way. Let’s explore some common challenges and troubleshooting techniques to help you overcome these obstacles.

One common challenge is ensuring that the Java library is properly added as a dependency in your project. Double-check the pom.xml or build.gradle file to ensure that the library is correctly specified. Make sure to refresh your project to download the library if necessary.

Another challenge may arise when configuring the bean in the application context. Ensure you specify the class of the bean and that configure any dependencies properly. Double-check the XML-based or annotation-based configuration to ensure accuracy.

If you’re experiencing issues with dependency injection, verify that the bean is properly injected into your components. Check for any missing @Autowired annotations or incorrect usage of constructor, field, or setter injection. Ensure that the bean is accessible within the component’s scope.

If you’re still encountering issues, refer to the documentation of the Java library and Spring Boot for any specific troubleshooting steps. Additionally, consider reaching out to the developer community or support channels for assistance.

Conclusion

In this article, we explored the process of creating a bean of class from a Java library in Spring Boot. We discussed the benefits of using Java libraries in your Spring Boot application, the steps to create a bean, and the process of configuring the bean in the application context. We also covered how to inject the bean into other components and the usage of the bean in Spring Boot applications.

Happy coding!

The post How to Create a Bean of Class from a Java Library in Spring Boot appeared first on onthecode.

This is thanks to the default Angular’s change detection mechanism, which constantly checks for changes in data and updates the view accordingly. While this is great for most use cases, it is possible to manually detect changes for performance optimisation.

Let’s explore change detection strategies in Angular.

What is a change detection strategy?

A change detection strategy is a mechanism that decides when Angular should update the view of a component.

Angular offers the following change detection strategies:

• ChangeDetectionStrategy.Default
• ChangeDetectionStrategy.OnPush

Any newly generated component uses the default strategy.

ChangeDetectionStrategy.Default

Default strategy triggers change detection for DOM events, timers, promises, XHR, observables etc. Therefore, every time something changes in our application, a change detection will run on all components to update the view.

Angular achieves this by creating a change detector, which is responsible for listening to changes and updating the view of the component.

ChangeDetectionStrategy.OnPush

The OnPush strategy can be used to optimise the performance of an Angular application.

With OnPush strategy, Angular only performs a change detection cycle on a component and its children, if there is a change in the component’s input properties or if an event is triggered.

OnPush triggers change detection when:

• DOM events listened by the component emit
• async pipe receives a new event
• @Input() property updates by change detection
• Explicitly registration using ChangeDetectorRef::markForCheck

If the component’s data model is updated outside of Angular’s change detection mechanism, Angular will not update the view.

This may sound like a drawback, but it’s actually a useful feature when used correctly.

The OnPush strategy is designed to reduce the number of unnecessary change detection cycles. This is especially important in complex applications, where change detection can become a bottleneck and degrading overall performance of the application.

How to use onPush strategy

To use the OnPush strategy, you simply need to set the changeDetection property of the component’s @Component decorator to ChangeDetectionStrategy.OnPush.

Here’s an example:

import { ChangeDetectionStrategy, Component } from '@angular/core';

@Component({
  selector: 'app-hello-world',
  template: `
    <p>{{ message }}</p>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class HelloWorldComponent {
  message = 'Hello, World!';
}

It’s important to note that when using the OnPush strategy, you need to make sure that Angular is aware of any changes in the component’s data model.

This can be done by using the markForCheck method from the ChangeDetectorRef class.

import { ChangeDetectorRef } from '@angular/core';

constructor(private cd: ChangeDetectorRef) { }

ngOnInit() {
  // Do some work that changes data
  this.cd.markForCheck();
}

The ChangeDetectorRef class provides a way to interact with the change detection mechanism and manually trigger change detection.

You can mark a component or its ancestors for checking using the markForCheck method. Next time change detection runs, the view will reflect the new state of data.

markForCheck() vs detectChanges()

Another method available on the change detector is detectChanges. You might be wondering, what is the difference between markForCheck and detectChanges.

The key difference between these is that detectChanges() triggers change detection, while markForCheck() doesn’t trigger change detection.

With detectChanges(), the change detection will run for the current component and all its children. This is a common fix to the infamous error Expression has changed after it was checked.

On the other hand, markForCheck() simply goes upwards from the current component to the root component and updates their view state to ChecksEnabled. The change detection for the component will happen in the future either as part of the current or next change detection cycle. The parent component views will also be checked even if they had detached change detectors. 

Should I use onPush strategy?

If change detection is a bottle-neck in your component, go ahead and try onPush change detection strategy. This is a great way to fine-tune the performance of your application.

However, premature optimisation can have an adverse effect on your application.

If you use onPush strategy without a valid reason, the component code will be more complex, harder to test and more difficult to maintain.

Based on my experience, the default strategy will work just fine for most small to medium sized applications.

Conclusion

In this post, we’ve looked at the different change detection strategies available in Angular. Default strategy automatically updates view when there is a change in the data model. OnPush strategy allows us to optimise performance by giving us the freedom to choose when to check for changes.

The post Change Detection in Angular: Default vs OnPush appeared first on onthecode.

Angular provides a built-in Title service that we can use to set the title of the web page dynamically from code. We will use the title service in combination with router events to change page title for all routes.

Setting page title in Angular

Firstly, import the Title service in the component you want to set the title:

import { Title } from '@angular/platform-browser';

Inject the Title service in the constructor of the component:

constructor(private titleService: Title) {}

Then you can use the setTitle method of the Title service to set the title of the web page.

For example, you can set the title based on the data received from a service or from the component’s properties:

this.title.setTitle(`My Awesome App - ${data.title}`);

As you can see, it is pretty straightforward to use set the title in Angular.

Setting the title for all routes

Instead of setting the title in every component that’s associated with a route, we’ll take it a step further and dynamically set the title from the routes table.

DRY (don’t repeat yourself) is a principle in software development that recommends to do something once, and only once.

The first step is to update routes table in every feature module to hold page titles.

const routes: Routes = [
  {
    path: "",
    component: HomePageComponent,
    data: {
      title: "Home"
    }
  },
  {
    path: "blog",
    component: BlogPageComponent,
    data: {
      title: "Blog"
    }
  },
  {
    path: "**",
    component: NotFoundPageComponent,
    data: {
      title: "Not Found"
    }
  }
];

You should now go through all routes of your app and make sure there is a title associated with every route!

Next, generate a service to get data from the current route:

ng generate service route-data

Implement the service with below code:

import { Injectable } from "@angular/core";
import { ActivatedRoute, ActivatedRouteSnapshot, Data } from "@angular/router";

@Injectable({
  providedIn: "root"
})
export class RouteDataService {

  constructor(private route: ActivatedRoute) { }

  get(): Data {
    return this.getRouteSnapshot().data;
  }

  private getRouteSnapshot(): ActivatedRouteSnapshot {
    let route = this.route;

    while (route.firstChild) {
      route = route.firstChild;
    }

    return route.snapshot;
  }
}

This service allows us to pull out the data object we defined in our routes earlier.

Like any other singleton service, we can inject it into any component to set the title.

Since we want to set the title for every page, we need to subscribe to router events in the root component app.component.ts.

Let’s to update app.component.ts to read the title every time navigation occurs:

import { filter } from 'rxjs';

import { Component, OnInit } from '@angular/core';
import { Title } from '@angular/platform-browser';
import { NavigationEnd, Router } from '@angular/router';
import { RouteDataService } from './route-data.service';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent implements OnInit {
  constructor(private router: Router,
    private routeDataService: RouteDataService,
    private title: Title) {
  }

  ngOnInit(): void {
    this.router.events
      .pipe(filter(event => event instanceof NavigationEnd))
      .subscribe(_ =>
        this.title.setTitle(`${this.routeDataService.get()["title"]} - Umut Esen`)
      );
  }
}

By using this method, you can set the title of the web page dynamically based on the data from the router events, which will update the title of the window in real-time.

Conclusion

In summary, we learned how to set the page title in Angular. Through DRY principle, we implemented a feature that sets the page title based on Angular router events.

Let me know what you think by dropping a comment below!

The post How to Set Page Title Based on Route in Angular appeared first on onthecode.

We will create a basic routes file and append routes dynamically from an XML sitemap ahead of running npm run prerender command when building the application.

Pre-requisites

This post assumes you already have an Angular Universal application. If this is not the case, add server-side rendering (SSR) capability to your Angular application by following this guide.

Once you add SSR, you can use npm run prerender command to prerender your application.

Benefits of prerendering

Prerendering with Angular Universal refers to the process of rendering an application’s content on the server side before sending it to the client.

This can help improve the performance of an Angular application, especially for users with slow internet connections or on devices with limited resources.

By pre-rendering the application’s initial state on the server and then serving the fully rendered HTML to the client, the client’s web browser can start rendering the page immediately, rather than having to wait for all of the necessary JavaScript to download and execute before the content is displayed.

This can lead to a faster time to first paint and a better user experience overall.

Prerender options

There are a few build options available to use with prerender command as outlined by official documentation.

These options are:

• Provide extra routes in the command line
• Provide routes using a file
• Prerender specific routes

A sitemap is likely to have a large number of URLs so we’ll provide routes using a file.

Modify prerender command

Open up package.json and update prerender command to use a routes file:

"prerender": "ng run myapp:prerender --routes-file routes.txt"

There is no need to manually create a routes.txt file because the script we’re about to write will automatically create it.

Generate routes file

We will retrieve urls from an XML sitemap using xml-sitemap-url-scraper package.

Install this package as a dev dependency so it does not ship with production bundle:

npm install xml-sitemap-url-scraper --save-dev

Using this package to retrieve URLs is pretty simple, just provide a direct link to your sitemap as shown below.

What you’ll get in return is a promise containing all of the URLs found in the sitemap.

const fs = require('fs');
const { sitemapUrlScraper } = require("xml-sitemap-url-scraper");

const url = "https://mysite.com/sitemap_index.xml";

sitemapUrlScraper([url])
    .then(urls => {
        const routes = urls
            .map(url => url.replace(new URL(url).origin, ""))
            .join('\r\n');

        fs.writeFile('routes.txt', '\r\n' + routes, err => {
            if (err) {
                console.error(err);
            }
        });
    })
    .catch(err => { console.log(err); })

Since prerender command expects relative URL separated by a line break in the routes file, we’re post-processing the results before creating the file routes.txt.

You’ll want to save this script to the root of your project and run using node in the command line:

node route-fetcher.js

Processing XML Sitemap:  https://mysite.com/sitemap_index.xml
Processing XML Sitemap:  https://mysite.com/post-sitemap.xml
Processing XML Sitemap:  https://mysite.com/page-sitemap.xml
Processing XML Sitemap:  https://mysite.com/category-sitemap.xml

You would ideally run this script as part of your continuous delivery pipeline, before prerendering the application.

Your routes.txt will be populated with all the links specified in your sitemap.

Conclusion

Hopefully this post helped you with prerendering the pages of your Angular application using a routes file.

What do you think? Let me know in the comments below!

The post Generating Routes File for Angular Universal Prerender appeared first on onthecode.

In this post, I’ll explain the steps I took to identify the root cause of issue and propose potential solutions.

Identifying the root cause

The exception stack trace hints at the root cause of this issue:

(Windows 8.1.0.0): Executed 9 of 846‌ SUCCESS‌ (0 secs / 1.912 secs)‌
15 12 2022 15:14:23.895:ERROR [karma-server]: ‌TypeError: Cannot read properties of undefined (reading 'range')‌
    at handleRangeHeaders (D:\Agents\1\_work\424\s\MyApp.Web\node_modules\webpack-dev-middleware\lib\util.js:134:21)
    at processRequest (D:\Agents\1\_work\424\s\MyApp.Web\node_modules\webpack-dev-middleware\lib\middleware.js:98:19)
    at ready (D:\Agents\1\_work\424\s\MyApp.Web\node_modules\webpack-dev-middleware\lib\util.js:54:12)
    at handleRequest (D:\Agents\1\_work\424\s\MyApp.Web\node_modules\webpack-dev-middleware\lib\util.js:185:5)
    at D:\Agents\1\_work\424\s\MyApp.Web\node_modules\webpack-dev-middleware\lib\middleware.js:64:7
    at new Promise (<anonymous>)

Let’s dig deeper and find out what’s going on the line of code throwing this exception:

// node_modules\webpack-dev-middleware\lib\util.js:134 
handleRangeHeaders(content, req, res) {
    // assumes express API. For other servers, need to add logic to access
    // alternative header APIs
    res.setHeader('Accept-Ranges', 'bytes');

    if (req.headers.range) {
      const ranges = parseRange(content.length, req.headers.range);

It looks like webpack-dev-middleware is handling requests as part of the test run. When it comes to handling headers on the request, it is falling over with:

Cannot read properties of undefined (reading 'range')‌

Clearly, Accept-Ranges headers are not present in some requests performed during our test run.

In order to pinpoint which request is causing this error, let’s output the name of each file during the test run:

// node_modules\webpack-dev-middleware\lib\util.js:134 
  handleRangeHeaders(content, req, res) {
    console.log(req.url);

Run tests again with ng test and see the file name causing this issue:

/_karma_webpack_/assets/icons/icon-library.svg
15 12 2022 15:14:23.895:ERROR [karma-server]: ‌TypeError: Cannot read properties of undefined (reading 'range')‌

At this point, we can see the file name and this should hopefully be familiar to you. The chances are your project is somehow trying to load this file from the assets folder using a relative path.

Let’s look at what we can do to fix this issue.

Fix #1 – Configure karma to use proxy

The very first thing I tried to fix this issue was to follow the advice of Ievgen, who had the same problem within an Angular project inside a docker container.

Simply add the following code in karma.conf.js after config.set({

proxies: {
    '/assets/': '/base/src/assets/'
},

Ievgen suggests this new rule in karma configuration will point all requests matching /assets/ to the base folder of the project. Unfortunately, this did not work for me even after adjusting the path to match the setup of my project.

Although Ievgen’s solution did not work for me, it put me in the right direction and helped identify the following fixes.

Fix #2 – Stop using relative paths

The first thing I did was to find all the usages of assets folder in the entire source code.

It turned out some css files were using relative paths to load some images from the assets folder:

  content: url(../../../assets/icons/back-icon.png);

The fix is to define the path from the src folder:

  content: url("/src/assets/icons/back-icon.png");

Repeat this for all references of assets folder to ensure all paths correctly identify a file.

Fix #3 – Exclude 3rd party stylesheets during test run

There may be external packages included in the test configuration within angular.json that are using relative path to assets folder.

// angular.json 
"test": {
          "builder": "@angular-devkit/build-angular:karma",
          "options": {
            "codeCoverage": true,
            "main": "src/test.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "src/tsconfig.spec.json",
            "karmaConfig": "karma.conf.js",
            "styles": [
              "src/styles.css"
              "node_modules/@my-company/web-styles/sass/main.scss"
            ],
            "scripts": [],
            "assets": [
              "src/assets",
              "src/Web.config",
              "src/auth.config"
            ]
          } 

As you can see in the above snippet, the test configuration is loading styles from an external package.

Since this package is internally using relative paths to assets, folder the exception is thrown. The solution is to remove this line of code to exclude 3rd party stylesheets during the test run.

I hope you found this post useful, drop a comment below to let me know what you think!

The post Fixing Angular Unit Tests: Cannot read property ‘range’ of undefined appeared first on onthecode.

In this post, I will show you how to set the HTTP status code from an Angular application with SSR.

Background

Let’s address why you might even want to set HTTP status code from an Angular component in the first place.

As an example, my application renders the following component when it does not recognise a URL:

import { Component } from '@angular/core';
@Component({
  selector: 'app-not-found-page',
  template: `
      <h1>Not Found</h1>
      <p>This page does not exist.</p>
  `
})
export class NotFoundPageComponent {}

When the component is rendered in the browser, the status code is actually 200 OK.

Search engines would consider this response as valid and continue indexing the contents of this page.

In this case, we should be returning the correct status code: 404 Not Found.

Another possible scenario is returning status code 401 Unauhorised when securing pages from anonymous access.

Inject response from Express.js

Like any other server-side application, we need to modify the HTTP response to set the status code.

To do this in Angular Universal, we can inject the Response object from Express.js server into the constructor of the component:

import { Component, Inject, Optional } from '@angular/core';
import { RESPONSE } from '@nguniversal/express-engine/tokens'
import { Response } from 'express'
@Component({
  selector: 'app-not-found-page',
  template: `
      <h1>Not Found</h1>
      <p>This page does not exist.</p>
  `
})
export class NotFoundPageComponent {
  constructor(
    @Optional() @Inject(RESPONSE) private response: Response
  ) { }
}

Notice the dependency is optional since Angular Universal applications run on both the server and the browser.

An optional parameter becomes null when the application is running in the browser. This means any usage of the response should be protected with a null guard.

Setting the status code

With the response available in the component, we can implement our logic inside the OnInit event.

We can pass in the status code to the status method as shown below as per Response API docs.

export class NotFoundPageComponent implements OnInit {
  constructor(
    @Optional() @Inject(RESPONSE) private response: Response
  ) { }

  ngOnInit() {
    // Return 404 when running server side
    if (this.response) {
      this.response.status(404);
    }
  }
}

Since the response can be null in the browser context, we guard against null value to avoid our component from failing.

Let’s now serve an SSR build locally to test the status code.

npm run build:ssr
npm run serve:ssr

Running the same scenario now yields 404 Not Found response in the browser.

Full source code

Putting it all together this is how the component looks like now:

import { Component, Inject, OnInit, Optional } from '@angular/core';
import { RESPONSE } from '@nguniversal/express-engine/tokens'
import { Response } from 'express'
@Component({
  selector: 'app-not-found-page',
  template: `
      <h1>Not Found</h1>
      <p>This page does not exist.</p>
  `
})
export class NotFoundPageComponent implements OnInit {

  constructor(
    @Optional() @Inject(RESPONSE) private response: Response
  ) { }

  ngOnInit() {
    // Return 404 when running server side
    if (this.response) {
      this.response.status(404);
    }
  }
}

Unit tests

It helps to put in unit test coverage around the features of the component to act as a safety net. Tests also help document our code.

This is the full spec file containing the implementation details for all of the tests:

import { ComponentFixture, TestBed } from '@angular/core/testing';

import { NotFoundPageComponent } from './not-found-page.component';
import { RESPONSE } from '@nguniversal/express-engine/tokens';
import { By } from '@angular/platform-browser';

describe('NotFoundPageComponent', () => {
  let component: NotFoundPageComponent;
  let fixture: ComponentFixture<NotFoundPageComponent>;
  let response: any;

  describe('client-side', () => {
    beforeEach(async () => {
      await TestBed.configureTestingModule({
        declarations: [NotFoundPageComponent],
        providers: [
          {
            provide: RESPONSE,
            useValue: null
          }
        ]
      })
        .compileComponents();

      fixture = TestBed.createComponent(NotFoundPageComponent);
      component = fixture.componentInstance;
      response = TestBed.inject(RESPONSE);
      fixture.detectChanges();
    });

    it('should create', () => {
      expect(component).toBeTruthy();
    });

    it('should render elements', () => {
      expect(fixture.debugElement.query(By.css("h1")).nativeElement.textContent).toEqual("Not Found");
      expect(fixture.debugElement.query(By.css("p")).nativeElement.textContent).toEqual("This page does not exist.");
    });
  });

  describe('server-side', () => {
    beforeEach(async () => {
      await TestBed.configureTestingModule({
        declarations: [NotFoundPageComponent],
        providers: [
          {
            provide: RESPONSE,
            useValue: jasmine.createSpyObj("Response", ["status"])
          }
        ]
      })
        .compileComponents();

      fixture = TestBed.createComponent(NotFoundPageComponent);
      component = fixture.componentInstance;
      response = TestBed.inject(RESPONSE);
      fixture.detectChanges();
    });

    it('should set 404 status code on response', () => {
      expect(response.status).toHaveBeenCalledOnceWith(404);
    });
  });

});

The post Angular Universal: Setting HTTP Status Code appeared first on onthecode.

./src/polyfills.ts - Error: Module build failed (from ./node_modules/@ngtools/webpack/src/ivy/index.js):
Error: Cannot resolve type entity i3.DialogModule to symbol

Error: node_modules/@angular/material/dialog/index.d.ts:3:36 - error TS2307: Cannot find module '@angular/cdk/dialog' or its corresponding type declarations.

3 import { CdkDialogContainer } from '@angular/cdk/dialog';

After hours of research online with no luck, it turns out I never had @angular/cdk as a dependency in the project.

I found this out by checking the getting started section of Angular Material docs.

How to fix Error: Cannot resolve type entity i3.DialogModule to symbol:

1. Open up package.json file
2. Add @angular/cdk to dependencies section:
3. Run npm install to update download the new package

It doesn’t matter where you put the new dependency, as long as it is within the dependencies block.

One thing to watch out for is using the correct version – it must match the rest of the Angular packages.

In the code snippet below, you can see I am using version ^14.2.1 because all other angular packages are on this version.

  ....
  "dependencies": {
    "@angular/animations": "^14.2.1",
    "@angular/common": "^14.2.1",
    "@angular/compiler": "^14.2.1",
    "@angular/core": "^14.2.1",
    "@angular/cdk": "^14.2.1",
    ...
  }
  ...

I hope this post helped you solve this problem!

It is really not clear to my why I didn’t have this error in Angular 13. After all, a missing dependency should break builds, right? Let me know in the comments, if you know why.

The post Error: Cannot resolve type entity i3.DialogModule to symbol appeared first on onthecode.