How does a millennial project manager successfully manage UX projects composed of team members and clients from older generations, sometimes even older than his parents?!! Justin Fraser will describe his experience as a young project manager, and how he successfully worked with people from other generations, in his UXify presentation, “The Next Generation of Project Management: Getting Results without Formal Authority.” 

UXify 2018: The Future of User Experience, our sixth annual, free UX conference, takes place on Friday, April 27 from 11 am – 5:30 pm, with networking from 5:30 - 7:00 pm. Lunch, snacks, and beer and wine during the networking are included. 

Check out the UXify 2018 agenda and speaker list, and register for FREE.

The Next Generation of Project Management: Getting Results without Formal Authority
By Justin Fraser, Senior Project Manager at Infragistics 

This session will provide real-life solutions for Millennials to connect with and successfully manage team members of different generations, some of whom may have been in their roles since before the Millennial was born. The talk will include actionable, appropriate responses for challenges Millennials in management positions may face, including building productive relationships with senior team members, dealing with insecurities, gaining authority, and resolving conflicts. 

The speaker, while in college at age 20, was an Associate Project Manager on a Client Services team responsible for managing internal staff and clients who were older than his parents. This talk will cover his real-life experiences, both positive and negative. He’ll discuss how he gained the team’s trust and respect to have the authority to manage projects the way a Senior Project Manager would.  

Justin Fraser
Justin has been managing User Experience Design and Development Projects for more than 9 years and has been at Infragistics for 5 years. He holds the PMP certification from the Project Management Institute and was a speaker at their PMI Global Congress. He has experience working with clients of all sizes, located around the globe; managing the design and development of business applications of various size and scope for financial, healthcare, pharmaceutical, and technology companies. 

Register for UXify

At UXify 2018, George Abraham will provide practical advice on how to avoid wasting time and effort in prototyping, by focusing on gathering meaningful user insights quickly, using the cheapest means possible, rather than trying to impress stakeholders with beautiful designs and animated transitions too early in the design process. 

UXify 2018: The Future of User Experience, our sixth annual, free UX conference, takes place on Friday, April 27 from 11 am – 5:30 pm, with networking from 5:30 - 7:00 pm. Lunch, snacks, and beer and wine during the networking are included. 

Check out the UXify 2018 agenda and speaker list, and register for FREE.

Detoxifying Your Prototyping Process for Better Results
By George Abraham, Senior Product Owner and Design Principal at Infragistics

The popularity of UX has generated a flurry of how-to blogs, UI kits, and new jargon. What has not changed, but obscured, is the fundamental practice of research - design - learn. If research represents problem-synthesis (what and why), prototyping is about solution-synthesis (how). 

We, however, seem focused on impressing other designers or stakeholders, with beautiful pixels and animated transitions, more than empowering people who will use what we create. And this happens at the cost of gathering meaningful insights quickly using the cheapest means possible. All our design work is moot if we don’t engage with those who are affected by this design. This is where learning happens, and how we converge on the right UX. 

In this presentation, I will share guidelines to reduce waste in prototyping by making the best use of research, managing fidelity, and making trade-offs for remote unmoderated usability testing. I will be using Indigo Studio, a prototyping solution by Infragistics Inc., to illustrate the process of design and evaluation. However, the ideas discussed are generalizable.

George Abraham
George Abraham is a Sr. product owner and design principal at Infragistics Inc. He is a prototyping maven who believes that design is the art and science of discovering the right trade-offs. He splits his time between delighting customers and figuring out what they will pay for. George also holds a Ph.D. from Drexel University’s College of Computing & Informatics.

Register for UXify

At the sixth annual and international UXify conferences held on April 27th, over 300 participants from various agencies, in-house workers, and freelancers, joined the events in the United States, Bulgaria, and Japan.  The conferences were successfully built to discuss the best UX practices and to consider forward-thinking concepts based on the drives of the international community. With the focus of this year's UXify centered on the "The Future of User Experience", the speaker list was inundated with professionals from all over the UX industry, supporting a meld of innovative discussion and thought-leadership throughout the days.  

The United States conference officially began with Dean Guida emphasizing that Infragistics is centered around its "passion for user experience." As the CEO and founder of the company, Dean has built Infragistics to be ultimately client-focused with its tooling and products for the web, desktop, and mobile environments. By bringing together like-minded professionals to collaborate and network, this passion was brought to a forefront for those involved at the cutting edge of the UX design community. 

Each location featured its own set of highlights and exciting speakers: 

UXify Bulgaria 

In Sofia, Bulgaria, the participants were fully engaged and energized while hearing riveting case studies which were focused on emotional and meaningful design. 

George Abraham's keynote speech, "Detoxifying Your Prototyping Process for Better Results", intrigued the audience and instilled confidence in those looking to play a larger role in the design processes of their companies.  

In other prominent talks, George Angeloff, a design leader for the popular IDIT Web based in Bulgaria, spoke about the revolution surrounding emotional design and how to design meaningful UI. This segued nicely into Svetoslav Simov's discussion around fonts and new technologies. Simov, as an owner of one of the world's most popular type foundries, Fontfabric, spoke about the history and future of fonts and typography.   

UXify Japan 

In Tokyo, Japan, the primary focus of the day rested on best practices for UX design and ways to boost functionality.   

The keynote speaker, Yoshihiro Saito, lead the audience through his take on the resonations of UX design within the mind and ways to best approach standard practices. With other talks from Nakagawa Tomoko and Fukuoka Say, the day moved into topics of expanding design services to fit user experiences for various positions and ways to design UX processes around purpose and context.  

UXify US  

In Cranbury, New Jersey, the talks centered on forward-thinking design strategies and the future implementation of design with the inclusion of AI and virtual reality. 

Featured speakers, like Darian O’Reilly, David Fisher, Lisa Lokshina and Kristine Malden, took to the floor with attention-grabbing thought-leadership. Darian started the event with useful ways to include clients in the design process to produce valuable project contributions and elegant final products. From there, David, Lisa, and Kristine all discussed the fascinating journey that UX design will now be taking as AI and VR come to the stage, encouraging designers to adapt to these transformational technologies as work moves forward. 

Overall, the events struck a chord with the design community, as a myriad of relevant, productive discussions stemmed from just under thirty talks spanning the globe. Moving forward, you’re encouraged to stay in touch with the design community and Infragistics, so please feel free to follow us on Twitter for the latest updates. Furthermore, you should check out Indigo Studio, our complete solution for collaborative prototyping and usability testing. It’s a code-free way to design for today’s most popular platforms for web, desktop, and mobile.  

If you don’t know what they are, how to use them, why they are useful, or what they even do, pivot tables can become scary and complex. You’ll soon find that a pivot table is a great way to quickly summarize, analyze, explore, and present your data.

