Angular

Ignite your way with Infragistics Ultimate Developer Toolkit

Published Oct 31, 2019

Updated Feb 14, 2023

11 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Infragistics is celebrating its 30th anniversary! Throughout the years, Infragistics built its strategy around two strong pillars: embracing the latest and greatest technologies, and focusing on high-performance and speed. These main pillars enriched developers, and their communities, with toolsets that made development enjoyable, and productive at the same time.

Infragistics presents the Ultimate suite as a single platform for UX design, and enterprise app development, for the web, desktop, and mobile. The suite offers more than 100 beautifully styled, high-performance grids, charts, and other UI controls.

Infragistics thought of every detail in the development life-cycle process. They offer prototyping tools to help you sketch your designs from the client’s early inception stage, allowing you to work on the UX, finalize the layout, and even orient the developer to build the final app.

In this introductory article on their Ignite UI suite, I will explore the different platforms supported by Infragistics, and will then delve into more details on the Ignite UI for Angular suite.

Infragistics Ultimate Developer Toolkit

Infragistics provides UI components for a variety of frameworks and platforms. This includes ones for the Web (ASP.NET, Angular, React and JavaScript), Desktop (Windows Forms and WPF), and Mobile (Xamarin, iOS and Android).

The components are served in packages. For instance, when developing with React, you would only install the packages for Ignite for React.

Here’s a list of the supported platforms and their corresponding components.

Web

Indigo Design A unified workspace for visual design, UX prototyping, and code generation for Angular development.

Ignite UI for Angular Infragistics wraps together more than 50 Material-based UI native components, designed, and built on an Angular platform.

Ignite UI for React A set of native UI components for React developers, featuring a high-performance data grid, and real-time high-volume data charts.

Ignite UI for JavaScript This package offers more than 100 HTML5 / JavaScript jQuery components with wrappers for React, Angular & ASP.NET MVC.

Infragistics Ultimate UI for ASP.NET ASP.NET AJAX UI controls.

Desktop

Infragistics Ultimate UI for Windows Forms This package contains more than 100 fully-featured Microsoft Office-style UI controls.

Infragistics Ultimate UI for WPF This package contains WPF native UI controls.

Mobile

Infragistics Ultimate UI for Xamarin This package contains Xamarin native UI components including Charts, Grid, Scheduling, and much more.

Infragistics Ultimate UI for iOS This package contains native UI controls for both iPad and iPhone apps.

Infragistics Ultimate UI for Android This package contains lightning-fast native UI controls for Android apps.

Prototyping

Infragistics offers the Indigo.Design Desktop to build prototypes for User Stories to share with peers for review, and collaboration. This software comes in two flavors for both Windows and Mac OS machines. Here’s a link to the software’s official documentation.

In addition to all the packages listed, Infragistics puts great effort in delivering an easy-to-follow, and extensive documentation for all their platforms, and UI components. You can consult the document anytime by visiting the Infragistics Help documentation website.

Also, Infragistics offers a set of reference apps that you can look at, take ideas from, and that allow you to see, in real-time, how the UI components are being used and integrated inside apps. You can have a look at the reference apps by visiting the Infragistics Apps Gallery website.

Ignite UI for Angular

Infragistics has placed a great emphasis on developing their Angular suite. They offer native UI components for Angular that are based on the Google Material design standards. In addition, they enrich the Angular app development with a unique, and valuable experience, by offering the Sketch UI kits.

The Sketch UI kits have a one-to-one mapping with all the Angular components they offer. The designer opens Sketch, loads the Sketch UI kits, and then designs the app screens, using “native” Ignite UI for Angular components. The end result is a prototype that is uploaded to the Infragistics Cloud, and shared with peer developers, designers, and stakeholders to review, comment on, and use to produce a final design prototype.

The developers can then take prototype URLs, go to Visual Studio Code per se, install the Infragistics extension, and generate code assets for their Angular app, based on the prototype. The extension generates Angular Components based on the screens baked inside the prototype.

The Ignite UI for Angular suite aims to help developers build modern, high-performance HTML 5 JavaScript apps for modern desktop browsers, mobile experiences, and progressive web apps (PWA).

Prerequisites

Before you can start using Ignite for Angular, you must have the following installed on your machine:

Visual Studio Code (VS Code). You can use any other code editor, but in order to make full use of the rich support Infragistics offers for Angular development, it is recommended that you use VS Code.
Node.js and NPM. This requirement is standard for developing front-ends using Angular, React, Vue and even vanilla JavaScript.

Ignite UI CLI