ReportPlus, built by user experience experts, makes pivoting your data easy with an intuitive drag and drop experience. The pivot table is broken out into four sections: Values, Rows, Columns and Filters:

You will see that as you start dragging fields into a corresponding section that the data being displayed will instantly update. 

Values

This location is where you will drop your value field upon which you want your visualization to be built. By default, the field that you place in the values section will be summarized as a sum. If your field is a text field, ReportPlus will detect this and display your data as count.

You can see here that, by dragging Sales over to my values section, ReportPlus summarized my data:

If a value is all you wish to display, you can display your value in the form of a gauge. By clicking on the sales field, I am prompted with options to customize the value by changing the aggregation, formatting, sorting and filtering. You have these options and more in any field that you bring over.

Rows

This section is where you would drop the field that you want to correspond to the x-axes of your visualization. So, if I change my visualization to a column chart and drag a date field over to rows, you will see sales by month.

Columns

Regarding the columns section, here are the fields that you would have appear in your chart legend or the columns of a table, etc.

Filters

The filters section allows you to filter and slice your data based on a certain field. So, if I wanted to see sales by month per product, but I only wanted to see the deal types that were subscriptions, I would pull deal type over to the filters section. Then, I can click on the field to select which value(s) I want to filter by:  

To see how you can easily pivot your data in action with R+, check out this video. If you like the ease and functionality behind these pivot tables, consider taking a closer look at ReportPlus. It’s our answer to true self-service BI, allowing you to better visualize and understand your significant data for faster decision-making.

With throngs of people chattering and rampant idea-sharing in the air, Microsoft's 2018 Build conference represented the sheer eagerness attendees had regarding the futurology of tech. The Washington State Convention Center packed upwards of 7,000 attendees, ensuring that lectures and sessions would be busy, full of learning, and conversant. With Satya Nadella, the CEO of Microsoft, dominating the keynote speech, the giant crowd was witness to the overarching ideas behind the conference: responsibility in computer-learning, the advent of Visual Studio Code Live, the hallmarks of Azure, and the cutting-edge opportunities we have torevolutionize work through mixed reality. As Nadella noted, "The world is becoming a computer," and he's right. 

So, What Did We See? 

Between the Expo Hall and the sessions dotting the building's landscape, major players in the industry were showcasing their newest wares and ideas. From GitHub to LinkedIn and from Docker to Citrix, there was information abound for attendees to access. With sessions held about Kubernetes, Azure, Visual Studio Code Live, machine-learning, Microsoft Graph, the HoloLens, and more, Build aimed to commandin the area of thought-leadership.  

At the Infragistics booth found near the Client & Web area, we spent three successful days demoing portions of our new Infragisitcs Ultimate 18.1 release. While showing off our updates to the fastest Angular data grid, financial charts, and improved spreadsheet functions, booth attendees were able to join in on our #PinItToWinIt campaign at the Expo and on Twitter. The campaign encouraged attendees to affix the Infragistics pin, and this put them in the running to earn one of our twenty giveaway sweatshirts or our large prize, Beats headphones.  

How Were the Conversations? 

The team found themselves having lengthy discussions about our high-speed Angular data grid features, showcasing the smooth rendering of large-scale data sets and the financial charting capabilities. With a healthy mix of current and new customers arriving to talk, excitement rested primarily on the power of our material-based Angular components. When not discussing Angular, many also came to explore and learn about our WPF and Windows Forms features, particularly for our work with the Excel engine updates. There was also a strong showing of those interested in our enterprise management products, with ReportPlus Embedded dominating the space due to its easy data visuals and cross-platforming.  

Where are We Going from Here? 

Moving forward for 2018, Infragistics is going to set its eyes on the area of rapid application development, promoting WYSIWYG and UI kits for web and mobile app building and delivering a design-to-code workflow across Indigo Studio and Ignite UI. From this design-to-code workflow, we'll have code generation for Flutter and Angular, adding to our innovative features surrounding our Angular grid and charts components.  

Excited to Learn More? 

We have an extensive list of products that make web, desktop, and mobile application development far easier and more streamlined. Since we've spoken so much about Angular recently, be sure to take a look at ourIgnite UI for Angular and the Ignite UI for Angular CLI and get to working with the fastest Angular data grid. On top of that, consider making your way to our popular enterprise management tool, ReportPlus Embedded. It enables businesses to create rich, beautiful data visualizations to accelerate ROI and to bring BI to life. Plus, if you're interested in a large-scale solution, learn about ourUltimate developer's toolkit which gives you a single platform for UX design and enterprise application development.

Part 2: The Anatomy of an Angular Spec File

By: Jared Fineman

The more things change, the more they stay the same; this adage definitely applies to unit testing. Although we’ve advanced greatly in the world of software development, the fundamentals remain the same. Certain things like AAA, Arrange, Act and Assert will always apply, however, we must learn how to think of them within the world of Angular.

In the previous article, we discussed setting up the infrastructure needed in an Angular Unit Testing Module. So for this article, I’d like to focus on the components that make up your typical Angular Spec File and provide the implementation of the age old concepts of AAA.

In the Arrange portion of our unit test, Angular, leveraging the Jasmine unit testing library, will first describe the component we wish to test by utilizing the describe function, as illustrated below. It’s important to utilize a descriptive name, as this will make reading the results from your unit tests a lot easier.

describe('AppComponent', () => {

Moving on to the Arrange section of our file spec, we utilize the beforeEach function to initialize any configurations that will be needed across all the unit tests in the file. Unique to Angular, however, is the TestBed class, which provides the essential ingredients needed for simulating the construction and initiation of our Angular Module.

beforeEach(async(() => {
    TestBed.configureTestingModule({
      declarations: [
        AppComponent,
      ],
      imports: [RouterTestingModule],
      providers: [
],
    }).compileComponents();
  }));

 If you’ll notice, we are using the configureTestingModule method of the TestBed class to initialize our configurations. If we look at the source code, the TestBed class provides additional methods for testing that can be very useful.

    static compileComponents(): Promise<any>;
    static overrideComponent(component: Type<any>, override: MetadataOverride<Component>): typeof TestBed;
    static overrideTemplate(component: Type<any>, template: string): typeof TestBed;

As their names imply, the above methods can be used to override functionality contained within your module. This may be useful in a case where you want to provide mock data to your component, but your component is coupled with a particular provider; overrideComponent would then give the ability to pass in a fake provider service to inject the mock data.

Some additional things to take note of in the previous code snippet are the RouterTestingModule and the compileComponents function. The RouterTestingModule can be used as a substitute for the usual RouterModule and simulates route navigation without having to actually change url locations. In addition, the RouterTestingModule has a method, withRoutes, that accepts a parameter value of fake routes, which can be useful in various testing scenarios. The compileComponents function is necessary when running your unit tests with a library other than angular-cli. When using angular-cli, however, your unit test code is compiled automatically during the initialization stage.

The Act section of unit testing is where we actually setup our individual unit tests and should look similar to the code below:

  it('should render title in a h1 tag', async(() => {
    const fixture = TestBed.createComponent(AppComponent);
    fixture.detectChanges();
    const compiled = fixture.debugElement.nativeElement;

The createComponentmethod is responsible for creating a copy of the root of our component and returns an object of type ComponentFixture. The fixture of an Angular Unit Test is crucial in that it helps manage and simulate the component’s life cycle. By calling the detectChanges method, the component will detect changes in its environment and bind all of its properties. Keep in mind that our unit tests exist outside the domain of the Angular component lifecycle, therefore, in order for any change to be detected we must first call the detectChanges method.

A closer look at the ComponentFixture class reveals a property of type DebugElement.

export declare class DebugElement extends DebugNode {
    properties: {
        [key: string]: any;
    };
    attributes: {
        [key: string]: string | null;
    };
    classes: {
        [key: string]: boolean;
    };
    styles: {
        [key: string]: string | null;
    };
    nativeElement: any;
    query(predicate: Predicate<DebugElement>): DebugElement;
    queryAll(predicate: Predicate<DebugElement>): DebugElement[];
    triggerEventHandler(eventName: string, eventObj: any): void;

First to notice is that the DebugElement class contains properties such as, properties, attributes, classes, styles that help streamline our unit tests by giving us a wealth of information about our component at our fingertips. The next step is the triggerEventHandler, this method is crucial for simulating DOM events that will be picked up by our component’s event listeners. Last, but not least, is the query method, by far my favorite.

Similar to jQuery, the query method is able to able to search through the DOM and return matching elements. The main difference, and advantage, in its functionality is that the return value is not merely a collection of DOM elements, but of DebugElement objects, making it easier to test nested components. In addition, the query method accepts a parameter of type Predicate<DebugElement>, meaning we can query the DOM using any of the properties found in the DebugElement class.

If that weren’t enough, Angular has provided a class called By, which has further methods to ease the construction of Predicate objects for use in our queries. Below is an illustration, taken from the Angular testing guide, of some examples of this class:

const h2        = fixture.debugElement.query(By.css('h2'));

const directive = fixture.debugElement.query(By.directive(HighlightDirective));

Finally, the last step of AAA, Assert, should look similar to the below:

expect(app.title).toEqual('app');

This is very similar to a typical Jasmine unit test, except we see the power of the Angular unit testing library, as we are directly accessing the title property of the component.

If you like this post, please like it and share it. In addition, if you haven’t checked out Infragistics Ignite UI for Angular, be sure to do so! They’ve got 50+ material-based Angular components to help you code speedy web apps faster.

Pyramid charts are very popular visualizations when working with demographics as they are an easy way to show the age and male/female composition of a given country. While line charts are very common when describing the growth scale of any population, pyramids are preferred as they are ideal to detect any changes or significant differences.

What are Stacked Charts?

Stacked charts are basically bar, area, or column charts that do not overlap because they are placed on top of each other. Stacked bars, for example, present information in a horizontal comparison and are meant to help users visualize how each piece of data correlates to the whole data set.

ReportPlus steps up to the plate by adding a new feature for users: the ability to present stacked charts with a percentage distribution instead of the default 0-100 scale.

Why not use a Bar Chart instead?

In the case above, where what’s being compared is a set of aging ranges, bar charts would only be helpful when representing data by year. Take a look at the data below: the first one is a bar chart plotted by year, and the second one is the equivalent to the stacked chart above.

If you really need to see your data broken down by the exact dates, bar charts just aren’t the correct fit.

How this relates to Population Pyramids

Population pyramids usually display not one data series, but two: age and female/male ratio. You’ll therefore need to use a chart that supports two or more series.

Sample Population Data

Let us consider the following figures to create the visualization in the screenshot above. These include the age ranges for Seattle inhabitants along with the male/female population ratio.

When we create the widget in ReportPlus and choose the Stacked Bar visualization, the data will be plotted in the following way:

In order to create a pyramid, we’ll need the values for male and female to point in two different directions. Therefore, let’s create a calculated field that displays the opposite of the male population:

Then, hide your original “Male” field by toggling the “Is Visible” slider.

Your visualization will now look like the following one:

Formatting your Data

If you want or need, you can format the negative values in a different way by changing the “Negative number format”.

If you want the pyramid to show the values from highest to lowest, change one of the genders’ Sorting to “Asc”:

By default, the theme will be set to “The Blues”. Change your theme to any of ReportPlus’ more than 20 themes if you want to have more contrast between the figures.

Interested in trying this out?

Download a free trial of ReportPlus Desktop or ReportPlus iOS now, or contact us to get this ready for you!

Interacting with Forms

By: Jared Fineman

When we think of forms, we may have visions of a stack of papers, piled on a waiting room table in a doctor’s office. However distant web forms may be from that concept, in terms of tediousness, a lot remains the same. Whether it be laying them out, styling them, or simply binding them, forms can be a chore in their own unique way and nothing changes when it comes to unit testing. Thankfully, by leveraging the Angular Unit Testing Library, we can streamline the process.

Let’s start by examining a unit test for the completion of a form:

it('should activate done button when complete’, async(() => {
  const fixture = TestBed.createComponent(LocationOptionsComponent);

  fixture.detectChanges(false);

  let inputs = fixture.debugElement
.queryAll(By.css('input.form-ontrol:not(.filter-input)'));

  let combos = fixture.debugElement.queryAll(By.directive(TypeaheadComponent));
        
  let doneBtn = fixture.debugElement
.queryAll(By.css('.star-grid-header-buttoncontainer input'))[1];

  ...

As we can see from the description of the unit test, the done button should only become active after the form is in a state of completion. We begin by querying the created component in order to find the form and all of its elements.

One thing to note is the power of the queryAll method of the Angular library; it is able to use a complex css selector to return a collection of DebugElement objects that represent the inputs of the form. Alternatively, the queryAll method can be passed a value type of directive or component as a parameter and it will return all corresponding matches. For more information about the query method, please see my previous article titled, "Demystifying Angular Unit Tests: Part 2: The Anatomy of an Angular Spec File".

At this point in the unit test, we have a collection of all the various inputs, some simple and others more complex, like drop-down menus or autocomplete fields. The challenge here is being able to simulate interactions with each component properly in order to test the various form dynamics. The following sections will illustrate how we locate and interact with each particular field, using the Angular library:

 optionNameInput.nativeElement['value'] = 'Testing';
 optionNameInput.nativeElement.dispatchEvent(new Event('input'));

We begin by examining a variable named optionNameInput in order to gain a better understanding behind some of the key concepts in unit testing forms. The optionNameInput, as well as the other field variables, are all of type DebugElement, a powerful class for unit testing. This class has a property called nativeElement, by which we can directly access and manipulate the field value in the DOM. This is insufficient, however, to activate Angular’s event detection. In order to do that, we will need to simulate an input event using the dispatchEvent method; doing so will then trigger data binding, validation, as well as any event listeners.

We have just successfully simulated an input event for our unit test, but how would we handle something more complex like selecting an option from a drop-down menu or an autocomplete field?

optionTypeInput.nativeElement.dispatchEvent(new Event('input'));
 activeInput.nativeElement.dispatchEvent(new Event('input'));

Similar to the input field, our autocomplete variables, optionTypeCombo and activeCombo, require an event to be fired in order to activate change detection, and in turn, expand the option menu. We handle this by first calling the dispatchEvent method, followed by a strange call to a method called whenStable.

fixture.whenStable().then(() => { ... }

As described in the Angular site documentation, whenStable is responsible for returning a promise after the completion of an asynchronous event. In order for us to catch the event of the autocomplete menu opening, we need to nest the continuation of our code within the returned promise of the whenStable call.

let locationOption = optionTypeCombo.query(By.css('button')).nativeElement;
    locationOption.dispatchEvent(new Event('click'));

let activeOption = activeCombo.query(By.css('button')).nativeElement;
    activeOption.dispatchEvent(new Event('click'));

Now that it has open, we are ready to make a selection from the autocomplete menu. Using the query method of the DebugElement object, we are able to find the first autocomplete field option, represented by a button element. Once again, we call the dispatchEvent method, but this time passing in a click event, to simulate selecting the first option.

fixture.detectChanges();

 expect(doneBtn.properties['disabled']).toBe(false);

After a quick call to detectChanges, which starts the Angular detection process, we are ready to check if the form is in a complete state, our primary indicator being an active done button. We have already queried and saved the done button as a variable of type DebugElement; using its properties value, we can now detect the disabled status of our button.

If you like this post, please like it and share it. In addition, if you haven’t checked out Infragistics Ignite UI for Angular, be sure to do so! They’ve got 50+ Material-based Angular components to help you code speedy web apps faster.

Change Detection means updating the DOM whenever data is changed. Angular provides two strategies for Change Detection.

1. Default strategy
2. onPush strategy

In default strategy, whenever any data is mutated or changed, Angular will run change detector to update the DOM. In onPush strategy, Angular will only run change detector only when new reference is passed to @Input() data.

To update the DOM with updated data, Angular provides its own change detector to each component, which is responsible to detect change and update the DOM. 

 Let us say we have a MessageComponent as listed below:

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

@Component({
  selector: 'app-message',
  template: `
    <h2>
    Hey {{person.firstname}} {{person.lastname}} ! 
    </h2>
    `
})
export class MessageComponent {

  @Input() person;
}

In addition, we are using MessageComponent inside AppComponent as below,

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

@Component({
    selector: 'app-root',
    template: `
  <app-message [person]='p'></app-message>
  <button (click)='changeName()'>Change Name</button>
  `
})
export class AppComponent implements OnInit {
    p: any;
    ngOnInit(): void {
        this.p = {
            firstname: 'Brad',
            lastname: 'Cooper'        };
    }
}

Let us talk through the code: all we are doing is using MessageComponent as child inside AppComponent and setting value of person using the property binding. At this point on running the application, you will get name printed as output.

Next, let us go ahead and update firstname property on the button click in AppComponent class below:

changeName() {
  
    this.p.firstname = 'Foo';
}

As soon as we changed the property of mutable object P, Angular fires the change detector to make sure that the DOM (or view) is in sync with the model (in this case object p). For each property changes, Angular change detector will traverse the component tree and update the DOM.

Let us start with understanding about component tree. An Angular application can be seen as a component tree. It starts with a root component and then go through to child components. In Angular, data flows from top to bottom in the component tree.

Whenever @Input type property will be changed, Angular change detector will start form the root component and traverse all child components to update the DOM. Any changes in primitive type’s property will cause Angular change detection to detect the change and update the DOM.

In above code snippet, you will find that on click of the button, the first name in the model will be changed. Then, change detection will be fired to traverse from root to bottom to update the view in MessageComponent.

There could be various reasons of Angular change detector to come into action and start traversing the component tree. They are:

1. Events fired such as button click, etc.
2. AJAX call or XHR requests
3. Use of JavaScript timer functions such as setTimeOut , SetInterval

Now, as you see,  a single property change can cause change detector to traverse through the whole component tree. Traversing and change detection is a heavy process, which may cause performance degradation of application. Imagine that there are thousands of components in the tree and mutation of any data property can cause change detector to traverse all thousand components to update the DOM. To avoid this, there could be scenario when you may want to instruct Angular that when change detector should run for a component and its subtree, you can instruct a component’s change detector to run only when object references changes instead of mutation of any property by choosing onPushChangeDetection strategy.

 You may wish to instruct Angular to run change detection on components and their sub-tree only when new references are passed to them versus when data is simply mutated by setting change detection strategy to onPush.

Let us go back to our example where we are passing object to MessageComponent. In the last example, we just changed firstname property and that causes change detector to run and to update the view of MessageComponent. However, now we want change detector to only run when reference of passed object is changed instead of just a property value. To do that let us modify MessageComponent to use OnPush ChangeDetection strategy. To do this set changeDetection property of @Component decorator to ChangeDetectionStrategy.OnPush as shown in listing below:

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

@Component({
    selector: 'app-message',
    changeDetection: ChangeDetectionStrategy.OnPush,
    template: `
    <h2>
    Hey {{person.firstname}} {{person.lastname}} !
    </h2>
    `
})
export class MessageComponent {

    @Input() person;
}

At this point when you run the application, on click event of the button in AppComponent change detector will not run for MessageComponent, as only a property is being changed and reference is not changing. Since change detection strategy is set to onPush, now change detector will only run when reference of @Input property is changed.

changeName() {
  
    this.p = {
        firstname: 'Foo',
        lastname: 'Kooper'    };
}

In the above code snippet, we are changing reference of object instead of just mutating just one property. Now when you run application, you will find on the click of the button that the DOM is being updated with new value.

By using onPush Change Detection, Angular will only check the tree if the reference passed to the component is changed instead of some property changed in the object. We can summarize that, and Use Immutable Object with onPush Change Detection to improve performance and run the change detector for component tree when object reference is changed.

 We can further improve performance by using RxJS Observables because they emit new values without changing the reference of the object. We can subscribe to the observable for new value and then manually run ChangeDetector.

 Let us modify AppComponent to pass an observable to MessageComponent.

import { Component, OnInit } from '@angular/core';
import { BehaviorSubject } from 'rxjs/BehaviorSubject';
@Component({
    selector: 'app-root',
    template: `
  <app-message [person]='data'></app-message>
  <button (click)='changeName()'>Change Name</button>
  `
})
export class AppComponent implements OnInit {
    p: any;
    data: any;
    ngOnInit(): void {
        this.p = {
            firstname: 'Brad',
            lastname: 'Cooper'        };
        this.data = new BehaviorSubject(this.p);
    }

    changeName() {

        this.p = {
            firstname: 'Foo',
            lastname: 'Kooper'        };
        this.data.next(this.p);
    }
}

In the code, we are using BehaviorSubject to emit next value as an observable to the MessageComponent. We have imported BehaviorSubject from RxJS and wrapped object p inside it to create an observable. On the click event of the button, it’s fetching the next value in observable stream and passing to MessageComponent.

 In the MessageComponent, we have to subscribe to the person to read the data.

@Input() person: Observable<any>;
_data;

ngOnInit(){
    
    this.person.subscribe(data => {
        this._data = data;

    });
}

Now, on click of the button, a new value is being created, however, a new reference is not being created as object is an observable object.  Since a new reference is not created, due to onPush ChangeStrategy, Angular is not doing change detection. In this scenario, to update the DOM with new value of observable, we have to manually call the change detector as shown below:

export class MessageComponent implements OnInit {

    @Input() person: Observable<any>;
    _data;

    constructor(private cd: ChangeDetectorRef) { }
    ngOnInit() {

        this.person.subscribe(data => {
            this._data = data;
            this.cd.markForCheck();
        });
    }
}

We have imported ChangeDetectorRef service and injected it, and then calling markForCheck() manually to cause change detector to run each time observable emits a new value.  Now when you run application, and click on button, observable will emit new value and change detector will update the DOM also, even though a new reference is not getting created.

To summarize:

1. If Angular ChangeDetector is set to default then for any change in any model property, Angular will run change detection traversing component tree to update the DOM.
2. If Angular ChangeDetetor is set to onPush then Angular will run change detector only when new reference is being passed to the component.
3. If observable is passed to the onPush change detector strategy enabled component then Angular ChangeDetctor has to be called manually to update the DOM.

 I hope you find this post useful. Thanks for reading.  If you like this post, please share it. Also, if you have not checked out Infragistics Ignite UI for Angular Components, be sure to do so! They have 30+ material based Angular components to help you code web apps faster.

I am excited to announce the first event in Korea and we invite developers in Korea!

Jason Beres, Sr. VP of Developer Tools and Satoru Yamaguchi, Solution Consultant will be visiting Seoul and they are going to introduce our latest products and provide free hands-on sessions for developers who are interested in building Modern Desktop and Web Applications using WPF and Angular.

Event Overview:

Contact: BluePort (02-569-3712 / sales@blueport.co.kr)

* English to Korean translation is provided

You can find detailed schedule and agenda here (Korean).

Registration:

There are two sessions on the day. Please pick one of them or both to sign up.

Morning Session - Angular

Afternoon Session - WPF

We are looking forward to seeing you all in Korea!

While one might reasonably argue that sales is the lifeblood of any organization (especially if you’re responsible for reporting on P&L), customer engagement is, at a minimum, a major contributing factor. What should a business do then, when it is interested in creating or improving the level of engagement between their customers and themselves?

Traditional Problem

When the primary “product” consists of services, businesses create applications that they believe will meet the needs of their users. With the best of intentions, meetings are held, decisions are made, requirements are gathered, and code is written. To much internal fanfare, the application is released, and confident product owners wait anxiously, hoping for large scale engagement. To ensure customers are aware of the application’s existence, marketing talent is brought to bear - mail is sent out, press releases published, conferences attended, and t-shirts given away.

Traditional Result

What tends to happen next is all too common. The application, which met the needs of the business, and seemed like it should have met the needs of customers, didn’t. For some reason, users were uninterested, downloads dropped to the point that reporting on them became awkward, and eventually, the application stopped being supported and faded away. Why did this happen?

User Experience Solution

Contrary to what might seem the obvious solution, the key to driving large scale engagement is not creating a method by which users tell the business what they want. While this might be sufficient to drive incremental improvement, users are only able to articulate their obvious needs: “I want access to my services,” “I want to be able to pay my bill,” “Make it easy for me to see my coverage details.” These are all fine and obvious bits of functionality that users believe they want, but there is another set of requirements – latent requirements – that define features and functionality that will improve users’ lives in ways they cannot describe or request.

User Experience Research

The next question is, since users aren’t able to articulate their latent requirements, how do we know they exist? Assuming they exist, how can we hope to define them? The answer to both questions is User Experience Research. By employing on-site observations (a technique known as shadowing) and intelligent interviewing (a technique known as contextual inquiries), an experienced UX team is able to identify key user groups, define existing workflows, task frequency, significant bottlenecks and problem areas, device usage, etc., essentially inferring users’ latent requirements. Based on this understanding, they can coordinate this information into a unified set of stated and latent requirements, completely defining the problem areas within a user’s professional environment. This coordinated set of requirements defines the space within which users are willing to engage with the business. The level of engagement, therefore, is limited only to the degree that the solution resolves users’ problems.

User Experience Process & Deliverables

I’ve made some gross assumptions to show what such a research project might look like for a B:B application, such as an insurance application designed for medical professionals. Please keep in mind that any or all of these can be modified, and need not happen sequentially, depending on circumstances and business needs.

Small Office Research (3 people)

• UX team onsite for 2 days
• One day to coordinate findings

Medium Office Research (10 people)

• UX team onsite for 4 days
• Two days to coordinate findings

 Large Office Research (10+ people)

• UX team onsite for 8 days
• Three days to coordinate findings

 Deliverables

• User Profiles/Personas
• Workflows/Journey Maps
• Informational Needs by User Type
• Frequency of Use Metrics
• Recommended Application Formats (web, mobile web, native web)
• Application Wireframes
• Full Aesthetic Designs
• Front-End Development

The UX process is almost infinitely malleable. Ultimately, it comes down to understanding the risks associated with how you spend your research dollars, the experience of your UX team, and the relationship between time, money, and representative sample size. Customer engagement is about proactively understanding what customers need and how to make it available at the right time, in the most useful format, not about reactively working through a list of feature requests.

Design at Infragistics

Here at Infragistics Consulting, we pride ourselves on delivering thoughtful and useful design. Getting the job done isn't the same as getting the job done well and we sweat the small stuff because it matters. Let us show you how we can help by contacting us at services@infragistics.com.

With all of the recent exciting changes in Angular v6’s release and the large shift in both the enterprise and SMB market towards adopting Angular as the go-to framework for building business applications, Infragistics is making sure to stay on the cutting edge of web development. Speaking to the ripple effect Angular has had in modern web development, our Angular team has been vocal about their plans to give web developers accessibility and ease when working with Angular on their upcoming projects. By providing tools for the upcoming wave of developers moving to building line of business applications in Angular, we’re making sure that we deliver best of breed UI components and the fastest Angular data grid with our products, Ignite UI for Angular and Ignite UI CLI.

Recently, we’ve been working on adding another product to our Angular productivity line, Indigo Design to Code Studio. Announced at Google I/O, Indigo D2C Studio is a digital product design platform that brings developers and designers together to build amazing user experiences. For example, once the iterative design process is complete, developers can use the Indigo D2C Studio Visual Studio Code plug-in and UI components to create a pixel-perfect Angular or Flutter application for Android and iOS. The product is highlighting Infragistics’ goal in working closely with Google’s Angular team to develop forward-thinking tools for web, desktop, and mobile applications, so be sure to read the latest press release and sign up for the upcoming preview.

As it follows, the team has been eager to share their goals and progress with the community, notably sitting down with JAXenter, the international technology website and news platform. In the interview and subsequent article, Infragistics' Radoslav Karaivanov, Sr. Software Developer, and Konstantin Dinev, Manager of Product Development, highlighted that they'll continue to work with each Angular release, as Konstantin notes, "Our goal is to be lock-step with the Angular releases from Google – our customers move quickly to take advantage of new Angular features, and they expect Infragistics products to ‘just work’ when their teams start new app dev in the latest version of Angular"

So, what’s new about Angular 6 and why is our dev team so excited?

Angular v6 has a laundry list of exciting new features that make building Angular apps easier and continues to drive the message that Angular is ‘enterprise-ready’.  When discussing the updates, Radoslav offered that, “The new features are compelling; Angular Elements could really increase the usage of the framework, even just to transform parts of legacy web apps into web components.”

On top of that, Radoslav also couldn’t ignore the sheer appeal and support that’s offered with a framework developed by Google. He had chuckled as he said, “At least you know you won’t be out in the wild,” given that Angular is providing a full package of the framework from one of the leading tech companies in the world.

Even aside from the fervor around support and Elements, let’s go through a brief rundown what’s caught developers’ eyes with the latest release:

• Synchronization of all major versions for the framework packages, the CLI, and the Material/ CDK to help with cross compatibility.
• Two new CLI commands, ng update and ng add. With ng update, your package.json will be analyzed and recommendations for dependency updates will be given. It’ll help you keep your dependencies in sync and up-to-date, plus allowing for third parties to develop update scripts called “schematics” that will auto-update your code when that third party needs to make some breaking changes. For ng add, you’ll see that it uses your package manager of choice to download and install new dependencies that can update a project with polyfills, configuration changes, or scaffold package-specific initialization code.
• The introduction of Angular Elements to convert custom elements into web components that can be reused.
• The new tree component for displaying hierarchal data.
• CLI workspaces that can contain multiple projects, like libraries and applications.
• The addition of ng generate library to support the creation and building of libraries in the CLI.
• Dependency Injection to bundle services into modules, so that applications are smaller.
• The promise of long term support for all major releases starting with v4.

So, with these new features, our Angular team is looking forward to further optimizing Ignite UI for Angular, boosting the 50+ Material-based components and the fastest Angular Data Grid for peak performance.

Let’s look at the team’s most talked about features and expand on some of the details.

Architecture Overview

Angular Elements:

When talking with the team about Elements, it was met with much excitement as to where Elements could take developers as Angular grows. Radoslav aptly noted that, “…reusability is there but, more importantly, interchangeability is king.”

Elements offer reusability and interchangeability by allowing developers to quickly publish their Angular components as framework-agnostic web components, without worrying about bootstrapping and modules. Using the Elements package, it allows for a developer to take the created component and register this now custom Element with the browser using the custom Elements API. The resulting Element can now be placed anywhere on a browser page without being connected to the DOM element, since its already been done using the browser APIs. With it now functioning as a standard DOM element, it can be adjusted with attributes and properties, now allowing a developer already familiar with HTML and JavaScript to conduct business as usual. By bridging the gap between Angular components and DOM elements, these custom Angular Elements can be injected, reflected, and synced with the DOM, allowing for true cross-platforming, reuse, content-rich applications, and dynamically created content.

As this feature grows, we're essentially hitting upon reusability with the true crux being interchangeability. Developers would be able to take their source code and controls, put them through a compiler, and have independent web components ready for use across a variety of ecosystems. With Angular currently receiving support from major browsers like Chrome, Firefox, Opera, and Safari, with Edge still on the cusp, web components and their interchangeability will boost Angular into an even larger spotlight as support builds.

The team is looking towards the upcoming framework independency, as a reduced code size in combination with interchangeable web components will greatly enhance the speed of products built with Ignite UI for Angular.

The Practicality of Building a Native Angular Application:

When Konstantin and Radoslav took time to look over the hierarchal changes, overall streamlining, and the use of tree-shaking, both had a few ideas about the popularity of Angular in the future. Konstantin put forth that,

There’s a big push by Angular for application optimizations that are done by the framework and other supporting frameworks, rather than leaving this to the developer. This gives Angular a big advantage when choosing a framework for adoption, because as a developer, you may or may not be aware of how to optimize your application, and the framework doing that for you saves a lot of time and effort. Bottom line – just like Ignite UI for Angular – it makes you more productive.

As it’s grown, the Angular framework for JavaScript has risen in popularity due to a variety of reasons: its hierarchal structure and modular building; its use of TypeScript; its component and class-based system for easy maintenance; its speed with server-side rendering; its cross-platform capabilities; and its quick-building with simple, declarative templates.

The popularity is also due in part to the practicality of using Angular. The native Angular application affords companies the ability to pull away from using the "lowest common denominator", as oftentimes the easiest of options is chosen when developing for cross-platform capabilities. Frequently, a product will be built in JavaScript and various APIs will be imposed on top to have that product be able to "talk" to relevant programs. This ends up scaling down the overall reusability of an application, which is now being mitigated with Elements.

Furthermore, this practicality is emphasized best by Radoslav, as he illustrated a bit of the reasoning for the team’s transition to building productivity tools in for Angular. He stated, “Angular has a good set of stable features since v4, good tooling for developing and building projects, and enough of a community to continue improving it. In the end, developers and users should decide what actually helps them solve their problems and not which npm package is more popular.”

Virtualization and the Upcoming Renderer:

When I asked Radoslav about Angular and the team’s work with code minification, virtualization, and the implementation of the new “Ivy” renderer with the v7 release, he laughed, saying, “The ‘Ivy’ renderer is the next best thing since sliced bread.”

Our Angular team uses each Angular release to push for high optimization with the virtualization directive to ensure that large-scale data sets will smoothly render with Ignite UI for Angular’s fast data grid. Infragistics recognized that as Angular develops, it's only going to become faster in server-side rendering due to code splitting with features like the new Component Router and the size of the rendering engine itself. Currently, Angular's rendering engine has become smaller and smaller, allowing developers to ship in microcode. With the early testing of the newest rendering engine for Angular 7, code-named "Ivy," developers would be able to ship a basic "Hello World" application in just under 3 kilobytes with the minified version currently standing at just over 7 kilobytes. Paired with Ignite UI for Angular’s updated virtualization directive, we're continually able to provide the fastest Angular data grid on the market today.

As for the Infragistics team, they went and implemented igxForOf in Ignite UI for Angular, which is functioning as an alternative to Angular's ngForOf for templating sizeable amounts of data. As pulled from our documentation, "The igxForOf uses virtualization behind the scenes to optimize DOM rendering and memory consumption. It's working similarly to Paging by slicing the data into smaller chucks which are swapped from a container viewport while a user scrolls the data horizontally and vertically."

They designed this as a way to help developers who are using the Angular data grid for enterprise or commercial applications, as there are two major problems that tend to go hand-in-hand with products that lack strong virtualization for their data grids:

• A noticeable lag in column headers that results in the column names being unable to stay attached to the appropriate column while horizontally scrolling
• A whited-out screen between scrolls as the data is taking time to render

While seemingly insignificant on paper, a product that is able to handle and to render large-scale data sets has become a significant want amongst the enterprise and commercial communities, particularly for those who need this data to be readily available at a moment's notice.

With eyes on Angular to continually release a smaller, faster renderer, the team is continually using these updates to ensure that our Angular Data Grid is able to handle robust data sets without a hitch or lag.

Grid and Component Highlights

Given the strong foundation and implementation of Ignite UI for Angular, let's move through a few of the most talked about features of our data grid and components:

Data Grid

Our Data Grid allows for you to display and manipulate tabular data with Ignite UI for Angular, and you can quickly bind your data with very little coding or configuration. Some must-have features include filtering, sorting, paging, templates, movable columns, and the ability to edit and update data. Also, user actions are easy to understand and can be controlled programmatically.

The grid is exported as an NgModule, thus all you need to do in your application is to import the IgxGridModule inside your AppModule, as shown below:

Once you’ve imported the igxGridModule, you can begin to data bind your information and import various components, directives, and higher classes. You can read about the full process in our documentation, check out the demo on StackBlitz, and here are some notable components from the 18.1 release with which you’ll find yourself working:

• Column Pinning
• Column Resizing
• Export to Excel/CSV/TSV
• Summaries
• Row Selection
• Editors
• Mask Directive
• Input Group
• Toggle
• Theming
• Time Picker

Financial Chart

Importantly, with the igxFinancialChart component, developers are able to construct high-performance, lightweight, and easily configurable charts to display financial data. You can take a look at the component on StackBlitz, and you'll see that, after you bind the data source, you're able to fully customize the financial chart to a preferred visualization. This can provide a user context and clarity to the information through a variety of chartType properties like bar, candle, column, line, and auto.

Below you can see an example of simple data source and the following code to bind a financial chart to that data source:

After customization binding, the financial chart is exported as an NgModule. You'll notice that you'll need to import the igxFinancialChartModule inside of your AppModule:

As a significant feature, you're able to bind high-volume data to your financial chart. Due to Angular specific features, you'll want to make sure to set changeDetection: ChangeDetectionStrategy.OnPush in your @Component decorator. By setting this, you're telling Angular to avoid digging deeply into the changes within your data array, as you wouldn't want that occurring during every changeDetection cycle.

While the above example demonstrated a simple data source, here's a look at binding to high volumes of data:

Category Chart

Our igxCategoryChart component is one that simplifies the complexities of the data visualization domain into a simple API. You're able to bind a collection of data or a collection of collection, and the category chart will automatically select the best series for the data's representation. This component example is also available on StackBlitz, and you'll see that it affords chartType properties like line, area, column, point, and spline.

Similarly to igxFinanicalChart, in order to create the igx-category-chart component, you must bind the data. Below you can see an example of simple data source and the following code to bind a category chart to that data source:

And remember, with the auto option for the chart type, the chart will analyze the assigned data based on suggestions from the Data Adapter.

Looking Forward to Angular 7

The Angular 7 release is slated to arrive sometime in mid to late Fall. We can expect to see more support for Elements and the transition into independent web components, and we'll get the opportunity to work with the new renderer and take advantage of the code minification. Since there's such a large push by Angular to optimize applications, the use of the framework only seems to be growing. It's proving to be particularly useful for developers who aren't sure of how to necessarily optimize an application, and Angular is showing how it can save you time and effort when building. Similarly, the approach harkens to our work with Ignite UI for Angular, in that we're working to boost the use of efficient tooling and productivity.

The Infragistics team has developed a roadmap based off of Angular’s progress, and they’ll be looking to add a series of new components and directives that will enhance Ignite UI for Angular’s library. They’ll also be including a new webpack for Ignite UI CLI and adding more features related to general scaffolding with templates and views for major components. Moving forward, they’re taking advantage of the new schematic feature for Angular and creating one so that ng-update works for Infragistics’ new features.

As I've discussed a few of the reasons why we’ve stepped into the Angular world and some of the latest Angular developments, I'll note again that our team is working closely with Google’s in order to ensure that we develop the best and fastest Angular products for developers working with web and mobile application development. We’re excited to continually bring you features that boast best-in-class grids, charts, and components, so you’re encouraged to take time to look over our entire Infragistics Ultimate 18.1 suite. Plus, you can follow us on Twitter for the latest updates on work that we’re doing.

C# Corner heralds as one of the largest online social communities for IT developers and professionals to share their experiences, articles, and questions. Founded in 2000 by Mahesh Chand, the forums, blogs, videos, and comprehensive interactive materials allow for developers, from the fresh-faced neophyte to the well-seasoned programmer, to forge a community built on an extensive and fruitful learning environment.  

Recently, we've formed a strategic marketing agreement with C# Corner due to the respective leadership we each have in our fields. We'll both be working together to promote, on social media and on our website, the latest information C# Corner has to offer about developer topics specific to the Infragistics community members, such as Angular. WPF, and .NET. In return, C# Corner will continue to post articles about Infragistics' flagship products and highlight core development features.  

With around 57,500 total article views in the recent line-up, here's a breakdown of what's been posted by C# Corner: 

"Build Navigation in Angular App" 

What’s it about? "Learn the following: Install Ignite UI for Angular; Create Angular Project with Ignite UI; Introduction to Navigation Drawer..." 

"Add Validation to a Web Form Using IGValidator" 

What's it about? "IGValidator that can be used to validate a form’s input controls without writing too much code... [and how] this control provides a very high interactive design for success and failure of data validation...because it’s written in JavaScript, that makes it very efficient and easy to code." 

"Create Charts in ASP.NET MVC Using Ignite UI jQuery" 

What's it about? "How to build a complete data-presentable MVC web application using Visual Studio 2017, C#, and Ignite UI JavaScript chart controls." 

"Building a Data Driven App Using WPF XamDataGrid" 

What's it about? "How to build a complete data-driven WPF app using Visual Studio 2017, C#, and Infragistics DataGrid control, XamDataGrid." 

"Building Windows Forms Data Driven App Using UltraGrid" 

What's it about? "How to build a complete data-driven Windows Forms app using Visual Studio 2017, C#, and UltraGrid control." 

"Data Binding and CRUD Operations in ASP.NET WebDataGrid" 

What's it about? "Learn the following: Introduction to data binding in a WebDataGrid; Implemention of paging, filter, and sorting functionality; Auto CRUD database operations; Export records to Excel..." 

"Play Video in Angular Using Ignite UI Video Player"  

What's it about? How "The Ignite UI Video Player is an HTML 5 Video Player which renders video on a web page with a robust, cross-browser user interface." 

Moving forward, be sure to keep up on the news from both C# Corner and Infragistics. You can do so by following both C# Corner and Infragistics via their respective Twitter handles. If you're looking to try out any of the products mentioned in the articles, be sure to check out Ignite UI for Angular, Ignite UI for JavaScript, or our full developer kit with Ultimate 18.1. 

To understand ViewEncapsulation in Angular, first we should understand about Shadow DOM.  You can learn in detail about Shadow DOM here. Putting it in simple words, Shadow DOM brings Encapsulation in HTML Elements. Using the Shadow DOM , markup, styles, and behaviors are scoped to the element and do not clash with other nodes of the DOM. Shadow DOM is part of Web Components, which encapsulates styles and login of element.

Angular Components are made up of three things:

1. Component class
2. Template
3. Style

Combination of these three makes an Angular component reusable across application. Theoretically, when you create a component, in some way you create a web component (Theoretically, Angular Components are not web components) to take advantage of Shadow DOM. You can also use Angular with browsers, which does not support Shadow DOM because Angular has its own emulation and it can emulate Shadow DOM.

To emulate Shadow DOM and encapsulate styles, Angular provides there types of ViewEncapsulation. They are as follows:

Let us try to understand it using an example. I have created a component, as shown below:

app.component.ts

import { Component, ViewEncapsulation } from '@angular/core';
 
@Component({
    selector: 'app-root',
    templateUrl: './app.component.html',
    styleUrls: ['./app.component.css'],
    encapsulation: ViewEncapsulation.None
})
export class AppComponent {
    title = 'parent component';
}

app.component.html

<div>    <h1>        Welcome to {{ title }}!
    </h1></div><app-child></app-child>

app.component.css

h1 {
        background: red;
        color: white;
        text-transform: uppercase;
        text-align: center;
    }

We are setting the style of h1 in the component CSS. We have also created another component:

import { Component } from '@angular/core';
 
@Component({
    selector: 'app-child',
    template: `
  <h1>{{title}}</h1>
  `
})
export class AppChildComponent {
    title = 'child app';
}

In AppChildComponent, we are also using h1 tag. To understand different ViewEncapsulation options, we will change the metadata of AppComponent.

Let us start with ViewEncapsulation.None, in this option,

1. There is no shadow DOM
2. Style is not scoped to component

As you run the application, you will find h1 style has applied to both components, even though we set style only in AppComponent. It happened because in AppComponent we have set encapsulation property to ViewEncapsulation.None.

@Component({
    selector: 'app-root',
    templateUrl: './app.component.html',
    styleUrls: ['./app.component.css'],
    encapsulation: ViewEncapsulation.None
})
export class AppComponent {
    title = 'parent component';
}
 

In the browser when you examine source code, you will find h1 style has been declared in the head section of the DOM.

Therefore, in ViewEncapsulation.None, style gets move to the DOM head section and is not scoped to the component.  There is no Shadow DOM for the component and component style can affect all nodes of the DOM.

Next, let us explore ViewEncapsulation.Native, in this option:

1. Angular will create Shadow DOM for the component.
2. Style is scoped to component

As you run the application, you will find h1 style has applied to both components, even though we set style only in AppComponent. It happened because in AppComponent we have set encapsulation property to ViewEncapsulation.Native, and we are using AppChildComponnet as child inside template of AppComponent.

import { Component, ViewEncapsulation } from '@angular/core';
 
@Component({
    selector: 'app-root',
    templateUrl: './app.component.html',
    styleUrls: ['./app.component.css'],
    encapsulation: ViewEncapsulation.Native
})
export class AppComponent {
    title = 'parent component';
}

In the browser when you examine source code, you will Shadow DOM has created for the AppComponent and style is scoped to that.

Therefore, in ViewEncapsulation.Native Angular creates a Shadow DOM and style is scoped to that Shadow DOM.

Next, let us explore ViewEncapsulation.Emulated, in this option:

1. Angular will not create Shadow DOM for the component.
2. Style will be scoped to the component.
3. This is default value for encapsulation.

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

@Component({
    selector: 'app-root',
    templateUrl: './app.component.html',
    styleUrls: ['./app.component.css'],
    encapsulation: ViewEncapsulation.Emulated
})
export class AppComponent {
    title = 'parent component';
}

 As you run the application, you will find that h1 style from AppComponent is not applied to h1 of AppChildComponent. It is due to emulated scoping. In this style is scoped only to the component. In this option, Angular only emulates to Shadow DOM and does not create a real shadow DOM. Hence, the application that runs in browsers does not support Shadow DOM also and styles are scoped to the component as well.

Let us see how Angular achieves this? In the browser when you examine source code, you will find answer.

Angular has created style in the head section of the DOM and given an arbitrary id to the component. On basis of ID, selector style is scoped to the component.

 These are three ViewEncapsulation options are available in Angular.   I hope you find this post useful. Thanks for reading.  If you like this post, please share it. Also, if you have not checked out Infragistics Ignite UI for Angular Components, be sure to do so! They have 50+ Material-based Angular components to help you code web apps faster.