Infragistics takes that extra step, and offers the Ignite UI CLI. This is a Command-Line Interface by Ingratistics.

The easiest way to create, and scaffold an app with Infragistics, is to use the CLI. This CLI is not only used with Angular, but can also be used for React and jQuery apps.

Here’s a step by step guide on how to generate your first app using the Ignite UI CLI.

You start by installing the Ignite UI CLI as a global dependency on your machine by issuing the following command:

npm install -g igniteui-cli

Once the installation process is finished, you can start the tool using either guided experience or specific commands.

For instance, to create a new Angular app, you issue the command:

ig new <project name> --framework=angular --type=igx-ts

To add a new Component to your app you issue:

ig add <component/template> <component_name>

You can read more about the CLI on the Ignite UI CLI official page.

Selection of Angular Components

Going through all of the Angular components in depth now, isn't useful. I have highlighted a few that interested me, and will give you a small overview of what is offered.

Financial Chart

The Financial Chart is one of the most popular and advanced charts offered by Infragistics. This type of chart is used to visualize financial data using a simple, and intuitive API.

To play with a live Financial Chart, here’s a sample hosted on StackBlitz: {% stackblitz angular-ytbzfi %}

Data Chart

Infragistics Angular Data Chart is the most extensive, and feature-rich, chart on the web today. It supports chart compositions (multiple charts overlaid), axis, series, legend, and annotation layers. Being highly customizable, it offers many more options, and features.

Something special about this chart is the long list of series types supported by default. The list includes, but is not limited to:

An example of a Radial Series chart is as follows:

You can find the entire list here: Data Chart Series Types.

To play with a live Data Chart, here’s a sample hosted on StackBlitz: {% stackblitz angular-bv857d %}

Mask

You apply the igxMask directive on a text input field, and you can control the user input, and format the visual value, based on configurable mask rules. You have a rich set of masking rules to choose from.

To use this directive, start by importing the following Angular Modules into your app module:

// app.module.ts

...
import { IgxMaskModule, IgxInputGroupModule } from 'igniteui-angular';

@NgModule({
    ...
    imports: [..., IgxInputGroupModule, IgxMaskModule]
    ...
})
export class AppModule {}

Then you can apply an Input Mask inside your components. The example below shows how you can use a Phone Input Mask:

<igx-input-group>
    <igx-prefix>
        <igx-icon>phone</igx-icon>
    </igx-prefix>
    <label igxLabel>Phone</label>
    <input igxInput type="text" [igxMask]="'(####) 00-00-00 Ext. 9999'"/>
</igx-input-group>

If you would like to play with a live Mask component, here’s a sample hosted on StackBlitz:

{% stackblitz angular-yh3dpu %}

The Navigation Drawer is one of my favorite components. It provides a smooth and smart navigation experience for developing Web apps that will be used on Mobile devices.

The Navigation Drawer is a side-navigation container. It can rest above content, and slide in/out of view or be pinned to expand/collapse within content. The component is highly configurable via its input properties: Mode (pinned, open, mini-variant) and Position (Right and Left). The mini-variant mode renders the side-navigation bar with icons only instead of showing both the icon, and text of the item.

Installing and using this component is no different from the rest of component offered by Ignite for Angular.

To play with a live Navigation Drawer component, here’s a sample hosted on StackBlitz: {% stackblitz angular-rsizth %}

Layout Manager

The Layout Manager directive, which is part of Ignite UI for Angular, is a wrapper on-top of Flexbox. You can organize and structure your HTML markup without having to write a single CSS selector for the layout.

The Layout Manager focuses on giving Angular developers a seamless design experience when developing, and laying out their apps.

To use this directive, start by importing the IgxLayoutModule Angular Module into your app module:

// app.module.ts

...
import { IgxLayoutModule } from 'igniteui-angular';

@NgModule({
    ...
    imports: [..., IgxLayoutModule ]
    ...
})
export class AppModule {}

Then you can apply the igxLayout, igxFlex, and other related directives to your HTML markup as follows:

<div class="layout-box" igxLayout igxLayoutDir="row">
              <div class="layout-box__el" igxFlex>1</div>
              <div class="layout-box__el" igxFlex>2</div>
              <div class="layout-box__el" igxFlex>3</div>
</div>

If you would like to play with a live Layout Manager component, here’s a sample hosted on StackBlitz: {% stackblitz angular-vtetkk %}

DataGrid

Infragistics claims to have developed the fastest high performance Data Grid for Angular platform.

The Grid is, by far, the most customizable Data Grid currently existing for the Angular ecosystem. The team at Infragistics have thought of every single detail a developer might need and want to customize in a Data Grid.

The features include data binding, live data binding (data streaming), editing, row editing, paging, filtering, advanced filtering, sorting, grouping, column moving, column pinning, column resizing, column hiding, searching, toolbar, multi-column header, exporting to Excel, pasting from Excel, and so much more.

You are in the presence of the Infragistics version of Excel Spreadsheets!

Importing and using the Data Grid cannot be simpler!

Start by importing the IgxGridModule Angular Module to the app module:

// app.module.ts

import { IgxGridModule } from 'igniteui-angular';
// Or
import { IgxGridModule } from 'igniteui-angular/grid';

@NgModule({
    imports: [
        ...
        IgxGridModule.forRoot(),
        ...
    ]
})
export class AppModule {}

To embed a Data Grid inside the HTML markup, add the following component:

<igx-grid #grid1 id="grid1" [data]="localData" [autoGenerate]="true"></igx-grid>

To reference the Data Grid from inside the Angular Component code-behind, add the following:

import { IgxGridComponent } from 'igniteui-angular/grid/';
// Or
import { IgxGridComponent } from 'igniteui-angular'
...

@ViewChild('myGrid', { read: IgxGridComponent })
public grid: IgxGridComponent;

It’s that straightforward to start using the Data Grid component for Angular!

Check the Infragistics extensive docs to learn more about customizing, and enabling more features in the Data Grid.

If you would like to play with a live Data Grid component, here’s a sample hosted on StackBlitz: {% stackblitz angular-4oqzke %}

Excel Library

An Excel Library comes as part of the Ignite UI for Angular. The Infragistics Angular Excel Library allows you to work with spreadsheet data using familiar Microsoft Excel spreadsheet objects like Workbooks, Worksheets, Cells, Formulas, and many more.

You can export your app data to an Excel sheet, and also load data from an Excel sheet into your app.

Have a look at the Excel Library page for more examples on all the options, and possibilities available for you.

Moreover, Infragistics offers an Export to Excel service that you can use inside your Angular components, and services.

To use this service, you start by importing the IgxExcelExporterService into the app module:

// app.module.ts

...
import { IgxExcelExporterService } from "igniteui-angular";

@NgModule({
  providers: [ IgxExcelExporterService ]
})

export class AppModule {}

Then, you inject the IgxExcelExporterService into the constructor of the component or service:

// component.ts

...
import { IgxExcelExporterService, IgxExcelExporterOptions } from "igniteui-angular";
...

constructor(private excelExportService: IgxExcelExporterService) {
}

And finally, to export your data to Excel, you call the exportData() function:

// component.ts

...

public localData = [
  { Name: "Eric Ridley", Age: "26" },
  { Name: "Alanis Brook", Age: "22" },
  { Name: "Jonathan Morris", Age: "23" }
];

public exportButtonHandler() {
  this.excelExportService.exportData(this.localData, new IgxExcelExporterOptions("ExportedDataFile"));
}

Indigo Design System

The Indigo Design System offered by Infragistics caught my attention to the extent that I wanted to dedicate a section to talk about this design system, and its versatility, especially for designers, and developers working on Angular apps.

Indigo Design System offers a unified platform for visual design, UX prototyping, code generation, and app development.

You’ve got your designers, and developers, both integrated into a single platform. This design system has a workflow that is depicted as follows:

Designers create designs in Sketch using the Indigo.Design System. The Indigo Design System integrates with Sketch in the form of:
Indigo-Components (Design library with 50+ components that match Ignite UI for Angular)
Indigo-Patterns (A collection of common UI patterns composed of Indigo-Components)
Indigo-Styling (Customize colors, typography, icons, and elevations to match your brand)
Designers share and test prototypes with peer developers, designers, and stakeholders, via a common platform known as cloud.indigo.design.
Use Sketch to create interactive prototypes of your designs and screens.
Share and Collaborate with others: View prototypes on any device, and collect feedback using comments.
Developers generate Angular components, and code from prototypes
Install the Infragistics Extension for VS Code
Load-in a prototype by URL and the code generation process starts

Conclusion

To explore and try all the features of Infragistics Ultimate Developer Toolkit, would require writing books and articles! This article introduces the Infragistics Ultimate Developer Toolkit, and related hyperlinks, that you can follow to read more about the topics.

Still, what has been discussed in this article is the tip of the iceberg when it comes to what the modern and efficient development ecosystem Infragistics offers!

The Infragistics design model for their components and controls is, by far, one of the easiest, and most straightforward model to follow. For instance, when using the Ignite UI for Angular components, you get the feeling that you are using Angular built-in components and services. They’ve done an excellent job giving Angular developers a seamless experience when using their UI components.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Bilal Haidar
Author, Developer, and Mentor: Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB | A Complete Guide to VueJS
@bhaidar @bhaidar

SSR Finally a First-Class Citizen in Angular?

I am sure you've already heard about server-side rendering (SSR). Generally, it's a technique used to deliver the HTML content generated by the server to the client. The client-side JavaScript framework then hydrates that HTML content to provide a fully interactive application. SSR provides numerous benefits if used correctly, including improved initial load times, better content indexing by search engines, and improved performance on lower-tier devices. Driven by the need for faster, more efficient web applications, with the rise in popularity of Node.js and, thus, server-side JavaScript, SSR has become a de facto standard in modern web development frameworks. At first, SSR was being provided as a part of meta-frameworks like Next.js, Nuxt, or Analog.js. Then, React introduced React Server Components, which marked a significant milestone in the way we think about front-end development. We think of front-end frameworks as being effectively full-stack, and a purely SPA approach is falling out of favor. However, I'm willing to bet that if you're a developer focused mostly on Angular, you may not have heard as much about SSR as your React counterparts. For a long time, Angular has been mostly focused on the SPA approach, and while we had Angular Universal or Analog.js, it was not as widely adopted. And that makes sense, given that Angular was widely regarded as best suited for complex, interactive applications, such as SaaS products or internal company tools, where SEO and initial load times were not as critical as they are for consumer-facing applications. Nevertheless, we have been blessed with the so-called Angular Renaissance, which has, among other things, brought SSR to the forefront of Angular development with the @angular/ssr package. Let's look at what Angular SSR is, how it works, and how you can get started. @angular/ssr The @angular/ssr package is not new; it was written from scratch. It's still Angular Universal. However, it's been pulled into the Angular CLI repository, and the appropriate schematics have been added to make it easier to use. What that means is that you can now add SSR to your Angular application with a single command: ` and you can generate a new SSR application with: ` And to make SSR a first-class citizen, the Angular team is planning to make it the default in the next version. But surely, it's not only rebranding and some CLI commands, you may say. And you're right. You may remember that hydration in Angular Universal has not been optimal as it was destructive and required essentially a complete re-render of the application, thus pretty much negating the benefits of SSR. With the introduction of non-destructive hydration in Angular 16 and its stability in Angular 17, the Angular team has taken a significant step forward in making SSR a first-class citizen. How to Make an SSR-capable Angular Application Let's look at how to use Angular SSR in practice by creating a simple SSR app. First, we need to create a new Angular application with SSR support: ` That will generate a few server-specific files: - server.ts, which is an Express server configured to handle Angular SSR requests by default but can also be extended to handle API routes, or anything else that Express can handle. - src/app/app.config.server.ts provides configuration for the server application similar to your app.config.ts, which defines the configuration for your client application. Both export an instance of ApplicationConfig - src/main.server.ts bootstraps the server application in a similar way to what main.ts does for your client app by calling the bootstrapApplication function. You should have an SSR application ready just like that. You can verify that by running ng serve. The terminal output should show you information about the server bundles generated, and you should be able to see the default app when going to http://localhost:4200. Open the Developer Tools and check the console to see that hydration is enabled. You'll see a message with hydration-related stats, such as the number of components and nodes hydrated. Speaking of hydration... Client Hydration If you open the src/app/app.config.ts in your new SSR application, you'll notice one interesting provider: provideClientHydration(). This provider is crucial for enabling hydration - a process that restores the server-side rendered application on the client. Hydration improves application performance by avoiding extra work to re-create DOM nodes. Angular tries to match existing DOM elements to the application's structure at runtime and reuses DOM nodes when possible. This results in a performance improvement measured using Core Web Vitals statistics, such as reducing the Interaction To Next Paint (INP), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS). Improving these metrics also positively impacts SEO performance. Without hydration enabled, server-side rendered Angular applications will destroy and re-render the application's DOM, which may result in visible UI flicker, negatively impact Core Web Vitals like LCP, and cause layout shifts. Enabling hydration allows the existing DOM to be reused and prevents flickering. Event Replay and Improved Debugging With Angular 18, event replay, a feature that significantly enhances the SSR experience, came into developer preview. Event replay captures user interactions during the SSR phase and replays them once the application is hydrated. This ensures that user actions, such as adding items to a cart, are not lost during the hydration process, providing a seamless user experience even on slow networks. To enable event replay, you can add withEventReplay to your provideClientHydration call: ` Furthermore, Angular 18 takes another step towards making SSR a first-class citizen by enhancing the debugging experience with Angular DevTools. Now, DevTools include overlays and detailed error breakdowns, empowering developers to visualize and troubleshoot hydration issues directly in the browser. Constraints However, hydration imposes a few constraints on your application that are not present without hydration enabled. Your application must have the same generated DOM structure on both the server and the client. The hydration process expects the DOM tree to have the same structure in both environments, including whitespaces and comment nodes produced during server-side rendering. Direct DOM Manipulation The fact that server and client DOM structures must match means that components that manipulate the DOM using native DOM APIs or use innerHTML or outerHTML will encounter hydration errors. The errors are thrown because Angular is unaware of these changes and cannot resolve them during hydration. Examples include accessing the document, querying for specific elements, and injecting additional nodes using appendChild. Detaching DOM nodes and moving them to other locations will also cause errors. Direct DOM manipulation is generally considered bad practice in Angular, so I recommend refactoring your components to avoid it regardless of hydration. However, in warranted cases where refactoring is not feasible, you can use the ngSkipHydration attribute until a hydration-friendly solution can be implemented. You can use it directly in a template: ` or as a host binding: ` > Note: The ngSkipHydration attribute forces Angular to skip hydrating the entire component and its children. So use this attribute carefully, as, for example, applying it to your root application component would effectively disable hydration for the entire application. Valid HTML Structure Another constraint is that invalid HTML structures in component templates can result in DOM mismatch errors during hydration. Common issues include: - without a - inside a - inside an - inside another Again, if you have an invalid HTML, you should fix this regardless of hydration. If you are unsure about your HTML's validity, you can use the W3 validator to check it. Zoneless apps or custom Zone.js Hydration relies on a signal from Zone.js when it becomes stable. Custom or "noop" Zone.js implementations may thus disrupt the timing of this event, triggering the serialization or cleanup process too early or too late. This configuration is not yet fully supported. While Zoneless is already available in developer preview and we could assume this issue will be resolved when it lands as stable, there is no explicit ETA mentioned in the official roadmap. I18n One of the biggest blockers for adoption of client hydration was the lack of support for internationalization with hydration. By default, Angular 17 skipped hydration for components that used i18n blocks, re-rendering them from scratch. In Angular 18, however, hydration for i18n blocks got into developer preview. To enable hydration for i18n blocks, you can add withI18nSupport to your provideClientHydration call. ` Third-Party Libraries with DOM Manipulation The last thing to consider is third-party libraries that manipulate DOM, such as D3 charts. They could cause DOM mismatch errors when hydration is enabled. You can use the ngSkipHydration attribute to skip hydration for components rendered using these libraries. Conclusion The Angular team has been doing great work to make the framework more modern and competitive, hearing the community feedback and adjusting the roadmap accordingly. And SSR is an excellent example of that. With the introduction of non-destructive hydration in Angular 16 and making it stable in Angular 17, the Angular team has taken a significant step forward in making SSR a first-class citizen in Angular. The @angular/ssr package is now part of the Angular CLI, making adding SSR to your Angular application easier. The Angular team plans to make SSR the default in the next version, further solidifying its position in the Angular ecosystem. However, as with any new feature, there are some constraints and best practices to follow when using SSR with Angular. You should be aware of hydration's limitations and ensure your application is compatible with it. However, if you follow the guidelines provided by the Angular team, you should be able to take advantage of the benefits of SSR without any significant issues....

Jun 26, 2024

8 mins

AngularJavaScriptExpress.js

Overview of the New Signal APIs in Angular

Overview of the New Signal APIs in Angular Google's Minko Gechev and Jeremy Elbourn announced many exciting things at NG Conf 2024. Among them is the addition of several new signal-based APIs. They are already in developer preview, so we can play around with them. Let's dig into it, starting with signal-based inputs and the new matching outputs API. Signal Based Inputs Discussions about signal-based inputs have been taking place in the Angular community for some time now, and they are finally here. Until now, you used the @Input() decorator to define inputs. This is what you'd have to write in your component to declare an optional and a required input: ` With the new signal-based inputs, you can write much less boilerplate code. Here is how you can define the same inputs using the new syntax: ` It's not only less boilerplate, but because the values are signals, you can also use them directly in computed signals and effects. That, effectively, means you get to avoid computing combined values in ngOnChanges or using setters for your inputs to be able to compute derived values. In addition, input signals are read-only. The New Output I intentionally avoid calling them signal-based outputs because they are not. They still work the same way as the old outputs. The Angular team has just introduced a new output API that is more consistent with the latest inputs API and allows you to write less boilerplate, similar to the new input API. Here is how you would define an output until now: ` Here is how you can define the same output using the new syntax: ` The thing I like about the new output API is that sometimes it happens to me that I forget to instantiate the EventEmitter because I do this instead: ` You won't forget to instantiate the output with the new syntax because the output function does it for you. Signal Queries I am sure most readers know the @ViewChild, @ViewChildren, @ContentChild, and @ContentChildren decorators very well and have experienced the pain of triggering the infamous ExpressionChangedAfterItHasBeenCheckedError or having the values unavailable when needed. Here is a refresher on how you would use these decorators until now: ` With the new signal queries, similar to the new input API, the values are signals, and you can use them directly in computed signals and effects. You can define the same queries using the new syntax: ` Jeremy Elbourn mentioned that the new signal queries have better type inference and are more consistent with the new input and output APIs. He also showcased a brand new feature not available with the old queries. You can now define a query as required, and the Angular compiler will throw an error if the query has no result, guaranteeing that the value won't be undefined. Here is how you can define a required query: ` Model Inputs Jeremy and Minko announced the last new feature is the model inputs. The name is vague, but the feature is cool—it simplifies the definition of two-way bindings. Until now, to achieve two-way binding, you would have to define an input and an output following a given naming convention. @Input and @Output had to be defined with the same name (followed by "Change" in the case of the output). Then, you could use the template's [()] syntax. ` ` That way, you could keep the value in sync between the parent and the child component. With the new model inputs, you can define a two-way binding with a single line of code. Here is how you can define the same two-way binding using the new syntax: ` The html template stays the same: ` The model function returns a writable signal that can be updated directly. The value will be propagated back to any two-way bindings. Conclusion The new signal-based APIs are a great addition to Angular. They allow you to write less boilerplate code and make your components more reactive. The new APIs are already in developer preview, so you can start playing around with them today. I look forward to seeing how the community will adopt these new features and what other exciting things the Angular team has in store for us, such as zoneless apps by default....

Apr 3, 2024

3 mins

AngularJavaScript

Making sense of Multiple v-model Bindings in Vue 3

This article is one of a series of articles on what’s new in Vue 3. If you haven’t checked that series yet, you can do so by visiting the links below: - Take your App to the Next Level with Vue 3 - Async Components in Vue 3 - Teleporting in Vue 3 - Your first Vue 3 app using TypeScript - Vue 3 Composition API, do you really need it? In this installment, I will introduce the new v-model in Vue 3 and go through a new feature that allows you to use multiple v-model on the same component! By design, the v-model directive allows us to bind an input value to the state of an app. We use it to create a two-way data binding on the form input, textarea, and select elements. It handles updates in two opposite directions: When the input value changes, it reflects the value onto the state inside the Component. When the Component state changes, it reflects the changes onto the form input elements. The core concept of v-model remains the same in Vue 3 with more enhancements and features. Let’s dig in! Vue 2: v-model Vue 2 supports a single v-model on any given Component. In Vue 2, to build a complex Component that supports two-way data binding, it utilizes a single v-model with one full-blown payload. The Component handles the state internally for all the input elements. It generates a single payload object representing the state of the Component. Finally, it emits an event to the parent Component with the payload attached. This method had several pitfalls, especially for creating Vue UI Libraries. Of these pitfalls is the vagueness of the payload interface. It’s unclear what’s being included in the payload. A developer had to loop through the payload object in order to uncover what properties were there. Another is the need to write the logic inside the Component to handle the internal state and the generation of the payload object. Shortly, we will uncover what has been improved in this regard with Vue 3. However, before this, let’s review some basics on how Vue 2 handles implementing two-way data binding in Components. Vue 2: Two-way Data Binding As mentioned, Vue 2 uses the v-model directive to support two-way data binding on Components. Internally, it follows certain steps and rules in order to support the v-model directive. By default, the v-model directive uses different properties and emits different events for different input elements: Text and Textarea elements use the value property and the input event Checkboxes and Radio buttons use the checked property and the change event Select fields use the input property and the change event. Building a Component with a single input element will internally use something similar to the snippet below: ` The custom Component above defines a single prop named value as follows: ` Then, in the parent Component, you use the new custom Component as follows: ` The v-model directive assumes that the CustomComponent defines an internal property named value and emits a single event named input. What if the CustomComponent has to handle multiple inputs? How do we accomplish that in Vue 2? Well, there is no official solution. However, there are two methods that you can use: The CustomComponent defines a single property named value of type Object. Internally, it parses the object into data fields and does the mapping manually on the template. On every change of any of the fields, it prepares a payload for all the fields and emits a single input event, and attaches the payload. That’s a lot of code to write for such a custom component. The other option is to skip using the v-model directive and instead utilize individual input/event pairs. I will illustrate this in a moment. Assuming you have a custom Component to handle the user’s first name and last name, you would employ something similar: ` As for the properties, the Component defines the following: ` Finally, the parent Component uses the new component as follows: ` We are not using the v-model anymore and providing multiple two-way data bindings on the new component. Further your understanding by reading the official docs on Using v-model on Components Vue 3: v-model In Vue 3, the v-model directive has had an overhaul to give developers more power and flexibility when building custom components that support two-way data binding. The v-model directive now supports new defaults. The default v-model property is renamed to modelValue instead of the old name of value. The default v-model event is renamed to update:modelValue instead of the old name of input. You might be thinking that's more typing when using the new v-model directive. The Vue team are one step ahead and have given you a shorthand to use instead. Let’s rebuild the custom component using it. ` The custom component defines a single prop named modelValue as follows: ` Then, in the parent component, use the new custom component as follows: ` The new v-model directive offers the new shorthand that is used like this: ` The v-model directive assumes that the CustomComponent defines an internal property named modelValue and emits a single event named update:ModelValue. In case you don’t want to use the default naming convention, feel free to use another name. Just remember to be consistent when naming properties. Here’s an example of using a custom name for the modelValue property. ` The custom component above defines a single prop named modelValue as follows: ` Then, in the parent component, you use the new custom component like so: ` Notice the use of the property fullName instead of the default property name. Vue 3: Multiple v-model directive bindings I hope the Vue 3 shorthand form of the v-model directive has given you a "hand up". With this, the v-model gives the flexibility to use multiple v-model directives on a single component instance. The modelValue can be renamed to whatever you want, allowing you to do this! This great new feature eliminates the previous two solutions I offered up on handling complex custom components for Vue 2. Let's jump in and go through an example demonstration! Demo - Multiple v-model directive bindings Let’s build a custom Address component that can be embedded in any form to collect a user’s address. > You can play with the example live on: vue3-multiple-v-model. > You can check the source code for the example on: vue3-multiple-v-model. Figure 1 below shows the final app in action. Let’s start by building the HTML template of the new component. Figure 1 shows that all the fields used are of type input elements. Except for the last one which is a checkbox element. Therefore, it’s suffice to focus on a single input field that will eventually be replicated for the rest of fields. ` The address-line input field binds the :value directive and the @input event as per the new v-model directive specifications in Vue 3. The component defines the following property: ` The other fields follow the same structure and naming convention. Let’s look at the checkbox field and see how it’s defined: ` In the case of a checkbox field element, we bind to the :checked directive instead of the :value directive. Also, we use the @change event instead of the @input event as in the case of input field elements. The event name follows the same standard way of emitting events in the new v-model directive. The component defines the following property: ` Let’s now embed the new custom Address component into the App component: ` For each and every property on the custom component, we bind using the v-model:{property-name} format. The modelValue was replaced with the specific property names we have in hand. When there was a single input binding, the shorthand format was so much easier. However, when there are multiple input elements, the modelValue is in a league of its own! Now, let’s define the properties inside the App component using the new Composition API setup() function: ` You create a new reactive property with an object payload. Finally, you return the reactive property to the component and use it to set bindings on the custom Address component as follows: ` That’s it! Conclusion Vue 3 has many new features and improvements. Today, we saw how we use multiple v-model directives on a single component instance. There is so much more to learn and uncover in Vue 3. The coming installments of this series will continue to look at different features to help you move from Vue 2 to Vue 3. Happy Vueing!...

Nov 6, 2020

6 mins

Vue

Internationalization in Next.js with next-intl

Internationalization in Next.js with next-intl Internationalization (i18n) is essential for providing a multi-language experience for global applications. next-intl integrates well with Next.js’ App Router, handling i18n routing, locale detection, and dynamic configuration. This guide will walk you through setting up i18n in Next.js using next-intl for URL-based routing, user-specific settings, and domain-based locale routing. Getting Started First, create a Next.js app with the App Router and install next-intl: ` Next, configure next-intl in the next.config.ts file to provide a request-specific i18n configuration for Server Components: ` Without i18n Routing Setting up an app without i18n routing integration can be advantageous in scenarios where you want to provide a locale to next-intl based on user-specific settings or when your app supports only a single language. This approach offers the simplest way to begin using next-intl, as it requires no changes to your app’s structure, making it an ideal choice for straightforward implementations. ` Here’s a quick explanation of each file's role: * translations/: Stores different translations per language (e.g., en.json for English, es.json for Spanish). Organize this as needed, e.g., translations/en/common.json. * request.ts: Manages locale-based configuration scoped to each request. Setup request.ts for Request-Specific Configuration Since we will be using features from next-intl in Server Components, we need to add the following configuration in i18n/request.ts: ` Here, we define a static locale and use that to determine which translation file to import. The imported JSON data is stored in the message variable, and is returned together with the locale so that we can access them from various components in the application. Using Translation in RootLayout Inside RootLayout, we use getLocale() to retrieve the static locale and set the document language for SEO and pass translations to NextIntlClientProvider: ` Note that NextIntlClientProvider automatically inherits configuration from i18n/request.ts here, but messages must be explicitly passed. Now you can use translations and other functionality from next-intl in your components: ` In case of async components, you can use the awaitable getTranslations function instead: ` And with that, you have i18n configured and working on your application! \ Now, let’s take it a step further by introducing routing. \ With i18n Routing To set up i18n routing, we need a file structure that separates each language configuration and translation file. Below is the recommended structure: ` We updated the earlier structure to include some files that we require for routing: * routing.ts: Sets up locales, default language, and routing, shared between middleware and navigation. * middleware.ts: Handles URL rewrites and locale negotiation. * app/[locale]/: Creates dynamic routes for each locale like /en/about and /es/about. Define Routing Configuration in i18n/routing.ts The routing.ts file configures supported locales and the default locale, which is referenced by middleware.ts and other navigation functions: ` This configuration lets Next.js handle URL paths like /about, with locale management managed by next-intl. Update request.ts for Request-Specific Configuration We need to update the getRequestConfig function from the above implementation in i18n/request.ts. ` Here, request.ts ensures that each request loads the correct translation files based on the user’s locale or falls back to the default. Setup Middleware for Locale Matching The middleware.ts file matches the locale based on the request: ` Middleware handles locale matches and redirects to localized paths like /en or /es. Updating the RootLayout file Inside RootLayout, we use the locale from params (matched by middleware) instead of calling getLocale() ` The locale we get from the params was matched in the middleware.ts file and we use that here to set the document language for SEO purposes. Additionally, we used this file to pass configuration from i18n/request.ts to Client Components through NextIntlClientProvider. Note: When using the above setup with i18n routing, next-intl will currently opt into dynamic rendering when APIs like useTranslations are used in Server Components. next-intl provides a temporary API that can be used to enable static rendering. Static Rendering for i18n Routes For apps with dynamic routes, use generateStaticParams to pass all possible locale values, allowing Next.js to render at build time: ` next-intl provides an API setRequestLocale that can be used to distribute the locale that is received via params in layouts and pages for usage in all Server Components that are rendered as part of the request. You need to call this function in every layout/page that you intend to enable static rendering for since Next.js can render layouts and pages independently. ` Note: Call setRequestLocale before invoking useTranslations or getMessages or any next-intl functions. Domain Routing For domain-specific locale support, use the domains setting to map domains to locales, such as us.example.com/en or ca.example.com/fr. ` This setup allows you to serve localized content based on domains. Read more on domain routing here. Conclusion Setting up internationalization in Next.js with next-intl provides a modular way to handle URL-based routing, user-defined locales, and domain-specific configurations. Whether you need URL-based routing or a straightforward single-locale setup, next-intl adapts to fit diverse i18n needs. With these tools, your app will be ready to deliver a seamless multi-language experience to users worldwide....

Apr 11, 2025

4 mins

NextJSAccessibility

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Ignite your way with Infragistics Ultimate Developer Toolkit

Infragistics Ultimate Developer Toolkit

Web

Desktop

Mobile

Prototyping

Ignite UI for Angular

Prerequisites

Ignite UI CLI

Selection of Angular Components

Financial Chart

Data Chart

Mask

Navigation Drawer

Layout Manager

DataGrid

Excel Library

Indigo Design System

Conclusion

Bilal Haidar

You might also like

SSR Finally a First-Class Citizen in Angular?

Overview of the New Signal APIs in Angular

Making sense of Multiple v-model Bindings in Vue 3

Internationalization in Next.js with next-intl

Let's innovate together!

You might also like

SSR Finally a First-Class Citizen in Angular?

Overview of the New Signal APIs in Angular

Making sense of Multiple v-model Bindings in Vue 3

Internationalization in Next.js with next-intl