Why Optimize Images Anyway?

We all want our apps to look good, but images come with costlier load times. Optimizing images can dramatically improve performance metrics, especially the Largest Contentful Paint (LCP), which measures how fast the largest piece of content appears on the screen. This is huge for user experience and SEO. Angular’s NgOptimizedImage directive makes it easy to get it right without manual tweaks.

Key Features of NgOptimizedImage

1. Responsive Images with srcSet and sizes

The srcSet and sizes attributes allow the browser to load the right image size for each device, which is especially helpful for performance. The great thing about Angular’s NgOptimizedImage directive is that it generates the srcSet for you, so you don’t need to do it manually.

Example:

<img
  ngSrc="angular.jpg"
  width="200"
  height="200"
  sizes="80vw"
/>

Here, sizes="80vw" sets the image to 80% of the viewport width. Angular will handle the rest, creating a srcSet with various resolutions so that each device gets the best fit. This saves time and ensures a smooth load no matter the screen size.

2. Customizing Image Breakpoints

If you’re working with specific screen sizes, Angular lets you customize breakpoints by setting an IMAGE_CONFIG token. This way, you can pick just the breakpoints that match your app’s design.

Example:

providers: [{
  provide: IMAGE_CONFIG,
  useValue: {
    breakpoints: [384, 640, 750]
  }
}]

Now Angular will only generate images for 384px, 640px, and 750px, which keeps your file sizes smaller and your app faster.

3. Prioritizing Key Images with priority

Ever noticed how long it can take to load a big image like a banner? The priority attribute tells Angular which images are critical for loading first. If you set priority, Angular preloads the image, making sure it appears quickly, improving that all-important LCP.

Example:

<img
  ngSrc="hero.jpg"
  width="1200"
  height="600"
  priority
/>

For server-side rendered apps, Angular even adds a <link rel="preload"> tag for these images, so they start loading right away. This is perfect for hero images or banners that you want users to see immediately.

4. Fill Mode for Flexible Layouts

Need an image to fill a container, like a background? fill mode has you covered. It lets an image scale to fit the container without needing fixed dimensions, which is perfect for layouts with unknown widths or heights.

Example:

<img ngSrc="background.jpg" fill/>

Just make sure your container has position: relative, absolute, or fixed, so the image fills it properly. This feature is great for responsive layouts where you want images to adapt smoothly.

5. Lazy Loading for Off-Screen Images

Angular makes lazy loading effortless with loading="lazy", which defers loading images until they’re about to be visible. This reduces the initial page load and is awesome for things like image galleries.

Example:

<img
  ngSrc="thumbnail.jpg"
  width="200"
  height="200"
  loading="lazy"
/>

Just be cautious with images that are crucial to the layout, like a logo. For these, skip lazy loading to ensure they load right away.

6. Placeholders for a Better Loading Experience

Nothing kills user experience like a blank loading image. With placeholder, you can show a temporary low-res version or even a Base64-encoded preview while the main image loads. This provides a smoother experience as users see a preview of the image right away.

Here’s an example of implementing a placeholder:

<img
  ngSrc="profile.jpg"
  width="200"
  height="200"
  placeholder
/>

To take it a step further, you can use a Base64-encoded image as a placeholder. For example, a blurred version of the image can be used to indicate that the original is still loading.

The placeholder blur effect can be customized with the placeHolderConfig object or turned off entirely. For example:

<img
  ngSrc="cat.jpg"
  width="400"
  height="200"
  placeholder
  [placeholderConfig]="{blur: false}"
/>

If you'd like to use a Base64-encoded placeholder, you can easily generate the string using:

• Online Tools: Use a free online Base64 converter like Base64-Image, and it will generate the encoded string.
• Command Line Tools: Open a terminal and type the following command:

  base64 -i input-image.jpg

Once you have the Base64 string, you can embed it directly into your HTML as the src for the placeholder:

<img
  ngSrc="profile.jpg"
  width="200"
  height="200"
  placeholder="data:image/jpeg;base64,/9j/4AAQSk..."
/>

This approach makes the user experience smoother and creates a seamless visual flow.

If you use a CDN, you can generate low-res placeholders automatically. Just keep them small (under 4 KB) to avoid slowing down the load. Angular will even throw an error if the placeholder size is too big:

NG02965: The NgOptimizedImage directive (activated on an <img> element with the ngSrc="angular.jpg") has
detected that the placeholder attribute is set to a data URL which is longer than 4000 characters. This
is discouraged, as large inline placeholders directly increase the bundle size of Angular and hurt page
load performance. For better loading performance, generate a smaller data URL placeholder.

CDN Integration for Faster Image Delivery

By using a Content Delivery Network (CDN) with NgOptimizedImage, you get faster load times because images are served from servers closer to your users. CDNs cache content across the globe, meaning shorter load times and less data travel, which makes a huge difference, especially for users far from your primary server.

CDNs also often compress images, ensuring the best quality at the smallest size, which boosts performance even further. When combined with NgOptimizedImage, CDNs can help you build a fast, responsive app that works well for users everywhere.

A Practical Example

Now, let's look at a real-world example to see how the NgOptimizedImage directive can make a big difference in performance. Imagine we’re building a site that displays 16 preview images.

Here’s the initial setup with the standard src attribute:

<div style="...">
  @for (image of list; track $index) {
  <img
    width="300"
    height="300"
    [src]="image"
    alt="A 300x300 placeholder image with a light gray background and bold black 'Preview' text in the center"
  />
  }
</div>

When we analyze the page in Lighthouse, the First Contentful Paint (FCP) comes in at 1.4 seconds, while the Largest Contentful Paint (LCP) lags behind at 13.5 seconds—not ideal.

By making a few tweaks with NgOptimizedImage, we can get those numbers way down:

<div style="...">
  @for (image of list; track $index) {
    <img
      width="300"
      height="300"
      [src]="image"
      alt="A 300x300 placeholder image with a light gray background and bold black 'Preview' text in the center"
      priority
      placeholder
    />
  }
</div>

To go the extra mile, we add a preconnect link for our image server in the <head>:

<link rel="preconnect" href="https://fpoimg.com/">

And in our app configuration, we set up a custom image loader for our CDN (e.g., Imgix):

const appConfig: ApplicationConfig = {
  providers: [provideImgixLoader('https://fpoimg.com/')],
};

With these small adjustments, we see a huge performance boost: FCP drops to just 0.2 seconds, and LCP is down to a quick 0.7 seconds! This is a perfect example of how NgOptimizedImage can make a real difference in your app’s speed and user experience.

Wrapping Up

Angular’s NgOptimizedImage is a fantastic tool for improving image handling and app performance. Whether you’re working with responsive images, lazy loading, or CDN integration, this directive makes it easy to get things right. With these optimizations, you’ll have a faster, smoother app that keeps users happy. Give NgOptimizedImage a try and see the difference in your next project!

You can access the application used in the article on GitHub.

In this article, we will take a look at how to test the reactive components in Angular, especially with some of the nifty new features that have come along. Our case study involves a component we created for demonstration, UsersComponent. Together, we'll unpack its code and walk through the testing process, highlighting on the why's and how's of each step.

Getting to Know UsersComponent

First off, let's chat about our UsersComponent. It's a nifty standalone component designed to handle a user list in a reactive manner, making good use of Angular's reactive features like signal and effect() for handling the data and keep the UI fresh.

@Component({
  standalone: true,
  // Component metadata...
})
export class UsersComponent implements OnInit {
  private readonly usersService = inject(UsersService);
  readonly dataSource: MatTableDataSource<User> =
    new MatTableDataSource<User>([]);
  readonly users: WritableSignal<User[]> = signal([]);

  constructor() {
    effect(() => {
      this.dataSource.data = this.users();
    });
  }

  async ngOnInit(): Promise<void> {
    this.users.set(await lastValueFrom(this.usersService.getUsers()));
  }

  addUser(): void {
    const iter = this.users().length + 1;
    this.users.update(users => [...users, newUser]);
  }

  removeUser(id: string): void {
    this.users.update(users => users.filter((user) => user.id !== id));
  }
}

The constructor is where the magic starts. We've got an effect() that set up the stage and ensures the MatTableDataSource is always reflecting the latest users' data. It keeps our UI accurately updated, no manual refreshes needed.

When ngOnInit() kicks in, it's all about fetching the async data and setting it up in the users signal. This action gets the ball rolling for the effect to do its thing and update the UI.

We have also implemented methods to add a new user or take one out. The addUser() and removeUser() functions tweak the users signal, which also triggers the effect() to update the data source accordingly.

The How-To of Testing

Now, when it comes to testing these reactive Angular pieces, there's a bit of know-how involved. We need to understand several Angular-specific methods and concepts, along with strategies to avoid calls to the real services. We're tackling TestBed.flushEffects(), the mechanics behind effect(), signal.update(), signal.set() and fixture.whenStable()method, not to mention Jasmine's spyOn to keep our service calls in check.

Understanding TestBed.flushEffects()

The TestBed.flushEffects() method, introduced in recent Angular updates (PR #51049 and PR #53843), is super important for testing components with effects. It ensures that all the queued effects are executed in the test environment. This is especially useful for those asynchronous moments when you want to make sure everything's settled before making your assertions.

The Trio: effect(), signal.set(), and signal.update()

In our UsersComponent, we used the power of effect(), signal.update(), and signal.set() to keep things reactive and fresh.

The effect() function allows us to create a reactive link between the users signal and the MatTableDataSource. This means whenever the users signal changes, the effect() function automatically updates dataSource.data, ensuring the UI stays in sync with the state.

signal.set() is our direct line to replace the signal's current value and kick the effect() into gear, updating the data source with the fresh list of users.

signal.set([...users, newUser]);

And for those times when you need to finesse the current signal value, signal.update() is the go-to, allowing tweaking the signal's value based on its current state. Perfect for when you want to add a new user without replacing the whole users list.

signal.update(users => [...users, newUser]);

Ensuring Stability with fixture.whenStable()

Asynchronous operations are the norm when fetching data, we need to ensure that our tests wait for these operations to complete. This is where whenStable() comes into play.

await fixture.whenStable();

This function returns a promise that resolves when all pending asynchronous activities within the component are completed. It's essential for ensuring that our assertions are made after the component has finished processing the data.

Keeping it Real with Jasmine spyOn

We definitely don't want our tests making actual calls out to the real services. So, we bring in Jasmine's spyOn method to intercept calls to the UsersService.getUsers() method and provide controlled, predictable responses.

beforeEach(() => {
  spyOn(usersService, 'getUsers').and.returnValue(of(mockedUsers));
...
});

By doing so, we simulate the service's behavior without making actual HTTP requests. This approach ensures that our tests remain fast and are not affected by external factors such as network latency or service availability.

Firing up ngOnInit()

We used fixture.detectChanges() to work in the beforeEach to get the component's lifecycle rolling and make sure ngOnInit does its thing.

beforeEach(() => {
  ...
  fixture.detectChanges();
});

This is essential for setting up the initial state of the component, such as bind properties or fetching the initial list of users and ensures that tests have a consistent starting state, with the component fully initialized and ready to respond to simulated user interactions.

Diving into Testing UsersComponent

Armed with our understanding of Angular's reactive features and testing methods, we're now ready to delve into the unit tests for UsersComponent. Each test case is meticulously crafted to verify the component's functionality, ensuring it behaves as expected under various scenarios.

Test 1: Populating MatTableDataSource with Users

it('should populate MatTableDataSource with users', async () => {
  expect(component.dataSource.data.length)
    .withContext('Data Source length before fetch').toBe(0);

  await fixture.whenStable();
  TestBed.flushEffects();

  expect(component.users()).withContext('User list after fetch')
    .toEqual(mockedUsers);
  expect(component.dataSource.data.length)
    .withContext('Data Source length after fetch').toBe(3);
  expect(component.dataSource.data).toEqual(mockedUsers);
});

In this test, we first assert that our data source is initially empty. After calling fixture.whenStable(), we ensure all asynchronous operations have completed. Then, TestBed.flushEffects() is invoked to process any effects, such as those linked to our users signal. This guarantees that our UI is synchronized with the current state. We conclude by asserting that the data source now contains the mocked users, proving that our effects correctly update the UI in response to the signal changes.

Test 2: Adding a New User

it('should add a new user', async () => {
  const newUser = {
    id: 'id_4',
    username: 'user_name_4',
    email: 'test4@email.com'
  }

  await fixture.whenStable();
  await component.addUser();
  TestBed.flushEffects();

  expect(component.dataSource.data.length)
    .withContext('Data Source length after new user addition').toBe(4);
  expect(component.dataSource.data).toEqual([...mockedUsers, newUser]);
});

This test focuses on adding a new user. We initiate by awaiting component stabilization and then invoke the async addUser() method, which updates the users signal. Post this, TestBed.flushEffects() is called to trigger the effects that update the UI. Our assertions confirm that the data source now includes the new user, demonstrating the component's dynamic response to state changes.

Test 3: Removing a User

it('should remove user', async () => {
  await fixture.whenStable();
  await component.removeUser('id_2');
  TestBed.flushEffects();

  expect(component.dataSource.data.length)
    .withContext('Data Source length after user remove').toBe(2);
  expect(component.dataSource.data[1].id).toBe('id_3');
});

In the final test, we validate the removal of a user. After stabilizing the component, we call removeUser(), updating the users signal. Following this with TestBed.flushEffects() ensures our effects process this change. The assertions then verify that the data source has been updated to reflect the removal of the specified user, again highlighting the reactive nature of our component.

Putting it All Together

Here's the complete overview of our UsersComponent tests:

describe('UserListComponent', () => {
  let component: UsersComponent;
  let usersService: UsersService;
  let fixture: ComponentFixture<UsersComponent>;
  const mockedUsers: User[] = [
    {"id": "id_1", "username": "user_name_1", "email": "test1@email.com"},
    {"id": "id_2", "username": "user_name_2", "email": "test2@email.com"},
    {"id": "id_3", "username": "user_name_3", "email": "test3@email.com"}
  ];

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [UsersComponent, NoopAnimationsModule, HttpClientTestingModule],
      providers: [UsersService],
    }).compileComponents();

    usersService = TestBed.inject(UsersService);
    fixture = TestBed.createComponent(UsersComponent);
    component = fixture.componentInstance;
  });

  beforeEach(() => {
    spyOn(usersService, 'getUsers').and.returnValue(of(mockedUsers));
    fixture.detectChanges();
  });

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

  it('should initialize with default values', () => {
    expect(component.isLoading()).toBeTruthy();
    expect(component.dataSource.data.length).toBe(0);
    expect(component.displayedColumns.length).toBe(4);
  });

  it('should populate MatTableDataSource with users', async () => {
    expect(component.dataSource.data.length)
      .withContext('Data Source length before fetch').toBe(0);

    await fixture.whenStable();
    TestBed.flushEffects();

    expect(component.users()).withContext('User list after fetch')
      .toEqual(mockedUsers);
    expect(component.dataSource.data.length)
      .withContext('Data Source length after fetch').toBe(3);
    expect(component.dataSource.data).toEqual(mockedUsers);
  });

  it('should add a new user', async () => {
    const newUser = {
      id: 'id_4',
      username: 'user_name_4',
      email: 'test4@email.com'
    }

    await fixture.whenStable();
    await component.addUser();
    TestBed.flushEffects();

    expect(component.dataSource.data.length)
      .withContext('Data Source length after new user addition').toBe(4);
    expect(component.dataSource.data).toEqual([...mockedUsers, newUser]);
  });

  it('should remove user', async () => {
    await fixture.whenStable();
    await component.removeUser('id_2');
    TestBed.flushEffects();

    expect(component.dataSource.data.length)
      .withContext('Data Source length after user remove').toBe(2);
    expect(component.dataSource.data[1].id).toBe('id_3');
  });
});

Wrapping Up

I hope you found our stroll through UsersComponent testing as insightful as it was enjoyable. Testing, especially with Angular's latest reactive features, doesn't have to be a pain in the neck. Actually, it's quite the opposite—it's a smooth, straightforward, and enjoyable task.

We've seen how tools like signal.set(), signal.update(), and effect() can be game-changers, making our tests not just necessary but a piece of cake. With the right approach and understanding, testing becomes less of a chore and more of an exciting part of the development process.

Incorporating these new features into our testing routine has shown us that it's not just about ensuring our components are up to snuff. It's about embracing a more dynamic and enjoyable workflow. The tests we've walked through exemplify this mindset, proving that with Angular's advanced capabilities, we're fully equipped to handle any reactive challenges that come our way, all with a smile.

So, let's shake off any old notions that testing is a drag. With Angular's reactive features, we're ushering in a new era of testing that's efficient, effective, and, dare I say, fun :)

You can find access to the working application and tests on GitHub.

In this article, we'll delve into the evolution of Angular's change detection strategies, exploring how they've transformed our applications to be more responsive and effective. Angular has made significant strides from the global top-down Default approach to the widely embraced OnPush strategy. However, the introduction of Signals-based methodology, as outlined in the Angular documentation promises even more significant efficiency gains in the change detection.

We'll explore the general inner workings of these strategies and analyze the performance gaps between them. Furthermore, we'll speculate on the direction of Angular's change detection mechanisms. So, let's get started!

Early Stage

Change detection kicks off with any asynchronous browser events, and Angular relies on the NgZone module to observe these interactions. When an async event occurs, Angular triggers the change detection process, traversing the view tree from top to bottom. However, there's a contrast in how components are marked for update across various strategies

Old-School Change detection

Back in the early days, Angular's default change detection was like a noisy neighbor. It kept an eye on every component, binding, and dependency whenever any event happened, leading to updates throughout the entire application. This method works, but it often leads to performance issues in bigger apps because it tends to perform checks even when everything has stayed the same.

Default Change Detection in Action

With the default change detection strategy, Angular keeps an eye on all components unless the view is explicitly detached:

@Component({
  selector: 'detached',
  template: `Detached Component`
})
export class DetachedComponent {
  constructor(private cdr: ChangeDetectorRef) {
    cdr.detach();
  }
}

This strategy relies on the CheckAlways flag:

let shouldRefreshView: boolean = !!(
  mode === ChangeDetectionMode.Global && flags & LViewFlags.CheckAlways
);

which ensures that Angular performs change detection on every view and executes the template function regardless of whether there are changes or not.

[

Click on component "H," which creates a domino effect throughout the entire app, even when it's just a false alarm.

A Relaxed Approach to Change Detection

To speed things up, Angular brought in the OnPush change detection strategy. The OnPush option has been around just as long as the Default one. But to switch it on, developers needed to give their components a heads-up, letting them know they wanted to use it. OnPush is like a more discerning detective, only springing into action when a component's inputs change or events occur within that component. This optimized approach relied on immutable states and reduced unnecessary checks, making our apps more straightforward and faster. So, how does it work?

Unpacking the OnPush Change Detection Strategy

With the OnPush strategy, change detection takes a back seat unless a component is flagged as dirty:

shouldRefreshView ||= !!(
  flags & LViewFlags.Dirty &&
  mode === ChangeDetectionMode.Global &&
  !isInCheckNoChangesPass
);

To mark that a component as dirty, we can change an input property, emit an event, or manually invoke the markForCheck() method, which marks the current view and all its folks up the family tree, all the way to the root view, for a thorough check.

@Component({
  selector: 'dirty',
  template: `Dirty Component`,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class DirtyComponent {
  constructor(private cdr: ChangeDetectorRef) {
    cdr.markForCheck();
  }
}

Angular then takes a tour of each dirty flagged view, executing the template function associated with its respective component.

With OnPush, a click in the component "H" triggers an event through clicked component itself and its parents.

Signals Era

From Angular v16 onwards, Angular has been moving towards adopting Signals, altering front-end state management. Unfortunately, as of version 17 , Signal-based Components remain under development, delaying the full implementation of Signal-based change detection. In the meantime, Angular allowed us to utilize the power of Signals and OnPush strategy to mark individual components as dirty. This Local Change Detection ensures no more unnecessary checks for parent or child components designated as OnPush.

Additionally, Angular's recent advancements in event detection include implementing signal inputs, where input value updates occur before the change detection cycle. This improvement ensures that change detection does not execute if the template doesn't use the input. Moreover, changing the value bound to an input no longer triggers a refresh of the parent view, as with the OnPush strategy.

Streamlining Change Detection with Signals

When we change the signal within a component's template using methods like set() or update() , we kick off a chain reaction. This signal triggers a notification to the reactive live consumer within the view, marking it as dirty through the markAncestorsForTraversal(). But it doesn't stop there – it also marks all ancestors, up to the root, with the HasChildViewsToRefresh flag. If the view is marked as dirty, the template function is called, and the current value is returned.

shouldRefreshView ||= !!(
  consumer?.dirty && consumerPollProducersForChange(consumer)
);

However, if the view is marked with the HasChildViewsToRefresh flag, there's no need to bother with the template function. It just takes a shortcut, skipping the template function and diving right into checking the children. This clever move helps Angular avoid unnecessary tasks, operations, calculations, and comparisons, ensuring everything runs smoothly and efficiently.

if (shouldRefreshView) {
  refreshView(tView, lView, tView.template, lView[CONTEXT]);
} else if (flags & LViewFlags.HasChildViewsToRefresh) {
  detectChangesInEmbeddedViews(lView, ChangeDetectionMode.Targeted);
  const components = tView.components;
  if (components !== null) {
    detectChangesInChildComponents(lView, components,
      ChangeDetectionMode.Targeted);
  }
}

The future

Looking ahead, Angular seems set to embrace a Signals-based Change Detection system fully. It's like getting a superpower to track changes with laser precision, eliminating the need for NgZone to manage execution context completely. By going zone-less, developers will have better, fine-grained control over change detection, enabling a more efficient and focused approach and optimizing performance even further by running Change Detection only when necessary. This approach will fundamentally change how Angular tracks and handles changes, allowing developers to pinpoint precisely where and when updates should occur.

However, transitioning to this new paradigm requires developers to understand signals better to harness their full potential. Despite the learning curve, the performance and scalability gains make it a worthwhile investment for projects aiming for optimal performance.

As Angular continues to evolve, developers must stay updated with these advancements in Change detection strategies.

The journey from the default strategy through OnPush and towards Signals-based Change Detection highlights Angular's commitment to enhancing performance and scalability. By adopting these advanced strategies, developers are empowered to build functional and exceptionally performant Angular applications.

In the world of Local Change Detection, a change in component "F" gets the attention it deserves without redundantly checking parent or component children.

Conclusions

In conclusion, the evolution of change detection in Angular reflects a constant effort to refine and optimize performance. Embracing these advancements empowers developers to create Angular applications that are not just functional but also highly performant, ensuring a seamless user experience across a wide range of applications. Given the progress that has been made in this regard, I look forward with optimism to further releases of the Angular framework.

The principle of change detection can be viewed in this GitHub application.

In this article, we’ll take a look at the impact of different build options of the Angular CLI on the build time of a monolithic application. Building is usually on a critical path of the continuous integration (CI) pipeline—that is, any changes to build duration impact the total CI time. The Angular team makes a few build optimizations available for developers, and in this post, we’ll take a look at their impact.

Measurements

To make the data reproducible and relevant, I’ll run the test builds with CircleCI. Using external servers for the build isolates the measurement from my local environment. At the same time, the results come from machines that others are using for building as well.

The key measurement I’ll pay attention to is the time needed to run the npm run build command:

At this level, I expect to see the most direct results of the optimization we use. If we manage to cut the build time in half, then we should see this impact here.

Another value to consider is the time of a whole build job. This will be especially important for optimizations that come with positives and negatives: for example, caching can speed up some operations, but part of the gain will be eaten by the downloading and uploading cache.

The last measurement for us to consider is the overhead: the difference between build script and build job. It will contain everything that is done before or after the build: restoring the cache, installing dependencies, saving the cache. With this number, we should see clearly the downsides of some optimization.

I’ll repeat each test build 5 times under the same circumstances and use the average of the measurements as the measurement value. In this way, I’ll be able to reduce a bit of random noise in the data without turning it into a full scientific experiment.

Application structure

As a benchmark, I’m using the build time of a simple application generated and built with the Angular CLI. The application models the real world complexity by including 1000 components. This approach is inspired by Nrwl’s Angular benchmark. Each component is very simple:

src/app/component1/component1.component.ts:

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

@Component({
  selector: 'app-component1',
  templateUrl: './component1.component.html',
  styleUrls: ['./component1.component.css']
})
export class Component1Component {

}

src/app/component1/component1.component.html:

<p>component1 works!</p>

And the whole application just displays each component one after another:

The biggest blind spot is the lack of third-party libraries. This is something that almost all real-world applications do, but including it in the benchmark would tie the results to the set of libraries used in the example application.

Build options

In my test, I’m measuring the build time in the following setups.

Baseline

This is the standard build as it’s generated by Angular CLI. Important features are as follows:

• it uses webpack under the hood
• it lacks ng cache for CI—so each build during CI starts from scratch
• the build job provides cache for npm install

esbuild

esbuild is a promising bundler with much better performance than Webpack: according to its own website, it’s up to 100 times faster. Because of its speed, since version 14, the Angular team has provided an experimental builder based on esbuild. It was recently improved in version 15. It can be turned on easily, with just 1 line change in angular.json:

       "architect": {
         "build": {
-          "builder": "@angular-devkit/build-angular:browser",
+          "builder": "@angular-devkit/build-angular:browser-esbuild",
           "options": {

Note! So far, this change affects only the build—the development server is still using Webpack. This is likely to change in version 16.

ng caching

For local builds, Angular CLI caches build results to save time on reruns. By default, this feature is turned off for CI. To use caching during CI, we need two changes:

• changing the cache configuration from local-only, and
• reading and saving the cache during CI.

You can turn on caching with two commands:

ng config cli.cache.environment all
ng cache enable

Managing cache files for CI will require changes in configuration. You can find my change for CircleCI here.

TypeScript 5

TypeScript 5 promises up to 10% improvement for the build time. It’s not yet available for Angular applications, but it’s on track to come in version 16. For my tests, I’m updating Angular to pre-release version 16.0.0-next.4.

Data

The builds I’ve run measured as follows:

| | npm run build (s) | Build job (s) | Overhead (s) | |------------------|-------------------|---------------|---------------| | baseline | 57.8 | 92 | 34.2 | | esbuild | 14.4 | 50.2 | 35.8 | | hot build cache | 31.4 | 67 | 35.6 | | cold build cache | 66.8 | 104.2 | 35.6 | | TypeScript 5 | 55 | 84.8 | 29.8 |

The baseline time needed to complete npm run build was on average 57.8s. The biggest improvement we can see is with switching to esbuild: it becomes 4 times faster and takes only 14.4s to build. Both builds have very similar overhead. With esbuild, the build job takes 56% of time that was needed in the baseline case—an excellent improvement.

Another optimization—caching of the Webpack build—looks very promising as well. Because there are more files cached, I expected a clear increase in the overhead. It went from 34.2s to 35.6s, but this difference could be statistically insignificant. Caching of the build has two effects:

• speed increases when cache is “hot”—with files already in place, the build job finishes in 31.4s instead of 57.8s.
• speed decreases when the cache is “cold”—most likely, the build takes more time because there are way more files to be written on the disk. Build went up from 57.8s to 66.8s.

Lastly, an interesting case is updating to TypeScript 5. The time needed to complete the npm run build lowered slightly from 57.8s to 55.5s. At the same time, the overall build job took 84.5s instead of 92s, which is a better improvement than the build script alone. This could be explained by the more efficient installation—maybe TypeScript 5 or other v16 dependencies are faster to install.

Conclusions

1. Check out esbuild—if it won’t introduce regressions to your code, you can immediately enjoy faster builds!
2. If esbuild doesn't work in your case, try enabling caching for Webpack on CI.
3. Don’t hold your breath for the speed increase that comes with switching to TypeScript 5.

Links

You can find our test application here.

Looking for more support for your Angular projects?

Our team at DevIntent is highly experienced in web development, including framework migration and updates. Check out our offerings or reach out.

New bundlers

A lot of optimization in Angular happens at build time. For this to be possible, Angular provides a custom compiler. The compiler takes care of things specific to Angular: ahead-of-time compilation or catching issues in the templates. The build is complex, but Angular CLI provides you all the configuration you need. Under the hood, Angular CLI uses Webpack, a well established bundler with a very active community.

While Webpack is the most popular bundler available, it has its downsides—especially speed when it builds larger codebases. Whereas Webpack is in active development and there are incremental improvements in speed between versions, there are other bundlers that take a fundamentally different approach and boast greatly improved speeds. A slower bundler causes slower builds, and this can negatively affect productivity in the project at all stages—from development to continuous integration.

To allow the Angular community to enjoy the benefits of faster bundlers, the Angular CLI has offered an experimental esbuild configuration since version 14, and it’s been reported to lower build time by up to 44%. The Roadmap also lists further investigation and progress toward making the improved builds stable, so we hope to see continued speed increases coming to applications built with the Angular CLI.

Further development of the image directive

Due to their size, images have a disproportionately large impact on web performance. Managing them well is especially important for the mobile user experience for a couple of reasons:

• When on the go, mobile users can experience slower and less stable internet connections or may be charged for the data transfer.
• Because of their often smaller screens, images on mobile devices don’t need the same high resolution as desktop users.

Managing images well can be difficult, especially in applications rendered on the client side. Improvements to image management for both users and developers are welcome. So it’s promising to see on the roadmap further enhancements to NgOptimizedImage that the Angular team plans to add to the framework.

Debugging dependency injection

In my AngularJS development work, I often use this snippet to access my services from the dev tools console:

 angular.element(document.body).injector().get('serviceName')

I find it very helpful to be able to test my methods interactively in the browser as I develop them. For that reason, I’m looking forward to seeing the updates in Angular DevTools that will bring dependency injection debugging APIs.

Upcoming changes

Those are the changes I’m the most excited about in that are on the way to becoming part of Angular v16. You can find the list of priorities for the current development in the project’s roadmap.

Looking for more support for your Angular projects?

Our team at DevIntent is highly experienced in Angular development, testing, and software quality. If you'd like to chat about how we can help you, please contact us at sales@devintent.com.

• The load time of the application will be lowered, improving your users’ overall experience—this is important for users with a slow internet connection, which is critical for applications primarily used on mobile devices.
• The amount of data transferred out of your servers—which can impact your cloud or data center cost, depending on the use case and hosting setup.

Introducing Brotli

Currently, Brotli is the most efficient compression algorithm for website code. According to benchmarks, HTML, CSS, and JS files are more than 10% smaller when compressed with Brotli compared to traditional GZIP. Brotli offers better results and is supported across all modern browsers—in most cases, it should be the go-to solution for compressing website data.

Whose responsibility is it to compress the files?

Isn’t compression something done automatically by your hosting provider? It can be, but there are few downsides to depending on a third party to compress the application:

• Compressing files is fast, but doing it when users request the files will introduce unnecessary delay. It’s safe to assume this is what happens when you are using compression support provided by hosting.
• You are limited to what is provided by the hosting company. GZIP may be the only option, which will produce files bigger than those compressed with Brotli.

As an alternative to automatic compression provided by hosting, you can generate .br files every time you build your app for deployment. In this way, you can ensure that .br files are up to date and ready on the server when needed—and that the user experience will not be affected by slow compression. Depending on your hosting setup, there will be different ways to configure your server to use .br files for user agents that accept Brotli.

How to set up Brotli in your Angular-based application

If you are interested in using Brotli for your AngularJS or Angular application, our team recently published a guide on the XLTS.dev blog here.

Looking for more support for your Angular projects?

Our team at DevIntent is highly experienced in Angular development, testing, and software quality. If you'd like to chat about how we can help you, please contact us at sales@devintent.com.

Stand-alone Components

Stand-alone components are components that are defined outside any NgModule. They are providing a simplified API that reduces the boilerplate necessary to define a component. Stand-alone components, directives and pipes integrate nicely with the existing Angular landscape. They

• can be used in traditional modules,
• can import modules to reuse existing code, and
• can even be used to bootstrap an application.

You can learn more in the official guide.

New Tree-shakeable APIs

Along with the stand-alone components, some services are available in a lighter form that works better with tree shaking. These APIs will help you keep your reusable code smaller—instead of including entire modules with all the features you don’t use. Thus, you can pick only the things that you need. All the rest is dropped during the build process with tree shaking.

Router

provideRouter allows you to pick various features of the router to optimize your build size:

type RouterFeatures = PreloadingFeature | DebugTracingFeature | InitialNavigationFeature | InMemoryScrollingFeature | RouterConfigurationFeature;

HttpClient

Similarly, provideHttpClient allows you to choose from the following features:

enum HttpFeatureKind {
  Interceptors
  LegacyInterceptors
  CustomXsrfConfiguration
  NoXsrfProtection
  JsonpSupport
  RequestsMadeViaParent
}

Image Directive

The NgOptimizedImage directive has become stable. The directive enforces best practices in loading images, improving the page's load performance.

Together with an ImageLoader, it can be used to generate the appropriate resource URL for a given image file. You can learn more about this (including plans for the future) on the Chrome blog in Optimizing Images with the Angular Image Directive.

Directive Composition API

As of version 15, Angular allows you to reuse existing directives as building blocks when creating new directives or components. With hostDirectives, you can add directives to your host element, effectively combining a few directives into one. It is similar to how some languages support multiple inheritance in classes. You can learn more, including performance implications, in the official guide.

Migration of Angular Material Components to new components based on MDC

The Angular team migrated the Angular Material components to reuse framework-independent code available in Material Design Components for the Web ("MDC"). This results in an improvement in how close the components are following the Material Design 2 specification; in the future, it will allow for switching styling to Material Design 3.

If you overwrite many styles in Angular Material components, be prepared for a large amount of refactoring. Migration requires changing the internal DOM structure and styling of the components, as well as some changes to the external API. You can learn more about what was changed and what updates are needed in the application in the MDC migration guide. The previous components are deprecated, but are still available to smoothen the migration.

Deprecated Features

Besides new additions to the framework, a few things were deprecated and will be removed in a future version. If you are using any of the features below in your apps, you should start making plans to move away from them.

@angular/flex-layout

The Angular team will stop releasing new versions of @angular/flex-layout — but they will publish security and browser compatibility updates for the following year. Instead, there are two alternatives available in pure CSS:

• flexbox
• grid

You can find the official recommendations in the article on the Angular blog in Modern CSS in Angular: Layouts.

providedIn: any and providedIn: NgModule

Both options were decided to be uncommon and confusing enough to be deprecated. If you use them, check the official release announcement to see the way forward. We will no longer be able to register services in lazy loaded modules using providedIn: NgModule, but only by using an old fashion technique—using the NgModule.providers array.

Update Guide

As always, you can find relevant update instructions in the Angular Update Guide.

Angular v15.1.0 update

Self-closing Tags for Non-native HTML Elements

Starting with version 15.1.0, Angular supports self-closing tags for non-native HTML elements (including Angular components). This will allow decluttering your templates by omitting closing tags. For example, you can replace <my-component></my-component> with just <my-component />.

Looking for more support for your Angular projects?

Our team at DevIntent is highly experienced in web development, including framework migration and updates. Check out our offerings or reach out.

In order for large web applications to be scalable, they are usually broken up into a number of modules. Very often, we need to reuse individual Components, Pipes, and Directives in many places of our application. Duplicating code for repetitious items is not the best practice. This is why we usually create a shared module, registering all reusable and generic elements of our application there, so that we can use them later in any feature module.

It makes sense to create a global place for all reusable items. Unfortunately, it also has disadvantages.

As the project evolves and the demand for more and more reusable elements increases, the shared module can grow significantly. We must be aware. that in order to use one component, we have to import all the elements registered in the shared module, which becomes inefficient.

Shared Modules

Let's look at the situation from a sample application.

We have defined 2 modules, AppModule and UsersModule. They both use ButtonComponent. Additionally, UsersModule uses a FilteredListComponent with users, which is also a reusable component - it accepts any shape of a single list element. We put both reusable components in a shared module.

export module SharedModule {
  export const name: string = 'Shared';

  angular
    .module(SharedModule.name, […])
    .component(FilteredListComponent.componentName, FilteredListComponent.componentConfig)
    .component(ButtonComponent.componentName, ButtonComponent.componentConfig);
}

angular.module('AppModule', [SharedModule.name])

angular.module(UsersModule.name, [SharedModule.name]);

As we can see, AppModule needs to import the entire SharedModule to access the reusable ButtonComponent.

Now imagine that our application defines hundreds of such reusable elements. We won't need all of these elements in every module. A Single Component Angular Module ("SCAM") comes to the rescue.

What is SCAM?

Single Component Angular Module, or SCAM for short, is the concept of creating small, encapsulated and reusable AngularJS / Angular modules with only one Component (or Directive, or Filter / Pipe).

SCAM in action

Instead of a global module with elements shared between the entire application, we can define modules for each of the elements:

export module ButtonModule {
  export const name: string = 'ButtonModule';
  angular
    .module(ButtonModule.name, ['ngMaterial'])
    .component(ButtonComponent.componentName, ButtonComponent.componentConfig);
}

export module FilteredListModule {
  export const name: string = 'FilteredListModule';
  angular
    .module(FilteredListModule.name, ['ngMaterial'])
    .component(FilteredListComponent.componentName, FilteredListComponent.componentConfig);
}

We can see that we can easily build a module architecture that provides only the required elements for given views, without the need to import unused Components, Filters / Pipes, or Directives.

export module UsersModule {
  angular.module(UsersModule.name, [ButtonModule.name, FilteredListModule.name]);
}

module AppModule {
  angular.module('AppModule', [ButtonModule.name]);
}

SCAM and Refactoring

Note that the SCAM-based architecture allows you to refactor the code quickly. If you reach the point where UsersModule no longer requires the use of buttons, you would need to delete the dependency to remove it. Adopting this method gives you a considerable advantage over shared modules when migrating from AngularJS to Angular. You can now migrate application sections more efficiently by breaking them into independent but valuable parts because you depend on only one component and not on sets of components.

SCAM and Standalone Components

Another point I would like to make is the similarity with Standalone Components. Let's recall that since Angular version 14, we can write code without using Angular modules. Having SCAM defined:

import {UpperCasePipe} from '@angular/common';

@Component({
  selector: 'app-button',
  template: `
    <button mat-button>Sample Button</button>
  `,
})
export class ButtonComponent {
  // your component's code
}

@NgModule({
  declarations: [ButtonComponent],
})
export class ButtonComponentModule {
}

we can easily migrate to Standalone Components without worrying that we messed up something in other parts of the application, since it is an independent piece of code.

@Component({
  standalone: true,
  selector: 'app-button',
  template: `
    <button mat-button>Sample Button</button>
  `,
})
export class ButtonComponent {
  // your component's code
}

Conclusion

Using common SCAMs creates some overhead because you have more modules and more imports in your feature modules. On the other hand, you get smaller, better encapsulated modules that are less cumbersome to maintain. SCAM-based code refactoring is much more straightforward and less time-consuming. Even more complicated migrations from AngularJS to Angular will be simpler to implement, and applying Standalone Components in the project will reduce the risk of bugs.

As I mentioned SCAM is a concept, not imposed by a specific framework or API version. So it can be used wherever we are dealing with shared components.

The source code for this example is in this GitHub repository.

Looking for more support for your Angular projects?

Our team at DevIntent is highly experienced in web development, including framework migration and updates. Check out our offerings or reach out.

How often do you use data in your applications? I do this in every application I implement.

We typically fetch data using an HTTP client in a service. Sometimes, the HTTP client is even used directly in a component, which is not very good practice. But this article is not about good and bad practices, so let’s move on.

So inside the Service, we can inject another Service, for example, $http (AngularJS), or HttpClient (Angular). The built-in HTTP Angular services are outstanding.

Why are we using them?

When AngularJS was written, the browsers didn't have a fetch() API. Well, now times have changed, and they do!

So why don’t we use fetch() instead of the HTTP client? You might think:

Well, it’s just easier to use the build-in HTTP client

or simply:

Why should I use something else if I get an HTTP client with the framework I’m using?

Think about React, Vue.js, other web frameworks or just plain JavaScript. What are they using? Well, they use the fetch() API. And if they need something more complex and involved, they can use things like Axios - a promise-based HTTP client for Node.js and the browser.

Axios in action

Let’s look at an AngularJS and Angular-based application that does not use the built-in HTTP client. Here’s what it might look like in AngularJS:

import axios, {AxiosResponse} from 'axios';
import {User} from '../users.module';

export class UsersService {
  loadAllUsers(): Promise<AxiosResponse<User[]>> {
    return axios.get('assets/mocks/users.json');
  }
}

and Angular:

import {Injectable} from '@angular/core';
import axios, {AxiosResponse} from 'axios';
import {User} from '../users.module';

@Injectable({
  providedIn: 'root'
})
export class UsersService {
  loadAllUsers(): Promise<AxiosResponse<User[]>> {
    return axios.get('assets/mocks/users.json');
  }
}

So, as we can see, we define a service called UsersService in both cases. And you’ll notice we're pulling in Axios. We can also see a method named loadAllUsers(). That method invokes Axios APIs, which return a Promise which will eventually resolve with the returned data.

The code examples above are straightforward and very similar. But notice what you do not see as well. It’s not just the HTTP service switched out for Axios in this case.

Where are the Observables in the Angular-based code example?

Now RxJS is extremely powerful and valuable. But do you ever feel weighed down when you’re getting into a new technology? Maybe you feel like:

I don’t need this yet

I shouldn't need to learn all of these concepts to understand a basic example.

Well, with this, you don’t have to. With fetch() and Axios, you can jump right into using Promises. But there is an even more significant advantage that we may overlook at first glance.

Migration from AngularJS to Angular

As some of you know, migrating an AngularJS-based application to Angular is a real challenge. Interfaces and APIs are so different that it's safe to say that they are two completely different frameworks. The way the HTTP client is used in the two mentioned versions is also completely different.

Here is an example of how we use the built-in $http service in AngularJS:

import {IHttpResponse, IHttpService} from 'angular';
import {User} from '../users.module';

export class UsersService {
  constructor(private $http: IHttpService) {
  }

  loadAllUsers(): Promise<IHttpResponse<User[]>> {
    return this.$http.get('assets/mocks/users.json');
  }
}

And here is an example of using the built-in HttpClient service for Angular:

@NgModule({
  imports: [HttpClientModule],
  ...
})
export class UsersModule {
}

import {HttpClient} from '@angular/common/http';
import {Injectable} from '@angular/core';
import {Observable} from 'rxjs';
import {User} from '../users.module';

@Injectable({
  providedIn: 'root'
})
export class UsersService {

  constructor(private http: HttpClient) {
  }

  loadAllUsers(): Observable<User[]> {
    return this.http.get<User[]>('assets/mocks/users.json');
  }
}

Maybe we should consider using a library that is independent of the framework used and guarantees a consistent API, whether in AngularJS, Angular or even React. Is Axios worth using? We would save ourselves the problem and time of rewriting all Services to an entirely new API.

So, does the built-in HTTP client have any use?

There are some reasons why AngularJS/Angular have their HTTP clients.

In both frameworks, the respective HTTP clients tie into the change detection system, automatically triggering a change detection as soon as a response is received.

If we use fetch() or Axios, we might need to handle that ourselves. This is not necessarily prohibitively complicated, but it’s worth remembering.

Another difference in AngularJS that could break your application if not addressed is that the built-in HTTP client returns $q promises, the AngularJS’s built-in promise type rather than regular Promise instances. So it is worth paying attention to what type is returned from the services and considering this argument when making a decision about the HTTP client.

Another difference worth mentioning when using fetch() is that it does not support some features offered by built-in clients, such as request/response interception, transformations, etc.

One last difference between fetch() and Axios is that they might be a little less easy to handle in tests compared to the built-in HTTP clients, which offer utilities that make testing easier.

With the above in mind, we should decide on the HTTP client based on our goals and objectives.

Summary

I am not trying to convince anyone that Axios is better than HttpClient. But I hope I have succeeded in getting you to reflect on the future of your application. Perhaps years from now, Angular will be another completely different framework implementing a new API. Regardless, using a framework-agnostic library like Axios will ensure that your code that fetches data will look and function similarly!

Sample application code based on AngularJS and Axios is available in this GitHub repository.

Looking for more support for your Angular projects?

Our team at DevIntent is highly experienced in web development, including framework migration and updates. Check out our offerings or reach out.

Image by upklyak on Freepik

When evaluating a migration strategy, one of the first questions is whether to use internal resources or partner with a migration expert. Initially, in-house migrations often feel like the easier choice, and the sticker shock can scare some away from bringing in outside help.

However, internal teams can become overwhelmed with competing priorities or need more technical expertise, causing the migration to drag on for years or, worse yet, never reach successful completion. With a closer look, you’ll find the upfront costs of a partner return significant savings from many angles over the life of the project.

Let’s see how partnering with a migration expert helps save time and money while achieving a successful migration.

Top Line Growth

Migrations to newer web application platforms are an experienced migration architect’s specialty. Their migration-specific expertise provides a blueprint for your application to work right, not only when the migration is complete but also along the way. By deploying a hybrid environment, they can ensure the application will be in a workable and releasable state throughout the migration. Compared to attempting a migration in-house, this is a significant advantage that allows your team to focus on the core business goals of developing new features and applications that grow your top and bottom line.

In-house Developer vs. Expert Migration Architect

When you already have developer talent in-house, why should you trust outside help? Because a migration architect’s skillset is unique to migrations, drastically differing from a developer’s proficiency in writing application code. The mammoth undertaking of ramping up your team’s knowledge for a successful platform migration is a legacy tech investment that won’t result in an ROI. You’ve burnt months or years of valuable time preparing for an undertaking having high odds of failure. Instead, by using an expert partner, you can have confidence in your approach while significantly increasing your success rate and starting your migration immediately.

Budgeting

A migration expert can complete the project with fewer costs and a shorter delivery time when compared to using in-house resources. Additionally, you’ll have confidence the correct route was taken, not requiring costly revisits to address something twice. You can get where you need to go faster and at a lower cost than in-house. Depending on your budget allocations, you can dynamically throttle up your project’s momentum with fully dedicated migration services or with consistently dedicated part-time work.

Stops the Bleeding

Stops the accumulation of technical debt by ceasing the creation of antiquated end-of-life code. Each incrementally migrated module is proven to work when complete, not just verified at the end of the migration. Further application development, like fixes and new features, can continue alongside the migration. Your team can quickly develop on a modern platform, improving your application performance and security while reducing implementation times for new features.

Head Count

No need to hire, train, or maintain migration-specific talent for the project, allowing you to avoid overhead costs and the time spent recruiting. Choosing to upskill internal talent for a migration comes with considerable risk. Many developers are unwilling to learn competencies on a deprecated platform or lack the spare time required. There are also chances of a fatal architecture error or newly trained developers transitioning away from the project part-way through. These obstacles could leave you upside down with a broken application or scrambling to hire replacements with a skill set that’s becoming obsolete.

Risk Management

You mitigate substantial risk by involving a proven web application migration expert early in the planning stages. Common errors avoided include confusing the easiest migration path as optimal for your future needs, choosing the incorrect migration tools, or not knowing when an app is better suited for a complete rewrite. Ultimately all these things could have severe negative consequences and huge costs associated.

Conclusions

The points above demonstrate a compelling business case of how teaming with a migration expert saves money and time. Whether you’re in the planning stages of a migration, stuck in a perpetual rut of deciding which platform to move to, or stalled halfway through, help is available. Keep your momentum moving forward and project on target without breaking the bank.

To learn more about the best path for your business, schedule a quick introductory chat with our team.

What is dark mode, and how to control it

Dark mode is a color scheme optimized for use in a low-light environment. Usually, it inverts the traditional color combination and uses light letters on a dark background. Light or dark mode is controlled by either the operating system or the browser. On macOS, you can select one of three options:

• always light
• always dark
• auto—light during the day and dark at night

Some browsers—for example, Firefox—either use a theme based on the OS setting or allow the user to override it on the browser level.

How do websites use switch to dark mode to respect users' preferences? With the media query option prefers-color-scheme, which is supported by 93% of browsers according to Can I use data.

How other websites look in dark mode

Many websites already switch to dark mode automatically based on the users' preferences. For example:

Google:

Twitter:

Why you should support it as well

As others have pointed out, supporting dark mode increases accessibility for your web application. Some visual impairments cause users to prefer viewing websites and applications in dark mode. Thus, by implementing it in your application, you make sure everyone in your user base can use your product effectively.

Besides accessibility concerns, for many users, dark mode is their preferred way of using applications. When the operating system is set to dark mode, most of the interface elements become dark. With many applications and websites following this setting, any application that sticks to the bright colors stands out negatively because it forces the bright colors onto the user.

Example with CSS variables

In order to support two color schemes on your website, every color on your website has to be set twice—for the light and the dark mode. To avoid code duplication, you can use native CSS variables—they have widespread support (source):

You can use it very easily in any web application. You define two files defining variables:

styles.light.css:

:root {
  --main-bg-color: #fafafa;
  --main-color: #000000de;
}

styles.dark.css:

:root {
  --main-bg-color: #303030;
  --main-color: #fff;
}

Then, in your main style file you use those variables for styling and import the color mode file based on user preferences.

styles.css:

@import url("styles.light.css") (prefers-color-scheme: light);
@import url("styles.dark.css") (prefers-color-scheme: dark);

body {
  background-color: var(--main-bg-color);
  color: var(--main-color);
}

Here you can find the example code, and the website in action

Depending on your use case, you may need some fallback values to ensure support for older browsers, styles.css with fallback:

body {
  background-color: #fafafa;
  background-color: var(--main-bg-color);
  color: #000000de;
  color: var(--main-color);
}

Looking for more support for your Angular projects?

Our team at DevIntent is highly experienced in web development, including framework migration and updates. Check out our offerings or reach out.

Let's get started!

Performance

From performance at scale, to tuning, to general best practices, web application performance was a big topic at ng-conf 2022. While we didn't have the opportunity to attend every presentation, we picked out a few highlights we thought were particularly valuable.

Lara Newsom's "The Tell-Tale Code" listed three standard Angular Code Smells:

• Calling functions inside Angular templates causes our method to be called multiple times instead of once
• Optional chaining EVERYTHING, which, when misused, increases the size of the bundle
• Tightly coupled component logic, which will require significant refactoring at a later stage for the application to be maintained and scaled appropriately because it can cause a loss of reusability of components or difficulty in identifying dependencies between them

In a presentation focused on the anatomy of slow web applications, Misko Hevery shared that the amount of JavaScript code in applications has caused performance problems for even the most mature players in the space. This increase, he said, is not necessarily due to bad practices but can be attributed to the evolution of JavaScript itself. Today, JavaScript is capable of so much more and, naturally, developers want to take advantage of that increased functionality.

Misko shared that the most common problem is extraneous JavaScript code. By optimizing that code, we can correct a lot of existing performance issues, even in larger web applications. He demonstrated one method by comparing Replayable (Angular, Vue, React, Svelte), where JavaScript code is fetched from the server and executed on the browser side, and Resumable frameworks (Marko, Wiz, Qwik), where code is executed on the server side, is serialized, and then encapsulated in HTML for user interaction.

Ady Ngom presented seven basic principles to develop faster Angular applications. He mentioned that the size of the application does not matter much when discussing performance. Budget plays a key role. He shared practical strategies, like lazy loading images, optimizing event detection with ngZone, the Ivy engine, non-blocking processes, and prefetching all possible resources. These are captured in his "Angular Checklist"

• a list of practices that will help boost the performance of Angular applications.

Michael Hladky spoke to Runtime Performance, comparing the performance of a regular Angular application with a Zone-Less Angular application. He explained how event detection works in the framework and presented an efficient way of event detection and template re-rendering using the RxAngular library as an example.

Ben Lesh, in turn, mentioned a patch release for RxJS version 7.5.4, where stream operations are performed 31 times faster than in previous versions! So it's worth checking the library version you're working with.

On the last day, Houssein Djirdeh talked about Chrome browser features and improvements in the area of web application performance:

• Updated the Largest Contentful Paint (LCP) metric in version 88 - previous versions did not consider elements removed from the DOM tree
• Automatically inline Google Fonts and critical CSS, so we don't have to make additional HTTP requests
• Image optimization during build time thanks to the new NgOptimizedImage module, which enforces best practices

Finally, we got to experience a deep dive into image optimization best practices for Angular, presented by Kara Erickson during her session called "Image Optimization Best Practices with Angular".

Security

Security is one of the greatest challenges in software development. It is a critical defense mechanism meant to cover any potentially vulnerable surfaces, as it's impossible to predict every form an attack may come in. However, despite its inherent importance, security is often overlooked or treated as an afterthought during development.

After all, we count on the framework to do the security work for us, and the rest of the dependencies… well, since they have been released for production, they should be safe, right? :) Of course not!

In their cleverly-named presentation, "OAyDaBy AAmn=/y SAinRe9L TArT, wait what?" Jessica Janiuk and Joey Perrot raised topics related to the security of the Angular framework. They covered topics on secure software development, operations to deploy and run applications securely in production, and how to ensure that applications are protected by default when using Angular.

Alisa Duncan's session, on the other hand, focused on the TOP 2 OWASP vulnerabilities from 2021:

• Broken Access Control, which is the failure to properly enforce policies such that users cannot act outside their intended permissions
• Injection - the attacker sends data to an application in a way that will change the meaning of commands being sent to an interpreter.

She highlighted what can happen when an attacker has elevated access within the application and explained some of the defenses we have against these attacks, both built into Angular and what we can do ourselves, as developers.

Architecture

As you might expect, architecture was another topic covered in more than a few presentations.

One of our consultants, Alain Chautard, walked us through creating generic components with content projection on Thursday, using the Dialog and Tabs Components in an example.

Manfred Steyer focused on topics related to Micro-frontend architecture and Webpack Module Federation. He discussed Static and Dynamic Federation configuration and showed how to share libraries and modules between independent applications.

In a similar vein, Adrian Iskandar Espinosa Caballero discussed some advantages of using Micro frontends, namely:

• Scalability
• Reusability
• Visual Continuity

Both speakers presented sample Micro-frontend applications using React, AngularJS, and various versions of Angular.

There were also topics related to Monorepos, which have Nx at their heart. Michael Madsen and Erik Slack presented 20 reasons why you should use Nx.

There was also a session on state management using NgRx as an example. Kate Sky and, in a later session, Brandon Roberts talked about some of the best and worst (or suboptimal, at least) practices for using NgRx. They also discussed separating smart and presentational components, clean code, and state management in a monorepo, using Nx as an example.

In another session, Mike Ryan and Brandon Roberts presented the new v14 version of NgRx and its features, such as createActionGroup, the new API for Standalone Components, and @ngrx/eslint-plugin. The topic of new features in NgRx was continued by Marko Stanimirović, discussing the createFeature function that can help us to reduce repetitive code in selector files.

The session with Pawel Kozlowski provided some additional insight into Standalone Components. We learned more about their power, motivation, and how they differ from NgModules. We also found how we can use Standalone Components to drastically reduce the number of lines of code and can break inheritance restrictions.

Manfred Steyer, on the other hand, in his talk on Standalone Components, showed us route handling in an application without NgModules and a recommendation for file and folder structure in such applications.

In his session, Mike Ryan demonstrated ComponentStore in action using a sample drawing application as an example. He explained best practices for sharing states between components, managing streams and lifecycle Subscriptions, decoupling component logic, removing responsibility outside the element, and making them easier to read, write, and test.

We found Ward Bell's session on validating Reactive Forms to be particularly enlightening. He talked about frontend architecture and its role in form validation. He said that it's the model that sets the rules, not the UI; that it's the model that should know if a field is required, not the UI; and that it's the model that should understand the relationships between fields in different forms on a page. He also demonstrated what the model could look like using the ngc-validate library. Ward’s fuchsia-colored outfit also attracted considerable attention. So if you were looking for Ward at the conference, you had no problem recognizing him :)

In the last session of the conference, Deborah Kurata discussed best practices for RxJS, mentioned the declarative approach, and the differences between different Higher-Order Maps.

Final thoughts

The conference ended with a Q&A session with the Angular Team, during which attendees asked questions for nearly an hour. Among other things, they asked about ngUpgrade support for Standalone Components and the future of Observables in Angular. It was an excellent opportunity for the community to learn about the upcoming but more distant plans for the framework.

Each of the three days of the conference presented fascinating information and touched on the essential aspects of Angular development and its community. There were topics on Angular's history, current best practices, and items still in the pipeline.

What were my takeaways? First, I gained a better understanding of the mechanisms under Angular's hood, learned more about the causes of poor performance in web applications, and the power of Standalone Components.

I'm particularly looking forward to doing tests using the new NgOptimizedImage module and playing around with RxAngular a bit more. I'm also curious about the new Qwik framework offering, according to Miško Hevery, the fastest possible page load times.

The only thing I missed was a lack of topics related to hybrid architecture that didn't depend upon using Micro frontends. The Angular Team officially stopped supporting the AngularJS framework in December 2021, but many projects are stuck on the old framework with no clear path for migrating to the latest version of Angular.

Hopefully, the materials from the conference will be released soon. It's worth checking out the videos when they are published, and you have spare time. Next year, I hope there will be another ng-conf, may it be as successful!

Thank you for your attention!

Looking for more support for your Angular projects?

Our team at DevIntent is highly experienced in web development, including framework migration and updates. Check out our offerings or reach out.

Imagine that you have an application where you display different content depending on the size of the screen. There are different ways to solve this issue, for example with @media css. Media queries with CSS is really helpful, but if we have business logic to implement depending on the screen size, creating custom classes with separate CSS just to handle these kinds of problems will create unnecessary chaos in our project.

This is where Angular CDK jumps in. In this article, we will focus on the solution provided by the Angular team, the two main classes from @angular/cdk/layout package: BreakpointObserver and MediaMatcher. We will also build an application that will track changes in the screen size and display different content depending on the resolution.

Let's get started!

Angular CDK Layout

The layout package helps to build responsive UIs that react to screen-size changes. With it, we can catch any resize and know when the screen exits or enters a breakpoint.

Prerequisites

If you would like to follow along with this article, you will need:

• Node.js installed locally
• @angular/cli installed globally

In this article, the examples are based on Angular CLI 14.2.2 and Node 16.13.1.

Project Setup

Let's open a terminal, navigate to the directory where we want to create the project, and type:

ng new cdk-breakpointobserver-example

It will create and initialize a new Angular application.

Navigate to the newly created project and install @angular/cdk package:

npm i --save @angular/cdk

To use services from Layout Module, we will first need to import it. Lets do that in app.module:

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { BrowserAnimationsModule } from '@angular/platform-browser/animations';
import { LayoutModule } from '@angular/cdk/layout';
import { MatCardModule } from '@angular/material/card';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    BrowserAnimationsModule,
    LayoutModule,
    MatCardModule,
  ],
  bootstrap: [AppComponent]
})
export class AppModule {}

Now we can start using the available utilities from the LayoutModule.

BreakpointObserver

BreakpointObserver lets you evaluate media queries to determine the current screen size and react to changes when the viewport size crosses a breakpoint.

export declare class BreakpointObserver implements OnDestroy {
  isMatched(value: string | readonly string[]): boolean;

  observe(value: string | readonly string[]): Observable<BreakpointState>;
  ...
}

There are two main methods defined in the class: observe and isMatched. The observe method is used to observe when the screen-size changes between different [breakpoints](when the viewport changes between a matching media query). The isMatched tells us whether one or more media queries match the current viewport size.

MediaMatcher

MediaMatcher is a low-level utility that wraps around JavaScript’s matchMedia, which can be used to get a native MediaQueryList.

export declare class MediaMatcher {
  matchMedia(query: string): MediaQueryList;
  ...
}

As we can see, it gives us access to the native MediaQueryList object through the public method matchMedia .

BreakpointObserver and MediaMatcher in action

Let's return to our application. We want to track the changes of the viewport size, and also list the values of each predefined breakpoint.

To do this, we need to inject BreakpointObserver and MediaMatcher into the class constructor and call the observe and matchMedia methods for class instances.

import {ChangeDetectionStrategy, Component, OnInit} from '@angular/core';
import {BreakpointObserver, Breakpoints, BreakpointState, MediaMatcher} from '@angular/cdk/layout';
import {Observable} from 'rxjs';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class AppComponent implements OnInit {
  breakpointsInfo: {name: string, value: MediaQueryList}[] = [];
  breakpointState: Observable<BreakpointState> | undefined;
  xSmall: string = Breakpoints.XSmall;
  small: string = Breakpoints.Small;
  medium: string = Breakpoints.Medium;
  large: string = Breakpoints.Large;
  xLarge: string = Breakpoints.XLarge;
  webLandscape: string = Breakpoints.WebLandscape;

  constructor(public breakpointObserver: BreakpointObserver, private mediaMatcher: MediaMatcher) {}

  ngOnInit(): void {
    this.breakpointsInfo = this.getBreakpointsInfo();

    this.breakpointState = this.breakpointObserver.observe([
      Breakpoints.XSmall,
      Breakpoints.Small,
      Breakpoints.Medium,
      Breakpoints.Large,
      Breakpoints.XLarge,
      Breakpoints.WebLandscape,
      Breakpoints.WebPortrait,
    ])
  }

  getBreakpointsInfo(): {name: string, value: MediaQueryList}[] {
    return [
      Breakpoints.XSmall,
      Breakpoints.Small,
      Breakpoints.Medium,
      Breakpoints.Large,
      Breakpoints.XLarge,
      Breakpoints.Web,
      Breakpoints.WebLandscape,
      Breakpoints.WebPortrait,
      Breakpoints.Handset,
      Breakpoints.HandsetLandscape,
      Breakpoints.HandsetPortrait,
      Breakpoints.Tablet,
      Breakpoints.TabletLandscape,
      Breakpoints.TabletPortrait
    ].map((breakpoint, index) => ({name: Object.keys(Breakpoints)[index], value: this.mediaMatcher.matchMedia(breakpoint)}));
  }
}

The observe method returns Observable of BreakpointState type, that we need to subscribe to for observing when the viewport of your application changes. We can do this manually in the component class with subscribe method, or in the component template with async pipe.

<div *ngIf="breakpointState | async as state" style="display: flex; gap: 10px">
  <h2 *ngIf="state.breakpoints[xSmall]">Breakpoint: Extra Small</h2>
  <h2 *ngIf="state.breakpoints[small]">Breakpoint: Small</h2>
  <h2 *ngIf="state.breakpoints[medium]">Breakpoint: Medium</h2>
  <h2 *ngIf="state.breakpoints[large]">Breakpoint: Large</h2>
  <h2 *ngIf="state.breakpoints[xLarge]">Breakpoint: Extra Large</h2>
  <h2>Orientation: {{ breakpointObserver.isMatched(webLandscape) ? 'Landscape' : 'Portrait' }}</h2>
</div>

It is worth adding that we can listen for non-standard breakpoints that we define ourselves:

this.breakpointObserver.observe(['(min-width: 500px)'])

To additionally display information about the value of individual Breakpoints, we need to loop through breakpointsInfo collection and display the values of the name and value property:

<mat-card>
  <mat-card-title>Breakpoints ranges</mat-card-title>
  <mat-card-content>
    <ul>
      <li *ngFor="let breakpoint of breakpointsInfo">
        <p><strong>{{breakpoint.name}}</strong>: {{breakpoint.value.media}}</p>
      </li>
    </ul>
  </mat-card-content>
</mat-card>

As a result, we should see the following effect:

Conclusions

We saw how to react to viewport size changes using BreakpointObserver and MediaMatcher classes. We can easily handle the elements of business logic, not being limited only to files with the styles, but also have control over them in the component and its template.

Source code with a working application described in the article can be found on the GitHub repository.

Thank you for your attention!

Looking for more support for your Angular projects?

Our team at DevIntent is highly experienced in web development, including framework migration and updates. Check out our offerings or reach out.

What is Playwright

Playwright is developed by Microsoft—the company that brought us TypeScript. It has a large following on GitHub; with 40k stars, and almost 2k forks, it is one of the most popular open-source projects for E2E testing.

How Playwright works

Playwright runs tests and controls the browser from the outside. The test runner runs the test scripts, controls the browsers via API, and doesn't share the execution context with the application—the same approach as in Protractor or Selenium.

Strengths

Because Playwright tests run outside the browser, there is a bigger choice of languages in which you can write your tests: you’re not restricted to just JS or its flavors like in Protractor, Cypress, or Nightwatch.js. Currently, you can write your test in:

• JavaScript
• Python
• Java
• .Net

This provides the flexibility to adapt the tests to the project and pick the language to get the most out of the skills you have available within your team.

Playwright allows you to run your tests in major browsers:

• Chromium (Chrome and Edge)
• Firefox
• WebKit (Safari)

Playwright emphasizes speed, and according to this article, they deliver on that.

Example tests

Let's take a look at an example test suite in Playwright.

Application

The application we will test is the final step from the official Angular tutorial Tour of Heroes. You can find the repository with the example code here.

Configuration updates

An easy way to initialize the Playwright tests in a project is to run:

For easy access to running the tests, let's update package.json:

With this change, npm run e2e will run Playwright with the default configuration—running tests on three headless browsers: Chromium, Firefox, and WebKit. Headless runs are faster and happen in isolation from the user, but they make debugging tests more difficult. For this, we have npm run e2e:debug, starting with only one visible browser.

Tests

Example tests in tests/example.spec.ts:

import { test, expect, type Page } from '@playwright/test';

test.describe('Tour of Heroes pages', () => {
  test('should load default route', async ({page}) => {
    await page.goto('http://localhost:4200');

    await expect(page).toHaveURL(/\/dashboard$/);
  });

  test('should allow edits', async ({page}) => {
    await page.goto('http://localhost:4200');

    await page.locator('[data-test="detail-link"]').first().click();

    await expect(page).toHaveURL(/\/detail\/\d+/);

    await page.locator('#hero-name').fill('lorem ipsum');

    await page.locator('[data-test="save-button"]').click();

    await expect(page.locator('[data-test="detail-link"]').first()).toContainText('lorem ipsum');
  });

  test('should search for heroes', async ({page}) => {
    await page.goto('http://localhost:4200');

    await page.locator('#search-box').fill('nice');

    await expect(page.locator('[data-test="search-result-link"]')).toHaveCount(1);

    await page.locator('[data-test="search-result-link"]').click();

    await expect(page).toHaveURL(/\/detail\/12/);
  });

  test('should delete heroes', async ({page}) => {
    await page.goto('http://localhost:4200/heroes');

    await expect(page.locator('.delete')).toHaveCount(9);

    await page.locator('.delete').first().click();

    await expect(page.locator('.delete')).toHaveCount(8);
  });

  test('should add heroes', async ({page}) => {
    await page.goto('http://localhost:4200/heroes');

    await page.locator('#new-hero').fill('Lorem Ipsum');

    await page.locator('.add-button').click();

    await expect(page.locator('.delete')).toHaveCount(10);
  });
});

The way of organizing tests in Playwright is similar to how it’s done in Protractor or Cypress. The API is returning promises, and we use await to ensure that each step is done executing before the next one is started.

Running tests

To run tests, we need to start the application server in the background:

$ npm run start

> angular.io-example@0.0.0 start
> ng serve

…

** Angular Live Development Server is listening on localhost:4200. Open your browser on http://localhost:4200/ **

…

✔ Compiled successfully.

With the server running, we can run all tests with:

Summary

As you see, setting E2E tests with Playwright for Angular applications is pretty straightforward. Thanks to its broad language support, you can choose a language depending on what skills are available in your team. E2E tests are an essential tool to maintain a high quality of an application in fast-moving teams.

Looking for more support for your Angular projects?

Our team at DevIntent is highly experienced in Angular development, testing, and software quality. If you'd like to chat about how we can help you, please contact us at sales@devintent.com.

AngularJS End-of-Life

On July 1, 2018, AngularJS entered its Long-term Support (LTS) period. The support was originally scheduled to end on June 30th, 2021.

Given the COVID-19 pandemic and its impact on teams migrating from AngularJS, the Google team extended the LTS for another 6 months, until December 31st, 2021.

As of January 1st, 2022 AngularJS has reached End-of-Life. You can read more about it on the official Angular blog in Discontinued Long Term Support for AngularJS. For those who are still using this framework, it will have a profound impact on their development and support plans. AngularJS will not receive patches for security vulnerabilities or breaking issues caused by new browser releases.

What if you are still using AngularJS?

Now that AngularJS has reached its End-of-Life, AngularJS applications will continue to function, at least until the next breaking browser change happens.

Nevertheless, using old versions of the framework is critical to the security of your application and your user's data. Since security patches will no longer be provided by Google, your business and your customers may be vulnerable to new / previously unknown security threats. Before a major vulnerability is disclosed to the public or there is an announcement that it is being exploited in the wild, you will need to have a mitigation plan in place.

What options do you have?

Get up to date

If your project is based on an older version of AngularJS, consider upgrading to AngularJS 1.8.2. The latest version of AngularJS improves security, imposes a component-based architecture, fixes a few bugs and will make the process of migrating to modern Angular much faster. If you aren't on AngularJS 1.8.0, or later, then your application and your users are already exposed to a range of security vulnerabilities, including Cross-site Scripting (XSS) attacks. Get protected now, by updating to the latest AngularJS version, if you haven't already done so!

Extend your support

You can get Extended Long-term Support via XLTS for AngularJS from XLTS.dev. This will allow you to continue developing or maintaining your application while using supported software. This means that you will receive fixes for security vulnerabilities and breakages to browsers or jQuery when they occur. If you have regulatory or other compliance obligations, this can help you stay compliant and get the customer approvals that your business needs.

Hybrid application migration

If you're ready to start migrating your legacy AngularJS application to modern Angular, a good first step is to refactor your application step-by-step, module by module, creating a hybrid AngularJS/Angular application. Using this hybrid approach minimizes risk since small chunks of your existing application can be migrated and tested. Using the ngUpgrade tool, you can mix and match AngularJS and Angular code in the same application and ensure their smooth cooperation.

Rewriting from scratch

If your current AngularJS application is small and the business logic and other requirements are well-documented, you may be able to perform a full re-write in a modern framework (e.g. Angular, React, Vue, etc.) without running into major issues. A full rewrite is a riskier approach for large or medium-sized applications. Careful planning, selection of the right tools/technologies, and building a team with the right skill-sets is necessary to avoid broken/missing functionality, costly delays, or even complete project failure.

Still unsure? In need of expert assistance?

If you require expert assistance or are unsure how to identify the best solution for your project, DevIntent has the expertise to help. Contact us at consulting@devintent.com to get in touch. We have worked with many enterprise and mid-sized companies since 2013 to help them update and migrate their AngularJS 1.x based applications. We can help make your Angular or AngularJS project a success.

Are you an experienced AngularJS developer?

We are hiring! As part of the DevIntent team, you’ll get to work with current and former members of the Angular team, as well as other experts from the Angular Community.

Apply today at careers@devintent.com to join us in moving the Angular community forward from AngularJS.

Angular v13 is here 🎉#ngUpdate for built-in improvements like:
- Faster prod builds
- Enhanced component a11y
- Improved test times and debugging
- Modern Angular Package Format

Read more:
📚 https://t.co/dx1HzBY9z6

Join us Friday at 10am PST:
📅 https://t.co/6GGtgkJDpl pic.twitter.com/ZZqIpja50M

It's been six months since the last major version of the Angular framework was released. A completely new version of Angular has just been released.

In this article we'll look at some features and updates that will help you create amazing applications. We will go through a few optimizations of the Ivy engine. We will also talk about what is being deprecated and briefly discuss the process of migrating the application to Angular v13.

So let's get started!

Upgrade to Angular v13

With the release of the new version, the Angular team provides a complete guide to upgrade from previous versions. By following the guide, you shouldn't have any problems with getting migrated to the latest version.

If you are using Nx, please follow the guidelines provided by the Nwrl team. By running nx migrate latest, you will also update Angular and all its dependencies.

Angular dependency updates

In the latest release of Angular, there are also changes in the dependencies of the framework. Angular v13 introduces TypeScript 4.4 support, which means that we can now use its new features. Support for older versions of TypeScript has been dropped.

Moreover, version 7.4 is now the default version for RxJs. To learn more about the changes from version 6 to version 7, please read this article.

Additionally, Angular v13 has dropped support for NodeJS versions below v12.20.0 and has introduced support for NodeJS >=16.10.

IE11 support dropped

And it happened. IE11 is no longer supported by Angular v13. This is one of the most important pieces of news for this release. Dropping support for IE11 is a good thing - it means Angular gets to fully embrace the Web APIs of modern browsers. It also means that we no longer have to include polyfills for IE, which makes applications lighter and load faster than in previous versions of Angular. It is worth noting that the migration process described previously will automatically remove polyfills for IE.

The Angular team put out an RFC (request for comments) about dropping IE11 support, and the feedback they received was overwhelmingly in favor of doing so.

Note that Angular 12 will continue to support IE11 until November 2022.

Ivy FTW

Ivy FTW View Engine

As promised in past announcements, Angular version 13 no longer supports the old rendering View Engine. For the average Angular dev, this doesn't mean much (other than reaping the benefits of a more performant framework). For library builders in Angular, though, this is a big deal.

As mentioned in the official announcement, removing View Engine also means that Angular can reduce its reliance on ngcc (Angular compatibility compiler) in the future, and teams can look forward to faster compilation because metadata and summary files are no longer included.

Angular Package Format (APF)

As mentioned in the official announcement, the Angular Package Format (APF) has been streamlined and modernized to better serve developers. To streamline the APF in Angular v13, older output formats such as CommonJS (CJS) and UMD have been removed. Thanks to this change, the whole Web community will be better off once ES Modules (ESM) are used everywhere.

Angular v13 will ship with the most modern version of APF (Angular Package Format): ES Modules+ES2020

If you've ever maintained an npm library, you know how hard it is to come up with the right package format that is modern & works for most use-cases! 🚀https://t.co/A8HPqixfKk

— Igor Minar (@IgorMinar) November 2, 2021

The Angular team has also updated the APF to support Node Package Exports. This will help developers from inadvertently relying on internal APIs that may change.

It is now time for Angular library authors to stop using enableIvy: false, and to instead use compilationMode: partial (in tsconfig.prod.json), as recommended by Younes.

⏳ tired of ngcc?

🚀 get ready for #Angular 13!

🧹 meanwhile, fellow library authors, let's move from "enableIvy: false" to "compilationMode: partial"
Cf. https://t.co/8ahrmiUp5R#javascript pic.twitter.com/iXL541Ui1Z

— Younes (@yjaaidi) November 2, 2021

The partial compilation mode is a partial-Ivy code format that is stable between different versions of Angular, and thus safe to publish to npm. Angular code that uses this partial format is processed during the build of the application using the same version of the Angular compiler. The benefit is that both the application and its libraries rely on a single version of Angular, removing potential compatibility issues.

Existing libraries will be automatically migrated to use “partial” compilation mode and some metadata previously required for the legacy View engine will be removed.

To learn more check out the official guidelines for library authors.

Create components dynamically from API updates

Ivy enables a simpler way to create dynamic components. Angular no longer requires component factories to dynamically create components. Ivy creates the opportunity to instantiate the component with ViewContainerRef.createComponent without creating an associated factory. So, instead of:

@Directive({...})
export class CustomyDirective {
  constructor(
    private viewContainerRef: ViewContainerRef,
    private componentFactoryResolver: ComponentFactoryResolver
  ) {
  }

  createCustomComponent() {
    const componentFactory = this.componentFactoryResolver.resolveComponentFactory(CustomComponent);
    this.viewContainerRef.createComponent(componentFactory);
  }
}

We can now write:

@Directive({...})
export class CustomDirective {
  constructor(private viewContainerRef: ViewContainerRef) {
  }

  createCustomComponent() {
    this.viewContainerRef.createComponent(CustomComponent)
  }
}

As we can see, the new approach requires much less boilerplate code!

Angular CLI improvements

With this release, Angular supports the use of persistent build cache by default, as requested by the community. The persistent build cache is a feature that caches build results on disk (under the .angular/cache folder). This results in up to 68% improvement in compilation speed.

In order to enable this feature in existing projects that have been upgrading to v13, we need to add the following configuration to angular.json:

{
  "$schema": "...",
  "cli": {
    "cache": {
      "enabled": true,
      "path": ".cache",
      "environment": "all"
      // other supported values: "ci" and "local"
    }
  }
}

We can also disable this feature (which is not recommended) with ng config cli.cache.enabled false.

If we need to clear the cache, we should delete the .angular / cache folder.

For those who use esbuild as a build tool, there is good news as well. The performance has been improved. The Angular team has introduced esbuild, which now works with terser to optimize global scripts. In addition, ESBuild supports CSS sourcemaps and can optimize global CSS, as well as optimizing all style sheets.

Router improvements

Disable a link’s navigation

Setting the routerLink directive value to null or undefined will completely disable navigation. Recall that in the previous version, the null and undefined inputs for the routerLink directive were interpreted as an empty string.

Observe router link active state

A new output for the routerLinkActive directive called isActiveChange has been added. It emits whenever the link becomes active or inactive.

Lazy load modules

The loadChildren property in the route definition no longer supports string values. It's been deprecated for a while now. This has been replaced by the ESM dynamic import statement.

Restore history

A new property has been added to Router public API

• canceledNavigationResolution , which configures how Router attempts to restore the state when a navigation is canceled.

RouterModule.forRoot(routes, {canceledNavigationResolution: 'computed'});

New events when an outlet gets attached/detached

Router now also provides new outputs for subscribing when an outlet gets attached/detached.

Other improvements and changes

• Support for question marks in query param values
• Custom route reuse strategy through dependency injection for the RouterTestingModule

  TestBed.configureTestingModule({
    imports: [RouterTestingModule],
    providers: [{provide: RouteReuseStrategy, useClass: AttachDetachReuseStrategy}]
  });

Form improvements

In this version, a little more attention is paid to Angular Forms, improving the security of reactive forms. Let's take a look at the changes.

Better type checking for form status

A specific type called FormControlStatus has been introduced, which is the union type of all possible status strings for form controls: 'VALID' | 'INVALID' | 'WAITING' | 'OFF'. Until now, we could not use Typescript checking because AbstractControl.status was entered as a string and AbstractControl.statusChanges was Observable<any>.

This is a breaking change! As mentioned in the release notes, this can break applications if an invalid form status string is used or if statusChanges events were something other than strings.

New methods to manage validators

New form methods have been added to AbstractControl:

• addValidators: Add one or more synchronous validator(s) to the control, without affecting other validators
• setValidators: Sets one or multiple validators by overriding the registered ones. For removing all registered validators we can pass a value of null
• hasValidator: Determines whether a validator or validators array has a given validator
• removeValidators: Remove synchronous validators from this control

All of these methods also have an async version: addAsyncValidators, setAsyncValidators , removeAsyncValidators, and hasAsyncValidator.

These new methods provide us with more control over the validation process. We can now easily add/remove synchronous and asynchronous validators.

Templates improvements

Angular now supports autocompletion for string literal union types . The language service of Angular is now able to automatically insert the optional chaining operator (i.e., ?.) when property access (i.e., .) is done on a nullable symbol.

Also, the fullTemplateTypeCheck compiler option has been deprecated. Instead, we should use strictTemplates .

Components improvements

Accessibility

The new version of Angular has also resulted in significant improvements and changes to the components of Angular Material.

All MDC-based components have been assessed to meet elevated a11y standards in areas such as contrast, tactile targets, ARIA, and more. For example let’s compare touch target sizes. The sizes on the right are the new sizes.

or for better support for high contrast mode for many components:

It’s always a pleasure to see large organizations put energy into improving accessibility.

Angular Material

There are also a few changes for Angular Material.

It is now possible to define content sections in test harnesses for the Dialog component. Also, a new injection token called MAT_PROGRESS_BAR_DEFAULT_OPTIONS has been added to the progress bar. It can be used to configure the default options as follows:

provide: MAT_PROGRESS_BAR_DEFAULT_OPTIONS,
useValue: {
  mode: 'buffer',
  color: 'warn'
}

Tests improvements

Together with Angular v13, TestBed has also been improved. It now takes better care of tearing down test modules and environments after each test. The DOM is now cleaned up after every test, avoiding side effects. Overall, tests should execute faster, use less memory, and be less interdependent.

The automatic teardown functionality was an opt-in feature since Angular v12.1.0 and is now enabled by default. As mentioned in the announcement, this behavior can be configured for the entire test suite via the TestBed.initTestEnvironment method:

beforeEach(() => {
  TestBed.resetTestEnvironment();
  TestBed.initTestEnvironment(
    BrowserDynamicTestingModule,
    platformBrowserDynamicTesting(),
    {
      teardown: {destroyAfterEach: true}
    }
  );
});

Or it can be configured per module by updating the TestBed.configureTestingModule method:

beforeEach(() => {
  TestBed.resetTestEnvironment();
...
  TestBed.configureTestingModule({
    declarations: [TestComp],
    teardown: {destroyAfterEach: true}
  });
});

This allows us to approach testing differently depending on the situation.

Summary

The new release of Angular introduced a lot of new improvements and minor changes, but also unlocked the way to the critical ones, such as the optional NgModules. ViewEngine is gone for good and Ivy has become ubiquitous.

This is another release that improves runtime performance, shortens build time, simplifies API, and improves tests.

Finally, I encourage you to check the full list of changes.

Until next time!

You can find the details for all releases in our Change Log.

Bug Fixes

• panel, select: fix Trusted Types violations during initialization (#12128) (4e354a6)

Code Refactoring

• sass: migrate from node-sass to sass (5e2d213)
  • If you consume our .scss files directly in your build, you will need to switch from the deprecated node-sass package to the sass package for compiling your Sass.
• sass: fix division deprecation warnings (b5a1a02)

Documentation

• fix API docs issues related to marked Markdown rendering (441a912)

Contributors

Thank you to the contributors who helped with the v1.2.4 release:

| | | :---: |:---: |:---: | Splaktar |bjarkler |superheri |

You can find the details for all releases in our Change Log.

Bug Fixes

• datepicker: ISO 8601 dates decorated as invalid in forms (0a06f99), closes #12075

Features

• menu: add a new backdropParent option (78b1073)

Contributors

Thank you to the contributors who helped with the v1.2.3 release:

| | :---: |:---: | Splaktar |atfzls |

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes bug fixes and enhancements.

• This is the final release of AngularJS Material prior to entering our Long Term Support (LTS) period.
• This release includes many accessibility and localization improvements to components like autocomplete, checkbox, datepicker, dialog, and fab speed dial.
• It fixes regressions with radio buttons in IE11 and with the datepicker modifying the model value (time) before a date is selected.
• A few long-standing issues with the fab speed dial have been fixed, significantly improving the UX of the component.

Bug Fixes

• aria: radio buttons throw argument not optional errors in IE11 (eab5c81)
• autocomplete: prevent flashing of invalid state (#12064) (a4732a9), closes #10975
• checkbox: aria-checked state is not computed correctly in all cases (c609385), closes #12046
• datepicker: null model with timezone throws exception (7856883), closes #12025
• datepicker: time is modified before even selecting a date (b406623), closes #12028 #12026
• dialog: shift+tab does not cycle through tabbable elements (7d5e262), closes #10963
• fab-speed-dial: action items are in tab order when closed (da86e62), closes #10101
• fab-speed-dial: keyboard navigation issues with tab and shift+tab (41c71ed), closes #12043
• fab-speed-dial: opens when trigger button is disabled (e7dfcc1), closes #9467
• input: check that containerCtrl.label is defined before accessing it (f79186f), closes #10831
• menu: menu focus is lost when menu-item has custom content (6391b13), closes #12054
• select: floating label hidden w/ placeholder and no value (3ea5630), closes #10116
• select: form remains valid after empty option is selected (61412b4), closes #10005
• tabs: md-align-tabs should only affect the current component (d77fbc4), closes #10541
• theming: fix CSS with nested rules parsing when registering a theme (71dc4eb), closes #9869

Features

• autocomplete: allow localization of query result announcements (5157f94), closes #11789
• chips: md-max-chips support for md-contact-chips (e6b5482), closes #10827
• datepicker: add input-aria-describedby and input-aria-labelledby (5f8472c), closes #11762

Contributors

Thank you to the contributors who helped with the v1.2.2 release:

| | | | | :---: |:---: |:---: |:---: |:---: | Splaktar |FreedCapybara |shishkinilya |kylekatarnls |natete |

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes bug fixes.

• You can now tab in and out of md-calendar when it is used in outside of a datepicker
• Calendar and Datepicker regressions related to GMT+X timezones and MomentJS custom format support have been resolved
• Fixes a regression where md-select when used with the md-select-header attribute and without the multiple attribute, closes when clicking the filter input
• Fixes a regression where the ink-bar in md-select would be black instead of using the theme color
• We now publish a list of supported screen readers on our home page
• md-icon has been updated to match the behavior defined in the docs when you provide aria-label="" or alt="", i.e. apply aria-hidden="true"
• Improved the handling of md-list-items that are clickable by screen readers
• Allow selecting the currently focused item in a radio group using the space key
• We now enable iOS long-press context menus in all AngularJS Material apps. If you don't want this behavior, you can set the -webkit-touch-callout: none; style on your app's html, body

Bug Fixes

• calendar: allow tabbing out when in standalone mode (93518bb), closes #9794
• calendar, datepicker: fix issues with GMT+X timezones (90d24cf), closes #12000
• calendar, datepicker: fix MomentJS custom format support (8f9e213), closes #12003 #11949
• datepicker: min-date validation is incorrect in GMT+X timezones (7395914), closes #11963
• dialog: remove focus trap focus listeners onRemove (33e8bac), closes #12010
• icon: providing empty alt or aria-label attributes do not hide them from a11y (37f1535), closes #10721
• list: case where list items are read twice by screen readers (5c455d3), closes #11582
• radio-button: Cannot read property 'nodeName' of null (f43ff63), closes #10546
• radio-button: support selection using the space key (3cf78a7), closes #11960
• select: respect theme color when select has focus (4afba57)
• select: in popup, hover and focus background colors are the same (d5863b8), closes #000 #9851
• select: md-select-header closes on mouse click when not using multiple (f2fca2e), closes #11969
• typography: enable iOS long-press context menus (3d98b6e), closes #10622

Documentation

• mdSticky: update and clarify the usage and behavior (0d431e0)
• a11y: add a list of supported screen readers (8ce0813), closes #11449
• home: simplify and clarify that browser support policy is for major versions (1babe8c)
• icon: documentation refinement and cleanup (c644d6a)

Contributors

Thank you to the contributors who helped with the v1.2.1 release:

| | | | | | :------------------------------------------------------------------------------------------------------------------------------: | :-------------------------------------------------------------------------------------------------------------------------------: | :-----------------------------------------------------------------------------------------------------------------------------------------: | :--------------------------------------------------------------------------------------------------------------------: | | Splaktar | mmalerba | josephperrott | cgx |

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes bug fixes.

• Fixes a regression that broke MomentJS custom format support

This is the last planned patch release for the 1.1.x release branch. Future patch releases will be based upon the 1.2.x release branch.

Bug Fixes

• calendar, datepicker: fix MomentJS custom format support (667a78f), closes #12003 #11949

Contributors

Thank you to the contributors who helped with the v1.1.26 release:

| | | | :------------------------------------------------------------------------------------------------------------------------------: | :-------------------------------------------------------------------------------------------------------------------------------: | | Splaktar | mmalerba |

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes bug fixes.

• Fixes a regression where md-select when used with the md-select-header attribute and without the multiple attribute, closes when clicking the filter input
• Fixes date selection and min-date validation issues in GMT+X timezones

Known Issues

• There is a regression that broke MomentJS custom format support. Fixed in 1.1.26 via PR #12006.

Bug Fixes

• calendar, datepicker: fix date selection issues with GMT+X timezones (a897a67), closes #12000
• datepicker: min-date validation is incorrect in GMT+X timezones (dd150fa), closes #11963
• select: md-select-header closes on mouse click when not using multiple (b32b473), closes #11969

Contributors

Thank you to the contributors who helped with the v1.1.25 release:

| | | | :------------------------------------------------------------------------------------------------------------------------------: | :-----------------------------------------------------------------------------------------------------------------------------: | | Splaktar | jelbourn |

You can find the details for all releases in our Change Log.

Highlights

This is a major release that includes breaking changes, deprecation removals, enhancements, and bug fixes.

• Long awaited updates to align with the Material Design (2017) Specification, including:
• Button
• Checkbox
• Chips
• Input and Input Container
• List
• Tabs
• Palette contrast colors
• Toolbar
• More robust opacity and contrast configuration for theming to meet the AA level of the WAI-ARIA accessibility guidelines.
• The full minified CSS is now 24 KB smaller. This translates to 3 KB smaller (37 KB) gzipped.
• Fixes and docs for aligning form components using containers with the md-inline-form class.
• New Sass mixin (auto-horizontal-margin($selector)) for more easily laying out components in layout="row" containers.
• See below for the details on breaking changes.

Known Issues

• min-date validation in md-datepicker is broken for GMT+T timezones #11963.

Bug Fixes

• autocomplete: change md-escape-options default to 'clear' (47106ba), closes #11767
• button: horizontal padding should match the spec (3205b33), closes #10535 #10535
• checkbox: handle links in transcluded label in an a11y-friendly way (4d36fd2), closes #11134
• checkbox: update CSS to match spec (c893050), closes #9351 #9927 #8713
• checkbox, date-picker, input, radio-button, select, switch: md-inline-form support (b3e9ffe)
• chips: chip remove icon isn't sized to match the spec (#10491) (29c0a4a), closes #9619
• chips: placeholder is truncated even though there is room (aa4e29b), closes #10630
• chips: update to latest Material Design spec (2017) updates (01351b1), closes #9883
• datepicker: support ng-model-options timezone w/ Moment (e24d09c), closes #11945 #10598
• input-container: align indentation with spec (31a596f), closes #10105 #11421
• list: fix checkbox alignment and match dense heights to spec (a13722e), closes #11966
• nav-bar: throws exception when indexing null tabs variable (b1c7154), closes #11964
• panel: demos need to access locals in controller's \$onInit (6e91c62)
• panel: don't throw exceptions when the groupName is a string (4178459)
• radio-button: when no value selected, first button not announced on focus (9159384), closes #11973 #11923 #11974
• select: support for md-inline-form, more configurable SCSS (0d4d37f), closes #8712 #8716
• select: md-select-header closes on mouse click when not using multiple (f2fca2e), closes #11969
• tabs: update min-width to follow the spec (693ecca), closes #10406 #11432
• tabs: align theming with spec updates (d237715), closes #7685
• theming: dark contrast used incorrectly when only contrastStrongLightColors defined (4e3f7a7)
• theming: update palette contrast types to current spec (d716fde), closes #8992 #10164
• theming, toolbar, subheader, input: align color palettes and contrasts with AA standards (3a291ac), closes #8992 #10164 #8993
• toast: improve position handling to better align with docs (96ec741), closes #11843
• toolbar: input placeholders and ink need more contrast (a82fc93), closes #7987 #11376
• toolbar: default to 500 hue and contrasts when using accent/warn palettes (98a94db), closes #7685

Code Refactoring

• autofocus: remove deprecated md-auto-focus attribute (bf0ec8c)
• card: remove styles for md-actions class (75aa734)
• chips: remove deprecated md-on-append attribute (1a2e3d0)
• chips: remove deprecated MdChipsCtrl.selectAndFocusChip (01d2cde)
• dialog: remove deprecated content options and methods (e3b52a0)
• dialog: remove styles for deprecated md-actions class (93e2081)
• layout: remove deprecated -lt- ("less than") attributes (e8e785e)
• \$mdCompilerProvider: remove deprecated \$mdCompilerProvider.respectPreAssignBindingsEnabled() (579a327)
• menu: removed deprecated \$mdOpenMenu API (f023ce7)
• panel: remove deprecated MdPanelRef.addClass/removeClass/toggleClass (bafbd96), closes #9310
• select: rename ngMultiple to mdMultiple (4c75858)
• sidenav: remove deprecated access to \$media in md-is-locked-open (baa7563)
• sidenav: remove md-sidenav-focus directive (8fc36d4)
• theming: remove support for deprecated \$mdThemingProviderTheme.primaryColor() and related APIs (00a50de)
• tabs: remove deprecated md-no-disconnect (05bee8f)
• toast: remove deprecated content() method and option and updateContent() method (cf3d56c)

Features

• layout: add mixin for responsive support of rows (c2c336b), closes #9112 #9220
• theming: add contrast opacity values for all color types and hues (68c1d02)

Documentation

• theming, colors: md-colors demo was broken. improve JSDoc and fix lint issues (01917b3)

BREAKING CHANGES

• autocomplete: The default behavior of md-autocomplete, when the options panel is visible and the Escape key is pressed, has changed. md-escape-options now defaults to 'clear' instead of 'blur clear'. This better aligns with the WAI-ARIA Authoring Practices as the focus is not sent to another element (like the <body>) when the Escape key is pressed.

If you want to restore the previous behavior, add the following to your md-autocomplete components:

md-escape-options="blur clear"

• autofocus: Removed the deprecated md-auto-focus directive. It was deprecated in favor of md-autofocus. Please see the md-autofocus Docs for examples.
• button: md-button's internal horizontal padding has changed from 6px to 8px to match the Material Design spec. This may affect the layout of portions of your application where md-button, md-datepicker, or md-toast with actions are used.

If you are using our SCSS files, you can override this back to the default, or another value, in your app's SCSS files:

$button-left-right-padding: rem(0.6); // For 6px horizontal padding

• card: Removed support for the class="md-actions" inside of an md-card template. This is deprecated in favor of using the <md-card-actions> element.
• checkbox: If you've created a custom solution to style links within md-checkbox labels, then you may need to remove or change that code now. This is because we automatically detect <a> tags in these labels and re-render them in an accessible way.
• checkbox: The default size and spacing for md-checkbox has been updated to align with the Material Design specification. Additionally, many new Sass variables have been added for customizing the size and spacing of md-checkbox. The md-dense class is now supported. After updating to this version, you may need to adjust the layout of your app due to the larger touch-friendly size of checkbox. You may also want to make use of md-dense in cases where space is limited.
• chips: Chips have been updated to latest Material Design spec (2017). $chip-font-size was reduced to 13px from 16px. $chip-remove-padding-right was increased to 28px from 22px. These changes may cause your chips to have a smaller, denser layout now. In certain scenarios, this may require minor changes to your app's layout. You can change these variables back to their old values if your app consumes Sass. Additionally, the remove chip icon has been changed, but you can use the custom chip template demo as a guide to changing back to the old icon, if desired.
• chips: Removed the deprecated, since 2015, md-on-append attribute. It was deprecated in favor of md-transform-chip or the simple notifier md-on-add. Please see the md-chips Demos for examples of using md-transform-chip.
• chips: The deprecated MdChipsCtrl.selectAndFocusChip() function has been removed. MdChipsCtrl.selectAndFocusChipSafe() should be used instead.
• dialog: Removed support for the deprecated class="md-actions" inside of an md-dialog template. This was deprecated in favor of using the <md-dialog-actions> element.
• dialog: Removed support for the deprecated .content('string') methods and options. These were deprecated in favor of .textContent('string') and .htmlContent('sanitized-string')' methods and their associated options. Please note that use of .htmlContent requires that the ngSanitize module be loaded.

If you have

alert = $mdDialog.alert().content('This is an example.');

It needs to be changed to

alert = $mdDialog.alert().textContent('This is an example.');

If you have

alert = $mdDialog.alert({
  content: 'This is an example.',
});

It needs to be changed to

alert = $mdDialog.alert({
  textContent: 'This is an example.',
});

• input-container: md-input and md-select inside of md-input-containers have been updated to use indentation that is consistent with the spec (aligned to the left in LTR and the right in RTL). This may cause some minor layout issues in apps that depended upon the previous 2px padding inside of md-input-container.

• layout: The way that margins are applied to md-checkbox, md-input-container, md-radio-group, and md-select has been changed. You can now use the $default-horizontal-margin Sass variable to override the default 16px horizontal margin size. As part of this, md-radio-buttons inside of layout="row" containers are now aligned vertically with other content as they no longer have a 16px margin-bottom. If you have previously added custom styles, to your components inside of a row layout, in order to give them extra margin-right in LTR or margin-left in RTL, you will need to re-evaluate those styles. In most cases, they can now be removed.

• layout: Removed the deprecated, undocumented *-lt-* layout attributes and classes. This includes the following attributes and their matching classes, which have been giving deprecation warnings since 2015:

• layout-lt-md

• layout-lt-lg

• flex-lt-md

• flex-lt-lg

• layout-align-lt-md

• layout-align-lt-lg

• flex-order-lt-md

• flex-order-lt-lg

• flex-offset-lt-md

• flex-offset-lt-lg

• hide-lt-md

• hide-lt-lg

• show-lt-md

• show-lt-lg

• list: md-list with the md-dense class has been updated to align with the Material Design specification. This means that md-list-items heights have changed when using md-dense. The md-dense-disabled class is now supported on md-list. After updating to this version, you may need to adjust the layout of your app if you use md-dense with md-list or customize the layout of md-checkboxs within md-list-items.

• \$mdCompilerProvider: The deprecated $mdCompilerProvider.respectPreAssignBindingsEnabled() API has been removed. We no longer respect AngularJS's $compileProvider.preAssignBindingsEnabled() value as this API was removed in AngularJS 1.7.0.

If you had the recommended configuration for AngularJS 1.6.x:

$compileProvider.preAssignBindingsEnabled(false);
$mdCompilerProvider.respectPreAssignBindingsEnabled(true);

Then you should remove both of these calls as they are now the defaults in AngularJS 1.7.0 and AngularJS Material 1.2.0.

If you had the recommended configuration for AngularJS 1.7+:

$mdCompilerProvider.respectPreAssignBindingsEnabled(true);

Then you should remove this call as it is now the default in AngularJS Material 1.2.0.

If you were using a backwards-compatible configuration for AngularJS 1.6+:

$mdCompilerProvider.respectPreAssignBindingsEnabled(false);

Then you will need to remove this call and may need to refactor your Controllers for AngularJS Material components like $mdDialog, $mdPanel, $mdToast, or $mdBottomSheet.

For example:

 $mdDialog.show({
   locals: {
     myVar: true
   },
   controller: MyController,
   bindToController: true
 }
  function MyController() {
   // No locals from Angular Material are available. e.g myVar is undefined.
   // You would need to move anything accessing locals in here to $onInit().
 }
  MyController.prototype.$onInit = function() {
   // Bindings are now available in the $onInit lifecycle hook.
 }

• menu: Removed the deprecated $mdOpenMenu API. It was deprecated in favor of $mdMenu.open.
• panel: The deprecated MdPanelRef.addClass(), MdPanelRef.removeClass(), and MdPanelRef.toggleClass() functions have been removed. These were deprecated in 2016 in favor of using the panelContainer or panelEl JQLite elements that are referenced in the MdPanelRef object.
• select: ngMultiple has been renamed to mdMultiple to make it clear that this API is provided by AngularJS Material and not by AngularJS.

If you had:

<md-select ng-multiple="expression">...</md-select>

You need to change to:

<md-select md-multiple="expression">...</md-select>

• sidenav: Removed access for the deprecated $media service in md-is-locked-open. This was deprecated in favor of the $mdMedia service. The functionality is the same and only a rename to the current name of the service is required.
• sidenav: Removed the md-sidenav-focus directive. It was deprecated in favor of md-autofocus. Please see the md-autofocus Docs and md-sidenav Basic Usage Demo for examples.
• tabs: Tab items now have a min-width and padding which matches the Material Design specification. For width, this is 72px on xs screens and 160px on all other screens. For left and right padding, this is now 12px instead of 24px. If your app needs to have tabs which are smaller than the spec, you will need to override md-tab-item's min-width and md-tab's padding styles.
• theming: Removed support for the deprecated $mdThemingProviderTheme.primaryColor() and the related accent/warn/background APIs. These were deprecated in favor of $mdThemingProviderTheme.primaryPalette() (and accent/warn/background) in 2015 and they have been logging warnings when used since then.
• theming, toolbar, subheader, input: The contrast colors (the text or icon color, for example on a raised button) of many of our default palettes have been updated to meet the AA level of the contrast guidelines for web accessibility. If you are using our default palettes directly, the accessibility of your application should be improved. However, we recommend that you evaluate this after updating to 1.2.0. There may be edge cases in your app or custom styles that need to be updated to meet accessibility guidelines.

If you find significant accessibility issues after updating, please report them to us. In 1.2.x, we have a lot more control over our component theming in regards to hues and opacities.

If your app is using a custom palette, whether based on a copy of default palette or not, we encourage you to evaluate that your contrast configuration meets the WebAIM guidelines. Please review our guide on Defining Custom Palettes for details.

• toast: $mdToast.show()'s position behavior has been updated to be consistent with the documentation. If you relied on the previously undocumented behavior where it defaulted to top left instead of bottom left, you will need to update your app.

Change your code from this:

    $mdToast.show(
      $mdToast.simple()
      .textContent('Simple Toast!'))
    .then(...

To this:

    $mdToast.show(
      $mdToast.simple()
      .textContent('Simple Toast!')
      .position('top left'))
    .then(...

• toast: The deprecated content() and updateContent() methods have been removed.

If you had:

$mdToast.show($mdToast.simple().content('This no longer works.'));

You will need to change to:

$mdToast.show($mdToast.simple().textContent('This works.'));

If you had:

$mdToast.updateContent('This no longer works.');

You will need to change to:

$mdToast.updateTextContent('This works.');

If you had:

$mdToast.show($mdToast.simple({ parent: parent, content: 'This no longer works.', theme: 'some-theme', capsule: true }));

You will need to change to:

$mdToast.show($mdToast.simple({ parent: parent, textContent: 'This works.', theme: 'some-theme', capsule: true }));

Contributors

Thank you to the contributors who helped with the v1.2.0 release:

| | | | | | | | :------------------------------------------------------------------------------------------------------------------------------: | :-----------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------: | :-------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------: | | Splaktar | jelbourn | clshortfuse | oliversalzburg | batsauto | wagnermaciel |

| | | :--------------------------------------------------------------------------------------------------------------------------------------------: | | tomaszgrabowski |

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes bug fixes.

• Fixes $mdPanel animation bugs
• Datepicker now passes ng-model-options on to calendar so that they both use the same timezone settings
• Fixes md-datepicker to work with a custom config via $mdDateLocaleProvider, including MomentJS

Known Issues

• min-date validation in md-datepicker is broken for GMT+T timezones #11963. Planned for in 1.1.25.
• md-select using md-select-header closes on mouse click when not using multiple #11969. Will be fixed in 1.1.25.

Bug Fixes

• datepicker: support ng-model-options timezone w/ MomentJS and datepicker now passes ng-model-options on to calendar (12562b0), closes #11945 #10598
• panel: animated panels never appear on the screen (e81e2e3), closes #11946
• panel: inline transforms accumulate after each time the close animation runs (6322e98), closes #11946

Contributors

Thank you to the contributors who helped with the v1.1.24 release:

| | | | :------------------------------------------------------------------------------------------------------------------------------: | :-------------------------------------------------------------------------------------------------------------------------------: | | Splaktar | mmalerba |

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes bug fixes.

• Adds a md-month-filter API to md-datepicker and md-calendar
• Fixes issue with the md-date-filter API
• Adds support for the $onDestroy hook in $mdCompiler
• Fixes a number of issues with $mdPanel animations
• Many fixes for md-select including bringing back support for ng-selected on md-option
• Adds md-calendar support for specifying timezone in ng-model-options

Known Issues

• md-datepicker throws exceptions if you specify a custom config via $mdDateLocaleProvider #11945. Fixed in 1.1.24.
• min-date validation in md-datepicker is broken for GMT+T timezones #11963
• Panels sometimes don't appear 11946. Fixed in 1.1.24.
• md-select using md-select-header closes on mouse click when not using multiple #11969. Will be fixed in 1.1.25.

Bug Fixes

• calendar, datepicker: in year view, md-date-filter only evaluates first day of month (3d5ff5d), closes #11703
• compiler: $onDestroy hook not called (8bb1d98), closes #11847
• datepicker: update error state only after $validate has run (11f65e3), closes #10360
• layout: Syntax Error: Token '&&' not a primary expression (#11940) (1bd1a97), closes #10935
• list: allow overriding md-list-item padding for clickable items (f7d9027), closes #10384
• menuBar: close top nested menu when escape key is pressed (98e259b), closes #11678
• navBar: update inkbar on screen resize (c1e2b12), closes #10121
• panel: allow transform to be animated on an offset panel (269b68e), closes #9641 #9905
• panel: consolidate redundant validations (#9631) (a334134)
• panel: invisible after hide/show cycle (a3c533f), closes #11291
• progress-circular: correct rendering for diameter bigger than 60 (#11896) (0cca317), closes #10376
• progress-linear, progress-circular: mirror indicator when rtl is on (#11895) (9fc2f3f), closes #10814
• select: height changes when disabled (e2af2a3), closes #11812
• select: md-focused not removed from options on panel close (5a7e967), closes #11927
• select: optgroups are not visible to screen readers (5fbabe7), closes #11240
• select: perform correct position calculation in rtl for long labels (#11894) (9f49e10), closes #10395
• select: revert removal of support for ng-selected on md-options (546bd84), closes #11914
• slider: vertical slider in a scrolled container sets value to zero on all clicks (#11801) (79bf96b), closes #11800
• toast: onRemove doesn't return a Promise in some cases (e625a9c), closes #10379
• toolbar: md-scroll-shrink conflicts with md-select in toolbar (1ed54bb), closes #10413 #9871
• tooltip: change from inline to inline-block to account for md-panel change (20194ba)
• util: sanitize function used by select and autocomplete throws "Invalid regular expression" when typing "(" (bc71d0b), closes #11908

Features

• calendar: support specifying timezone in ng-model-options (2a01746), closes #10431
• input: add animation to color change (#10079) (b486a41)
• select: add the ability to pre-select the only option in the list (#9940) (6372027), closes #9626

Documentation

• codepen: update for AngularJS 1.8.0
• security: added Security Policy
• tabs: improve correctness of API docs and types a17ef4f, closes #10407

Contributors

Thank you to the contributors who helped with the v1.1.23 release:

| | | | | | | | :------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------: | :--------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------: | | Splaktar | crisbeto | marosoft | nnmrts | Thaina | chmelevskij |

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes bug fixes.

• A number of significant fixes for md-select including an a11y overhaul
• Lots of important fixes for md-list
• Fixes for md-autocomplete including a regression fix for md-not-found and some usability improvements

Known Issues

• md-select using md-select-header closes on mouse click when not using multiple #11969. Will be fixed in 1.1.25.

Bug Fixes

• autocomplete: loop options list when moving past first/last option with arrow keys (5228f23), closes #11766
• autocomplete: md-not-found template is not styled properly (ce6e2ff), closes #11852
• autocomplete: Move mouse enter and leave events to container (5b0c9ba), closes #11776
• autocomplete: scroll to top of the list each time dropdown open (498c9ed), closes #10479
• contact-chips: don't rely on debug info to get access to controller scope (2f77095), closes #11699
• datepicker: md-open-on-focus fails when switching tabs with open datepicker (7a16778)
• gesture: 'drag' gestures don't clean up touch action styles on parent (deb3dfc), closes #11147
• list: dense lists cut off descenders of letters like gjqpy (0ab73bd), closes #8890
• list: isEventFromControl() works on all browsers now (d537d25), closes #7937
• list: primary action is fired twice on space/enter keydown (920018e), closes #11756
• list: secondary actions give aria warning if text is in a span (90c8b8d), closes #6152
• menu-bar: z-index not restored on menu close (4a4dde4), closes #11235
• nav-bar: clicked nav item not focused or selected in some cases (4d4e0ac), closes #11747
• select: overhaul screen reader support (928c71d), closes #10748 #10967
• select: sanitize user input before searching options (#11855) (0ec0cc5), closes #11854
• select: when using trackBy, trigger ng-change only when tracked property is different (ecd55d0), closes #11108
• select: menuController not defined edge case in focusOptionNode() (b9d8322), closes #11885

Documentation

• vscode: add VSCode configuration and guide (#11879) (a8954df)
• dialog: clarify promise rejection behavior in descriptions (#11889) (939f6c9), closes (#10130)
• docs, README: remove Bower references, update GitHub and NPM icons. fix 'View Demo' button appearing for directives w/o demos (#11888) (5c75b12)
• getting-started, home: updates to landing page and getting started. add Blank StackBlitz Demo starter (#11890) (d1a9976)
• COMMIT_LEVELS: update guide to better describe the process and responsibilities (#11862) (38fe956)
• BUILD: rewrote most of the guide (#11880) (4093953)

Contributors

Thank you to the contributors who helped with the v1.1.22 release:

| | | | | | | | :------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------: | | Splaktar | marosoft | oliversalzburg | andrewseguin | free-easy | nathanael-bice |

| | | | :--------------------------------------------------------------------------------------------------------------------------: | :-----------------------------------------------------------------------------------------------------------------------------: | | psamim | qubiack |

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes bug fixes.

• Accessibility and touch improvements for md-autocomplete

Bug Fixes

• autocomplete: improve handling of touch pads and touchscreens (#11782) (20c4d3f), closes #11778
• autocomplete: improve implementation of aria-activedescendant (#11743) (8c159aa), closes #11742

Contributors

Thank you to the contributors who helped with the v1.1.21 release:

| | | | :------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------: | | Splaktar | neilsh |

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes bug fixes.

• A number of fixes for iOS, Android, and IE11
• Fixes for a number of accessibility issues
• Improvements to internationalization through support for specifying dir="rtl" on any DOM element

Bug Fixes

• autocomplete: options panel flickers on hover after clicking input (#11757) (8f14afd), closes #11625
• autocomplete: support ng-click on md-autocomplete (#11758) (313e5e6), closes #11625
• autocomplete: tap outside options panel on iOS does not close panel (#11625) (f81349a), closes #9581
• datepicker: remove invalid aria-expanded (#11740) (197d197), closes #11475
• gesture: check if navigator is defined before accessing userAgent (#11755) (0077d3e), closes #11751
• gesture: maximum call stack size exceeded exception on click when using TalkBack screen reader on Android (#11774) (4acef53), closes #11768
• input: floating label text fails a11y contrast audit (#11497) (b5de054), closes #11475
• panel: append panel animation transforms after existing transforms (#11681) (ffe9349)
• rtl: support applying dir="rtl" on DOM elements other than the body (#11579) (bc7833b), closes #11016 #9754
• select: improve focus/blur handling on iOS (#11739) (0284b13), closes #11345
• tooltip: move document.contains polyfill for IE11 into $mdUtil (#11749) (f5535f8), closes #11745

Contributors

Thank you to the contributors who helped with the v1.1.20 release:

| | | | | :------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------: | | Splaktar | marosoft | Noglen |

Original in English by Stephen Fluin

Estamos buscando desarrolladores que deseen probar cosas nuevas (con algunas limitaciones) y que deseen compartir tus experiencias con nosotros. Si estás interesado, siga los pasos a continuación y háganos saber en qué problemas se encuentra.

Esta vista previa se destina principalmente a validar la compatibilidad con versiones anteriores, ya que las mejoras de rendimiento y tamaño del paquete aún están en curso.

El plan es asegurarse de que la mayoría de las aplicaciones de Angular sigan funcionando sin cambios significativos, y luego enfocarse en aprovechar las mejoras al framework subyacente.

Estado Actual

Hemos logrado un importante hito de estabilidad con la compatibilidad con versiones anteriores de Ivy. Basándonos en nuestras pruebas en miles de suites de prueba dentro de Google (el 97% de las suites de prueba se pasan en Google), estamos razonablemente seguros de que la mayoría de las aplicaciones funcionarán sin cambios en todo el ecosistema. Tenemos varios problemas conocidos en los que estamos trabajando, pero esperamos que haya una larga cola de problemas más pequeños que solucionar.

Ahora que hemos alcanzado este hito, necesitamos tu ayuda para identificar e informar estos problemas. Inscríbete en la vista previa, pruébelo y háganos saber qué se rompe.

Hay tres cosas que vamos a hacer con los problemas que se nos informan:

1. Corríjalos — siempre que sea posible, queremos utilizar esta entrada para abordar los problemas de compatibilidad con versiones anteriores.

2. Reconozcalas — algunos de los problemas informados serán de aplicaciones que se basan en comportamientos no especificados o que no forman parte de nuestra API pública. Es probable que no podamos revertir estos cambios, pero queremos entender y ayudar a los desarrolladores a identificar si se están ejecutando en alguno de estos.

3. Automatizarlos — si hay problemas o patrones a gran escala que descubrimos en todo el ecosistema (como una dependencia o un código problemático escrito por un esquema popular), queremos crear esquemas y reglas de TSLint para automatizar las migraciones.

¿Qué pasa con el rendimiento y el tamaño del paquete?

Todavía estamos trabajando en mejoras para el tamaño del paquete y el rendimiento del tiempo de ejecución. Cuando actualice hoy, todavía no verá todos estos beneficios.

Actualmente estamos viendo que el código generado y las aplicaciones “Hello World” son más pequeñas, pero en algunos casos, Angular en sí es más grande. Estos son algunos de los primeros resultados que hemos visto al actualizar las aplicaciones a Ivy:

ng new my-app @ 8.1.0-next.1

Antes de Ivy: Paquete principal (135 KiB)

Con vista previa de Ivy: Paquete principal (122 KiB)

Real World Angular @ 8.1.0-next.1

Antes de Ivy: Paquete principal (358 KiB)

• Lazy Chunks (7.7–34 KiB)

Con vista previa de Ivy: Paquete principal (400 KiB)

• Lazy Chunks (3.3–27 KiB)

Ahora estamos trabajando para reducir el tamaño del framework, de modo que hemos reducido el tamaño de los paquetes para aplicaciones reales en casi todos los casos antes de que Ivy sea el valor predeterminado. También serán posibles beneficios adicionales, ya que ofrecemos nuevas formas de arranque que van a reducir el tamaño del framework en tu paquete principal.

Haremos más anuncios sobre el rendimiento y los hitos del tamaño del paquete para las aplicaciones del mundo real en los próximos meses a medida que nos acerquemos a activar a Ivy de forma predeterminada para todas las aplicaciones.

¿Qué debo esperar ver hoy?

Tu aplicación debe construir y funcionar como lo hace hoy. Notarás los siguientes beneficios que se deben al nuevo compilador y conjunto de instrucciones:

• Mejoras menores en el tamaño del paquete: ng new es un 10% más pequeño y el código generado debería ver una reducción de ~25% en el tamaño

• Mejor rendimiento de compilación: la compilación incremental, la reconstrucción en modo AOT es un 40% más rápida

• Mejor rendimiento de las pruebas: en Angular, hemos visto que las pruebas de unidades de framework son 1.5 veces más rápidas, las pruebas de unidades de Angular Material son 2.7 veces más rápidas y el uso de memoria en las pruebas de unidades de Angular Material se ha reducido en un 81%

• Instrucciones más depurables — Agregue puntos de interrupción a HTML y pase a través de la representación de la plantilla, y depure más fácilmente la detección de cambios porque puede pasar a la función de plantilla en el traza de la pila y ver dónde se encuentra

También hemos solucionado muchos errores de larga data, hemos mejorado el comportamiento confuso y hemos solucionado algunos problemas de rendimiento.

• Los enlaces de clase siempre anulan otras clases (7289)

• ContentChildren consultas seleccionar nodo de host (10098)

• Las consultas tienen un tiempo de resolución inconsistente (21800, 25961)

• La bandera de los descendientes funciona inconsistentemente (14769, 27504)

• La detección de cambios aún se está ejecutando para los componentes separados que se proyectan (21324)

• El comportamiento de referencia de la plantilla local es inconsistente / confuso

• Ya no es necesario agregar componentes a la lista de componentes de entrada (28826)

¿Cómo me inscribo?

Hemos publicado una guía aquí: angular.io/guide/ivy

Siempre debe ejecutar la última versión de Angular desde npm (etiquetada a next) siempre que use Ivy. Estaremos haciendo cambios frecuentes en los próximos meses. Puede usar ng update para obtener la última versión de la siguiente manera:

ng update —-next @angular/core

Una vez que estés en la última versión, actualiza tu src/tsconfig.app.json para incluir “enableIvy": true bajo un nivel superior angularCompilerOptions llave.

Cuando ejecutas ng build, haremos la compilación de compatibilidad Angular (ngcc) de tu carpeta node_modules/ y actualizaremos todos tus archivos de metadatos en un formato que podamos convertir en instrucciones Ivy.

Danos Tu Opinión

Nos estamos acercando rápidamente a un futuro en el que los beneficios de Ivy son automáticos y universales para todos los desarrolladores y el Proyecto Ivy llega a una conclusión. Mientras tanto, abra un problema o comuníquese con devrel@angular.io para darnos tu opinión acerca de tus experiencias con la vista previa.

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes bug fixes, enhancements, and documentation improvements.

• Fixed the 3 known regressions from the 1.1.18 release
• Published a new guide for migrating your AngularJS Material app to Angular Material and the CDK
• A number of cross browser bug fixes
• The documentation can now be scrolled while reading it using the up/down/pageup/pagedown keys!

Bug Fixes

• datepicker: auto closes in Chrome when md-open-on-focus is used (#11719) (73c424d), closes #11701
• gesture: tapping a submit button fires two submit events on mobile (#11729) (244619a), closes #10189 #11725
• icon: symbol icons not working on browsers other than IE11 (#11706) (a62d160), closes #11705
• select: edge case where the model value is unset w/ AngularJS 1.7.8 (#11724) (952a035), closes #11679
• tabs: new tab animation broken by code to support IE11 (#11711) (1063a92), closes #11689

Features

• menu-bar: support md-prevent-menu-close on checkbox/radio items (#11710) (d577afd), closes #11707

Documentation

• migration: Add a guide for migration to Angular Material and the CDK (#11706) (16cea88)
• docs: Added support for Sass and TypeScript in code samples (#11706) (16cea88)
• docs: Allow up/down/page up/page down to scroll content (#11712) (67826f5), closes #2961

Contributors

Thank you to the contributors who helped with the v1.1.19 release:

| | | | :------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------: | | Splaktar | codymikol |

This release is now available in our Online Documentation, NPM, and Bower. It is also available on the Google CDN (JS, CSS).

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes bug fixes, infrastructure, and documentation improvements.

• Fixed an a11y issue where md-svg-icon could cause pages to have multiple SVGs with duplicate id values.

Known Issues

• Symbol SVG icons are not displayed when using md-svg-icon in 1.1.11+(#11705). This will be fixed in 1.1.19 via PR #11706.

• Creating a new tab with pagination enabled does not animate correctly (#11689). This will be fixed in 1.1.19 via PR #11711.

• AngularJS 1.7.8 causes an issue with md-select where using requiredwill unset the value of the model. This is being tracked in #11679 and is fixed in 1.1.19 via PR #11724.

Bug Fixes

• icon: stop breaking SVGs that have id references

Infrastructure

• release: workaround NPM bug that publishes .git/ directory

Documentation

• docs: fix demos not loading in CodePen

Contributors

Thank you to the contributors who helped with the v1.1.18 release:

This release is now available in our Online Documentation, NPM, and Bower. It will be available early next week on the Google CDN (JS, CSS).

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes bug fixes and documentation improvements.

• In 1.1.13, we fixed an issue where the md-autocomplete would sometimes position the options panel on top even when there was no room in the viewport. Unfortunately, this meant that the options panel often defaulted to top position. This was tracked in #11656 and fixed in PR #11670.

• The 1.1.14 release was deployed to NPM with a .git directory included in the published package due to a bug in npm publish. This caused NPM to refuse to uninstall or update the package. We’ve fixed this in 1.1.17 and we’re using #11684 to implement a long term fix.

• In addition to fixing the two regressions above, this release fixes an a11y regression with md-slider and tab scrolling with wheel devices in Firefox.

Known Issues

• AngularJS 1.7.8 causes an issue with md-select where using requiredwill unset the value of the model. This is being tracked in #11679.

Bug Fixes

• autocomplete: default dropdown position to the bottom again.

• slider: aria attributes are not announced when tabbing in JAWS or VoiceOver. A previous fix for ChromeVox broke this for JAWS and VoiceOver. This new fix has been verified in all 3 of these screen readers.

• tabs: use the standard wheel event instead of the non-standardmousewheel event to fix tab scrolling in Firefox.

• npm: deploy new release early to fix issue of 1.1.14 including a .git/ dir for NPM installs.

Documentation

• docs: scroll position improvements for navigation. Using the back button should bring you back to the same scroll position instead of somewhere else. Opening a new page in the docs should take you to the top of the page instead of somewhere in the middle.

Contributors

Thank you to the contributors who helped with the v1.1.17 release:

This release is now available in our Online Documentation, NPM, and Bower. It is also available on the Google CDN (JS, CSS).

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes bug fixes and documentation improvements.

• 1 memory leak, 2 regressions, and 5 other bugs fixed

• Fixed an accessibility issue with md-nav-bar

• Fixed linking to specific sections of the documentation site and specific demos

• Build output (JS and CSS files) will be easier to compare from 1.1.14 onward

Known Issues

• Somehow this release was deployed to NPM with a .git directory included in the published package. This can cause NPM to refuse to uninstall or update the package. We’re investigating and tracking this in #11684.

• AngularJS 1.7.8 causes an issue with md-select where using required will unset the value of the model. This is being tracked in #11679.

• In 1.1.13, we fixed an issue where the md-autocomplete would sometimes position the options panel on top even when there was no room in the viewport. Unfortunately, this meant that the options panel often defaulted to top position. We’re tracking this in #11656 and have merged a fix in PR #11670. This will be fixed in 1.1.15. In the meantime, you can use md-dropdown-position="bottom" as a workaround.

Bug Fixes

• \$mdInteraction: clean up events on $rootScope destroy. This fixes a memory leak when $mdDialog needed to be injected multiple times. This occurred most often in testing, but also effected certain apps that were creating/tearing down the app repeatedly.

• icon: large SVG files can cause icon caching to hang. This fixes a regression where sites that use many, rich SVG icons could hang. This is part of an ongoing effort to provide more robust support for SVG icons.

• input: placeholder hidden when there is also a label on IE11. This fixes a regression caused by a previous fix for placeholders in md-datepicker on IE and Firefox.

• interimElement: don’t track elements that fail compilation. This fixes an issue with $mdDialog, and other interimElements, where an exception during to runtime compilation of the element could cause dialogs to stop responding. This occurred most commonly in apps that used nested or multiple dialogs.

• nav-bar: non-selected tabs with anchors have invalid tabindex value. This fixes an accessibility issue where it is not possible to tab out of certain tabs using the keyboard.

• panel: caching of panels by id is not working. This fixes an issue where our trackedPanels caching was working for md-tooltip, but not for md-panel.

• progress-circular: show correct circle arc when changing from indeterminate to determinate mode. This fixes an issue where changing the md-mode at runtime could cause the arc to be off by about 90 degrees.

• virtual-repeat-container: support horizontal scrollbar in vertical orientation. This fixes an issue where a horizontal scrollbar in a vertical list could cover up some of the final items in the list.

Documentation

• docs: properly format anchor names and hrefs. You should now be able to link to a specific demo (I.e. the new Autocomplete Repeat Mode Demo) or documentation section (I.e. AngularJS Material Browser Support). Previously these anchors just took you to the top of the page (prior to 1.1.13) or gave you a 404 (in 1.1.13).

• radio-button: correct two misspellings of Latin names in the demo

• colors: clean up Closure / JSDoc comments and types

Infrastructure

• build: make the build output deterministic and reproducible. Previously the ordering of content within our JS and CSS files changed each build. With this change, comparing the build output between releases will be a lot easier.

• ci: we moved over to CircleCI from TravisCI in the previous 1.1.13 release

Contributors

Thank you to the contributors who helped with the v1.1.14 release:

This release is now available in our Online Documentation, NPM, and Bower. It is also available on the Google CDN (JS, CSS).

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that includes a couple enhancements in addition to bug fixes and documentation improvements.

• md-autocomplete now supports variable-height autocomplete list items when using md-mode="standard". Find out more in the updated docs and the new Repeat Mode demo.

• The md-date-filter API will now disable months when looking at the month picker in the md-datepicker and md-calendar. Note that only the first day of the month is checked.

• A number of issues specific to IE11 and Firefox were resolved.

• md-radio-button styles were updated to better align with the Material Design 2017 spec. This changes the style of focused, unchecked and checked, disabled radio buttons.

Known Issues

• The fix for copying links to example/demo anchor headers didn’t quite work as expected in production. It’s been fixed in master via 163b762.

• Large SVGs used with md-icon can cause applications to hang since v1.1.11. This is being tracked in #11651 and is being worked on in PR #11653.

• We fixed an issue where the md-autocomplete would sometimes position the dropdown on top even when there was no room in the viewport. The improved calculation means that there are more opportunities for the dropdown to show in the default top position where it would have used the bottom position previously. We’re considering changing this to make bottom the first choice again. Please leave us feedback on this in #11656. In the meantime, you can use md-dropdown-position="bottom" as a workaround.

Bug Fixes

• autocomplete: show dropdown on top only when there is room (#11629) (38fb991), closes #10859

• autocomplete: suggestions can be highlighted incorrectly (#11529) (320511c), closes #10573

• autocomplete: two chips added on enter w/ IE11 (#11528) (705c54e), closes #10640 #10667

• checkbox: submit on enter rather than toggle (#11584) (a191a8e) (#11640) (251cfed8), closes #11583 #11639

• datepicker: does not open on focus in Firefox (#11521) (45e92ea), closes #10619

• datepicker: validation error when adding text after date (#11110) (57c81c8), closes #9994 #10520 #10015

• icon: SVG elements are not loaded from the cache properly on IE11 (#11635) (7cde443), closes #11603 #11545#11604

• layout: remove some duplicate layout > flex styles (#11613) (6515e6c), closes #11609

• list: case where user is unable to interact w/ secondary actions (#11539) (708fff9), closes #9676

• menu: fix min-height when scrollable (#11602)

• nav-bar: improve focus behavior for click events (#11600) (e64875d), closes #11591 #11494 #11598

• radio-group: style focused but unchecked radio buttons (#11564) (8a4105c), closes #11563 #8339 #3643

• select: carrot not aligned to end in IE11 (#11544) (bf5bbfc), closes #10714 #3840 #3840

• tabs: exception when no selection and header clicked (#11520) (9c079aa), closes #10042

Features

• autocomplete: support variable-height autocomplete list items (#11516) (562e0c7)

• datepicker, calendar: md-date-filter disables months in month mode (#11526) (8aa5d58), closes #11525

Documentation

• checkbox: clarify description of md-no-ink (#11605)

• docs: copying links to example/demo anchor headers gives a bad URL (#11634), closes #11285

• menu: add demo and docs for dense menus. (#11602)

• ripple: break out docs for $mdInkRippleProvider from $mdInkRipple (#11606)

Contributors

Thank you to the contributors who helped with the v1.1.13 release:

This release is now available in our Online Documentation, NPM, and Bower. It is also available on the Google CDN (JS, CSS).

You can find the details for all releases in our Change Log.

Highlights

This is a patch release that fixes two regressions found in the previous v1.1.11 release.

Bug Fixes

• select: multiple with initial value causes label to overlap with value (#11572) (a4507d6), closes #11571 #11571

• tabs: md-center-tabs causes tabs to not render (#11567) (a49043d), closes #11566 #11432

Contributors

Thank you to the contributors who helped with the v1.1.12 release over the holiday break:

This release is now available in our Online Documentation, NPM, and Bower. It is also available on the Google CDN (JS, CSS).

You can find the details for all releases in our Change Log.

Highlights

v1.1.11 is our largest release of 2018. This release focused on fixing a lot of high priority issues related to accessibility, performance, and cross browser compatibility.

Here are the highlights:

• Our primary focus this release was on high priority regressions and accessibility issues. We’ll continue with this same focus in v1.1.12.

• With the announcement of major changes to Material Design in the 2018 update to the specification, we’ve clarified that AngularJS Material will continue to focus on aligning with the Material Design Spec for 2014–2017. The Angular Material project will be the place to find the latest Material Design 2018+ features.

• We fixed 21 P1, 21 P2, and 14 P3 issues.

• We reduced the minified CSS bundle size by 76KB as compared to v1.1.10. Also note that this is 93KB smaller than the minified CSS bundle from v1.1.9.

• IE11 support was significantly improved with 7 bug fixes. There were also fixes for issues specific to Firefox and Edge.

Advisories

Tabs received a number of accessibility, cross browser support, and performance fixes. As part of this, there was a regression to md-center-tabs which can cause the tabs to not appear or to appear shifted to the right. This is being addressed and will be fixed in v1.1.12.

Also related to the above change to Tabs, if you use Tabs inside of a non-AngularJS Material dialog, you may see issues with the width of the tab content. You can resolve this by overriding the width of the md-pagination-wrapper. In v1.1.12, you will only need this override if using Tabs with pagination in a non-AngularJS Material dialog.

There also appears to be a regression to md-select when it is used with the multiple option and assigned an initial value. This can cause the label to not float, leaving it overlapping with the values. A fix is being worked on and will be included in v1.1.12.

We hope to have a v1.1.12 release out in mid-January.

Bug Fixes

• autocomplete: screen readers now announce when an item is selected from the dropdown (#11403) (e56424e), closes #10837

• autocomplete: apply theme to mdProgressLinear and input (#9698) (affe84b)

• autocomplete: ChromeVox indicates selected option on focus (#11441) (ca10bd0), closes #10838 #10970

• autocomplete: updateSize incorrectly sets the size to zero (#11500) (d343363), closes #10834

• bottom-sheet: theme now supports dark mode (#11380) (4cecebb)

• chips: editing chips works again (#11364) (97455f5), closes #11322 #11323

• chips: improve screen reader support (#11422) (2268c24), closes #2618

• chips: set dirty when a chip is removed (#11363) (0dd688c), closes #11356

• datepicker: md-open-on-focus constantly re-opens on close w/ IE11 (#11440) (6596cc7), closes #10999

• icon: stop breaking SVG id references when caching icon ids (#11342) (841e8b2), closes #8689

• icon: regression causing exceptions to be thrown on IE11 (#11545) (47527f2), closes #11543 #11342 #11162

• input: make md-maxlength validation happen on initialization with interpolated value (#11338) (0cb4af1), closes #11329 #11329

• input: placeholder and datepicker value displayed overlapping on Firefox (#11538) (44a6946), closes #10440

• input: remove placeholder from button accessibility tree (#11404) (2203eec), closes #11293

• input: remove unnecessary warnings when ng-messages not provided (#11352) (d48c5b8), closes #10461

• input-container: handle initialization of md-icon with ng-if (#11437) (4493389), closes #9529

• interim: validate the interim element while closing it (#11509) (6815faf), closes #11507 #10715

• list: account for IE11 bug with Flexbox and min-height (#11393) (e3c1a5c)

• nav-bar: improve screen reader support (#11486) (6b29548), closes #11485 #11485

• nav-bar: set ng-href on nav-item even if md-nav-href is empty (#11488) (e876eec), closes #11487

• nav-bar: update keyboard navigation to WAI-ARIA guidelines (#11494) (4d29450), closes #10419 #11489

• select: display asterisk on label only if empty (#11355) (f7b7f10), closes #11312

• select: give focus to the first option when loaded asynchronously (#11372) (998199f), closes #11357

• select: perform full cleanup of the select drop-down after the close (#11448) (dfba062), closes #11447

• select: theming issues with md-select-value (#11373) (9852ff7), closes #9592

• select: extra scrollbar when select dropdown is open (#11453) (20fc2d8)

• select(multiple): Remove side-effects to forms when adding md-select elements (#11491) (97e2d00), closes #11490

• sidenav: refactor syntax to work around issue in babel-minify (#11351) (0ed110b)

• switch: theming issues with focus in dark theme (#11459) (71e0411), closes #8518 #11417

• tabs: provide guidance on how to navigate between tabs (#11402) (4b1b729), closes #10895

• tabs: show a visual indication of tab focus (#11392) (1d73d81)

• tabs: tab labels overly truncated on IE11 when pagination active (#11432) (2b2f441), closes #10406

• theme: prepend # to hex codes for enableBrowserColor (#11492) (0306ac0), closes #11259

• toast: improve a11y support for $mdToast.simple(). improve docs (#11424) (fedb9a3), closes #349

• toast: remove the interim element from the list before closing element (#11427) (f616b25)

Features

• autocomplete: add input-aria-label and input-aria-labelledby (#11412) (534beea), closes #10815

• autocomplete: add support for input-aria-describedby (#11405) (a25a7df), closes #11004

• contactChips: add basic support for md-separator-keys (#8142) (eb10b56)

• slider: enable page up/down and home/end keyboard actions (#11517) (70654c3), closes #11515

• tabs: allow specifying custom class names for tabs (#11332) (aa30ada)

• theming: add ability to specify hues as options to defineTheme (#11428) (f776bf7)

Performance Improvements

• tabs: md-center-tabs causes in high CPU usage (#11375) (7fdf9da), closes #9690 #6375

• tabs: remove unreferenced elements variable from TabsController (#11379) (33652b4), closes #11377

• css: remove bloat from auto prefixing of unsupported browsers (#11340) (3660a32)

This auto prefixing change reduced the minified CSS bundle size by 76 KB. You can find the breakdown of supported browsers here.

Documentation

• We’ve updated our home page to include more details about the browsers and versions that AngularJS Material supports.

• We made many small tweaks to the docs to fix broken links, update URLs to the Material Design 2014–2017 Spec, and fix syntax and formatting.

• We also made changes across the docs and demos to properly support dark mode themes.

• a11y: audit of our entire docs and demos site to resolve most all of our accessibility issues identified by Lighthouse

• icon: update our guidance for using SVGs and provided details about the new Material Design Icons tool

• contact-chips: add docs for md-highlight-flags

• highlight-text: add md-highlight-flags example

• list: clarify the docs around md-avatar-icon

• slider: add missing docs for APIs like md-vertical. Fix demos in IE11

• input: fix issues with displaying the types in the docs. Add docs for md-select inside of md-input-container

• select: add missing docs for md-option and md-optgroup

• toast: add example of using locals to the custom toast demo

• typography: fix URL for Roboto font and general cleanup of the guide

Contributors

Thank you to the contributors, especially the first timers, who helped with the v1.1.11 release:

I am going to use this post to chronicle the first days of using this machine. I hope that it will help other developers and professionals who may also be looking at the latest MacBook Pro line up. Oh and I’m sure there will be some gaming content in here as well 😁

Day 0

When I purchased my 2014 MBP, I opted to pass on the Nvidia discrete graphics card. This was based on two primary drivers: heat and usage.

At the time, I had a Dell XPS desktop for gaming. So I didn’t intend to do any graphics heavy tasks on the MBP. I was also upgrading from a Chromebook Pixel 2013 which had a very hot i5 CPU. Thus, I wanted to get a device that I could use on my lap while doing basic web browsing or writing.

Fast forward to 2018, my 2014 MBP is 4.5 years old and well outside of the extended warranty plus my gaming desktop is about to be retired. I’m also in a situation where I anticipate needing to be able to do all of my professional work on a mobile platform for the next few years. This means that something like the attractive 2018 Mac mini won’t work for me.

I watched the early 2018 MBP i9 thermal drama unfold from a distance. I was happy to see that Apple quickly released a patch for this. The resulting benchmarks were acceptable to me. Additionally, as a developer, the burst speed of the i9 processor is valuable to me as it helps to eliminate micro interruptions in my workflow. I don’t really need to run the CPU at max for extended periods of time as is needed for video processing.

I was convinced to go with the Vega 20 after watching a number of videos that covered the benchmarks, thermals, and real world performance. For reference, some of those include:

• Vega 20 MacBook Pro Benchmarks vs 560X!

• Gaming on the VEGA 20 MacBook Pro — 2018

• Is Vega 20 Worth it for 15" MacBook Pro? Benchmarks & Thermals

• Vega 20 MacBook Pro Gaming — Battlefield 5, Black OPS 4, and Fortnite!

• Best MacBook Pro? (Radeon Vega 20) — Unboxing + Benchmarks

• Gaming on the Vega 20 MacBook Pro!?

A brief summary of those videos

• The thermals of the i9 w/ Vega 20 seem to be improved over those of the i9 w/ 560X even in pure CPU tasks.

• The Vega 20 was able to get 60+ FPS in modern games at medium settings and in slightly older games at high settings.

• The previous issues of throttling and stuttering during game play have been resolved (I believe as part of the thermal patch).

• The i9 w/ Vega 20 graphics provided a ~20–60+% increase to graphics performance for ~10% increase in cost.

• Gaming on Windows 10 in Boot Camp provided an increase of about 10–25 FPS over the same in macOS.

Additionally, I researched peripherals and adapters so that I could work with USB-C effectively. I picked up a USB-C card reader and two Thunderbolt 3 to HDMI adapters. These were used to hook up my two external monitors and, since the MBP has 4 USB-C ports, I’ll also be able to plug in power and a dongle for my external mouse and keyboard. The adapters also came with a discount for a Thunderbolt 3 to VGA adapter which will be useful when presenting at some schools and meetups. I decided to wait on ordering a dock until I was confident the laptop was going to be a keeper. The dock that I have my eye on is the CalDigit Thunderbolt 3 dock w/ 85 W charging.

My new MBP shipped straight from Shanghai. There was a delay of 2 days in Japan and that triggered UPS to push my expected delivery date by 4 days. Thankfully, soon after that it started moving again and was quickly back on track for on time delivery.

Day 1

When FedEx delivered my new MBP, it was a familiar unboxing experience. I went with silver, partially since I didn’t want a darker color that might absorb more external heat. It’s probably only the smallest possible difference, but it was enough for me 😉

The feel and build was similar to by 2014 MBP, but there were some differences. It felt slightly thinner overall and instead of a light up apple on the top, it’s just a shiny silver apple. 👍🏼

When I opened it up, the giant touchpad really stood out and worried me that it might cause issues while typing. The Touch Bar was there too… and the keyboard…

Thankfully it arrived with macOS Mojave already installed.

Migration

I booted it up and wasn’t sure what to expect of the Migration Assistant. The first attempt was with Wi-Fi, but I saw a message that connecting to my old MBP via USB would be faster. So I got the USB-A to USB-C data cable that came with my Pixel XL and plugged that in to each laptop. My old MBP detected it and switched to Peer-to-Peer networking, but the new MBP got stuck at “Switching”.

I had to cancel and restart the process. This time connected via USB from the start. I also had to make sure to overwrite and not duplicate any of the users, or the files (uncheck a box in the Migration Assistant wizard). The migration went smoothly this time. It originally estimated around 3 hours and 45 minutes to complete, but it was done within a couple of hours.

I knew that it was going to try to migrate some apps and settings, but I didn’t have high hopes and expected to install a bunch of apps and tweak a lot of settings after it was done. To my surprise, it basically copied over my entire device to the new device with almost nothing missing other than re-granting security and accessibility permissions! This was really the experience that I was hoping for!

This gives me a lot of confidence that should I have a MBP fail, I can restore to another MBP device from a Time Machine backup and be productive again in just a couple of hours. This is critical to me and my consulting business.

Boot Camp

I read a number of articles about installing Windows 10 via Boot Camp and it seemed somewhat straight forward. It was my first time working with Boot Camp though.

I downloaded the 5.08 GB Windows ISO from October 2018. I picked 150 GB for my Windows 10 partition and started it up. After about 30 minutes, it failed to copy the Windows files and started trying to back out the partitions that it had created. This seemed to get stuck, so I had to cancel it and manually clean up the partitions as detailed here.

That same article explained that the issue was Boot Camp’s partitions being FAT32 which support file sizes up to 4 GB. Then it provided a Boot Camp ISO Converter tool to split the ISO into smaller chunks in Boot Camp. I also disabled Time Machine and installed an update to Mojave just to be safe. This worked like a charm for me!

Windows 10 on a Mac was quite disorientating to me initially. Dragging windows with the touchpad didn’t seem to work and tap to click wasn’t enabled. Thankfully I found options in the Boot Camp settings to enable tap to click. It also had an option to change how window dragging worked, but that didn’t seem to help. I just had to figure out that I had to click and drag all with one finger instead of holding a click with one finger and dragging with another finger.

There were some prompts to install drivers, Windows updates that needed to install, virus scanning, and the usual range of other Windows tasks that had to be sorted out. I also went and cleaned up most of the privacy settings, disabled Cortana, and uninstalled as many Windows store apps as possible. Oh but I did install Slack from the Windows store. Then I downloaded and installed Chrome, Firefox, NVDA, Guild Wars 2, and Star Wars, The Old Republic.

Downloading, installing, and patching these games really gave the machine a workout. It flew through most tasks, but this got the fans going and got the CPU load up to around 18% while the Wi-Fi was going as fast as possible (unfortunately, we don’t have Fiber here). Even with all of this load, the palm rest remained a comfortable ~45C while the CPU ramped up to around ~80C. It certainly created a hot spot on my desk and would not have been comfortable on my lap under this kind of load.

That said, while sitting here in macOS with a 30+ open Chrome tabs, Slack open, numerous menu add-ons running, lots of Chrome extensions enabled, and writing this post, the palm rest is at a cool 30C, the GPU is only 35–40C, and the CPU is 38–45C. These temperatures are perfectly comfortable to use on your lap.

The MBP handled this load just fine over a period of about 3–4 hours while ~80GBs of game assets and patches were downloaded. After one of the games finished, and the other was playable, but downloading background updates, I decided to walk away for a bit and shut the lid. Doh! I hadn’t changed the Windows 10 settings for this, and it went to sleep right away. I could tell when the fans cut off about 20 seconds after closing the lid.

I opened it back up and went to change the setting when BSOD! Windows crashed, and the Event Viewer didn’t have much useful information for me. I didn’t see anything related to bridges or T2 chips… After rebooting, I was able to change the setting and get it to keep running after closing the lid.

About 5 hours later, after all the updates and downloads finished, I was installing NVDA when Windows 10 prompted me with a popup about sound issues. Then another BSOD! After rebooting, I was able to install NVDA without any problems. I tested using it for a bit and verified that sound was working in Google Play Music.

Using a Nonda USB-A to USB-C adapter, I was able to work with my U2F security key just fine. This adapter is Thunderbolt 3 compatible and passes data just fine while I have another adapter that only handles charging and doesn’t work with data. Keep this in mind if you are looking into USB-C adapters. I had picked up this attractive Nonda adapter at DevFest Florida 2016 as a speaker’s gift.

Day 2

Back to macOS

I decided to head back to macOS in order to write up the first day of experiences and to start testing peripherals like my external keyboard, mouse, monitors, and backup drive.

Keyboard

Now I’ve been typing on this keyboard for a few hours now… It’s certainly worse than my 2014 MBP, and it’s much worse than the Pixelbook’s keyboard. Even with the minimal typing required for installing software and entering basic details, it caused me to make a lot more mistakes than usual. I figured that this might just take some getting used to, so I waited until day 2, after writing this post, to provide feedback on the typing.

So the verdict after writing up this post with the MBP 2018 keyboard? I can certainly still type fast! But there are a lot missed keystrokes and mistyped keys, much more than any other typing experience that I’ve had in years. The “new, softer sounding keys” are too loud for my tastes and the “new, softer feel” is also not something that I am happy with.

The arrangement of the up and down arrow keys on the MBP is not something that I like compared to the 2014 model. That said, it hasn’t caused me too much pain, yet.

I don’t know if there is a setting for this or not, but the caps lock key’s light only seems to work about 20% of the time. I don’t know how, why, or when it decides to work, but I’ve seen it come on. If I click it a bunch of times here in Medium, the light stays off, but the caps lock mode does enable and disable. Solved: this turned out to be a bug in Karabiner that was fixed in their beta a couple months ago and just got fixed in their stable release in February 2019.

In my home office, these keyboard issues won’t be a problem since I’ll be using a trackball and external keyboard. However, I’ve never been a person to carry an external keyboard to co-working spaces. That may need to change. I wonder if there is already a keyboard on Kickstarter that fits over the top of the MBP’s keyboard 🤔

Now before we get into the Touch Bar, I just wanted to be clear, the MBP 2018 keyboard is by far the most underwhelming and disappointing feature of the device.

Touch

I am generally happy with the touchpad so far. I’m also happy with the Touch ID sensor. However, I wish that I could use my fingerprint for even more of the admin password prompts.

The Touch Bar experience in Windows 10 was a little confusing. Sometimes the volume up and down virtual keys would work, sometimes they would not. The esc key seemed to work.

The Touch Bar experience is unsurprisingly better in macOS. I have enjoyed being able to tap the volume or brightness buttons and then use the slider to find a setting that I was happy with. Some shortcuts in Finder and Chrome are useful, but I haven’t used them much yet.

Slack doesn’t offer anything but the default esc and brightness / volume / mute / Siri virtual buttons.

The Touch Bar in JetBrains’ WebStorm and IntelliJ IDEA seems quite useful! Here’s what I see when I open a project:

You can see that it offers me a menu to pick from the Run Configurations, then buttons to run, debug, or stop a Configuration. Additionally, it offers to the Git Update and Git Commit buttons.

If you open the Run Configurations menu, you can scroll through the options in the Touch Bar:

In this case, there is a green dot on “Watch Site” because it is currently running. If I exit the menu, I can see that the Run button has changed to Re-run, and the Stop button is enabled:

Even the Git Commit dialog has Touch Bar support. In this case it saves me an extra click by showing “Commit and Push…” in the Touch Bar:

Since I use a Logitech K800 Wireless, back-lit keyboard with a Windows layout for most of my work, I have the F1-FX keys mapped to actions like volume up/down, mute, etc. Thus, I don’t really make use of these Function keys when doing development. My primary shortcuts in WebStorm are all configured to use control , shift , option , combinations instead.

That means that I’m not really sad to be “missing” the F keys. I also haven’t hit a situation yet where I needed the esc key, and it wasn’t there. I’ll certainly be keeping my eye open for that though.

Verdict after 2 days: I’m learning to live happily with the new Touch Bar. Hopefully I don’t like it too much though. There are no external keyboards with Touch Bars yet and getting used to this 2018 MBP keyboard isn’t proving to be easy.

Peripherals

Everything went super smoothly with hooking up two 27" AOC 1080p HDMI monitors, an Anker 10 port USB 3.x Hub, and power. The time it takes to wake and sync the monitors seems to be cut in half compared to my 2014 MBP w/ Intel graphics.

I was a little worried that, with all 4 USB-C ports in use, I would have a problem with using my Titan U2F Security key. That was solved easily by just plugging it into my Anker Hub.

I haven’t had time, or a need to test out my Uni Thunderbolt 3 to VGA Adapter or Anker Thunderbolt 3 SD Card Reader yet.

It’s certainly a pleasure to be using this high speed laptop with my beloved Logitech K800 keyboard and M570 Trackball!

Additional Peripheral Research

I noticed that Logitech released the new MX Ergo Trackball last year. So I put in an order immediately since it was at its lowest price in 4+ months (it’s now about \$6 higher than yesterday). I can’t wait to try it out after 5 solid years with two of the M570s.

I also did a lot of research on keyboards in the last 2 weeks. I got some great recommendations for things like the Code keyboard, and the Apple Magic keyboard, however I’m looking for a wireless, back-lit keyboard with a Mac keyboard layout. The Code isn’t wireless. The Magic isn’t back-lit. The K800 has a Windows layout.

I looked at the Macally keyboards, but wasn’t able to find a good fit. However, it sounds like they may be launching something that meets my needs in the next few months.

I got a suggestion for Matias keyboards as well, but there are too many reviews that are very negative on the typing experience.

The best match that I can find seems to be the new Logitech Craft keyboard. However, it’s $199 MSRP (twice that of the K800) stopped me in my tracks. It’s currently $169 on Amazon, but I’m going to try waiting a few more months to see if there are any price dips. One of the biggest complaints with the Craft is the Logitech software support. Hopefully over the next few months, they can squash a few more bugs.

Day 3

I spent a good deal of time cleaning up my machine today. This meant removing old VirtualBox VMs and uninstalling VirtualBox since I have VMWare Fusion now. While doing that I noticed some old multi-GB docker images, Android Virtual Devices, and some other cached files from NVM, Gradle, Maven, etc that could be cleaned up.

I also noticed that some programs weren’t compatible with Mojave. This wasn’t an issue with the new MBP, as the same needed to be done on my old laptop as well. This just meant downloading and installing updates to things like KeyCastr, Robo 3T, Android File Transfer, Postman, Logitech Camera Settings, Logitech Control Center, etc.

While Git, SSH, GPG, and many other CLI tools were working fine after the migration, there were still some issues with MacPorts giving some plist warnings when running sudo port selfupdate. I followed the steps in the Install Guide and I was back up and running (without needing to do the steps in the Migration Guide).

I also spent some time customizing the key mappings when using my external keyboard via Karabiner Elements. While doing this, I noticed that my volume up, volume down, and mute keyboard buttons were working w/o the need to map them to a Function key. Some time ago, this wasn’t working on my 2014 MBP, but I didn’t go back to verify if this still an issue on that device.

Just like I saw with the built-in keyboard, the caps lock light not coming on while using my Logitech K800. I tried to enable Karabiner’s option to “manipulate” the Caps Lock LED, but it didn’t help. **Solved: **this turned out to be a bug in Karabiner that was fixed in their beta a couple months ago and just got fixed in their stable release in February 2019.

I ran into some confusing behavior in Chrome that seems to be related to the Migration. I went into Sharing Settings to give this new Mac an updated Name. This didn’t seem to help though. Whenever I go into Chrome’s History and look at “tabs from other devices”, I can’t see tabs from my 2014 MBP. It’s like Chrome somehow thinks that the two devices are a single device. I disabled and re-enabled sync on both devices without any luck. I stopped short of completely clearing my sync data, which the forums mentioned may be required.

I also setup Chrome Remote Desktop. After the migration, this meant disabling remote desktop on both MBPs and then re-enabling it with updated names and PINs.

Overall, things are feeling clean and fast now. This “Spring cleaning” cleared up around 20 GB of disk space.

I also watched a nice summary video on this machine from AppleInsider

• Vega 20 MacBook Pro Review — The Dream is Finally Complete!

It looks like some of my keyboard settings didn’t make the migration. I noticed that I wasn’t able to hold a key to have it repeat. This is especially important with delete. I found that the “Delay Until Repeat” setting in Keyboard settings was set too long. I moved it to the second shortest value. Then delete started working as expected. So of course I tried it with some other keys like aaaaaa, but that didn’t work! Instead, it opened up an accent picker.

This was new to me. An AppleInisider article helped me understand what was going on. I am happy with the option shortcut method:

This screenshot is showing that if you want to type ü then you need to press option+u and then u again. Using this same approach but typing option+u and then e will give you ë. Great! This will work perfectly for me when I need to use different accents (something that I am trying to get better with in Spanish).

However, I want to repeat keys on long press. To do that, I found this answer which advised running the following in the Terminal to disable the accent picker on long press:

defaults write -g ApplePressAndHoldEnabled -bool false

Then you need to reboot for it to take effect.

Day 4

I went back to work with a full focus on productivity. This machine blew my mind with its speed 🚀 and general productivity boosts ❤️. I haven’t taken measurements yet (planning on it), but there is a very noticeable improvement in the speed in my every day development and testing tasks.

Day 5

I decided to dig into the media aspect of this device. I used an Anker USB-C SD Card Reader to pull 25 GB of photos off of my DSLR. Then I proceeded to copy and organize those files before batching uploads to both Google Photos and a Synology NAS. This resulted in driving the network card and CPU quite heavily for many hours in a row. Everything went extremely smoothly.

I’m not an experienced video editor, but I did some work on some small video editing in iMovie. I’ve identified a 2.75 GB video that I plan to do some additional testing with. Other than my own issues learning to use the iMovie user interface, everything here went smoothly as well.

The Logitech MX Ergo Trackball arrived. Pairing it up with the Logitech receiver and installing Logitech Options was simple. The transition from the Logitech M570 Trackball was pretty smooth. After a few hours, most all the minor differences faded away. This even included using the Ergo at the 20 degree tilt. I appreciate the minor amount of extra friction / stepping in both the trackball, and the mouse wheel. The precision mode is very handy, but I forgot to use it earlier when I was editing images in GIMP.

Day 1

My Pixelbook arrived this afternoon. Within a few hours, I’ve already got my primary dev tooling installed and working! There were only a few minor bumps in the road, and they were quickly resolved with a quick Google search.

I’m curious how things will play out over the next week as I try to push it for productivity tasks.

I’ll also be monitoring the thermal performance since I don’t want to be working at some point in the future with burning finger tips. So far today, I felt some heat when I reached up above the keyboard and below the screen. However, when I checked Cog, the temps were actually not bad at all (160 F / 71 C or less).

With the machine mostly idle, 4–5 tabs open, while I wrap up this post, the CPU is barely over body temperature at 104–109 F.

The battery life is very impressive so far. I’ve been off of power most all day, and I’ve still got over 30% power remaining and almost 3 hours of estimated run time.

I’ll also be doing a good deal of testing with Bluetooth. I was able to use an LG Tone 700 headset for over an hour today without any disconnections or issues.

There has been one minor usability glitch that has bothered me a few times today. On about 5–10 different occasions, the machine seemed to lag or freeze up. Sometimes this was only affecting the scroll of the touch pad, or the responsiveness of the touch screen. Other times the entire UI was frozen and there was no way to interact with the device. This generally only lasted 1–20 seconds… until just about 5 minutes ago.

I wrote 99% of this post on the Pixelbook, but I’m finishing up the first draft here on my mid-2014 MacBook Pro. With 30% battery left and low heat (as seen above), I closed all of my Linux and Android apps. I also closed a few open tabs to get down to only 4 tabs open. Then while making minor edits to this post in the Medium web app, everything froze.

It never came back. After about 5 minutes, the machine rebooted itself to this:

I pressed the power button and tried to reboot it, but it just turned off. There were no connected devices. Nothing I did was able to wake it back up, even holding the power button for 30+ seconds, until I plugged it into power. It then booted up pretty quickly and still had 29% battery left.

That was… a little scary. When I first unboxed the device, I had a similar experience. I couldn’t get the power button to do anything. Only when I connected my Pixel XL via USB-C did it power on and start responding.

Day 2

I found out that the Chrome OS missing or damaged screen isn’t new and isn’t that uncommon.

I didn’t have a lot of time today for development tasks, but I did get a good deal of web browsing, and a little Android gaming done. I found that using the device on the lap in either tablet or laptop mode did not generate enough heat to bother me. This was after about an hour of web browsing and some Star Wars Galaxy of Heroes.

On the gaming side, I’m still getting a feel for the touch screen as there are quite a few occasions where I don’t touch it with enough force to register and need to tap again. Gaming performance-wise, I’m seeing a significant improvement over my Nexus 9, but I feel like my Pixel XL may outperform the Pixelbook in the GPU category.

I was able to get the Google Cloud SDK (gcloud) installed using their instructions for Debian.

I was able to get IntelliJ IDEA installed and running with almost the same instructions that I used for WebStorm. I ran into an issue with the Google Cloud Tools plugin and opened a bug.

I was also able to get Android Studio installed and running. I am generally able to install the SDKs and libraries and get my Gradle builds to succeed. However, there are a number of other minor issues like not being able to sign in to Google due to the callback going over a port that isn’t forwarded to Crostini and resolution of secondary SSH keys when using Git. Android Studio suggested that I install libsecret-1-0 and gnome-keyring so that it could preserve access to my keys, but it doesn’t appear to be working.

I’m also seeing an issue where I need to re-authenticate with GitHub either after rebooting or re-launching of WebStorm. It says “missing access token” as if the previous token has been lost. I’m seeing similar issues using a secondary SSH key in WebStorm as well.

I’m getting the feeling Crostini and Chrome OS are on the edge of being a real development platform. However, the concern that Crostini (beta) may have too many productivity-draining issues with edge cases is getting more real.

Day 3

I spent many more hours trying to get a second SSH key to work in IntelliJ IDEA and WebStorm. I tried both the Built-In and Native SSH, but had no luck. Then I learned about, and setup, a ssh-agent service with systemctl. Additionally, I tried keychain and gnome-keyringsome more. Even though everything appeared to be set up properly and worked from the Terminal, it would never work from the IDE.

I finally just gave up and decided to use the key for associated with my BitBucket account for accessing both GitHub and BitBucket. I was able to add that email address to my GitHub account. I’ll have to wait and see if this causes me problems with some PR review bots, commit verification, or CLA checks in GitHub.

I found out today the issue I reported about the Google Cloud Tools plugin for IntelliJ IDEA wasn’t specific to Chrome OS. It was just an issue that they hadn’t added support for the latest version of IntelliJ (2018.3). They released that fix today, and it resolved the issue.

I did however run into another problem with that plugin. It uses a strategy where it logs you in via OAuth redirects. However, when it tries to send the confirmation back to the IDE, the browser shows a Not Found page. This is because they use a random high level port (40–60K) each time, and those ports are not forwarded between Crostini and Chrome OS. Only some well-known ports are forwarded. For now, being logged into the Google Cloud Tools plugin is not critical for my work, so I am going to ignore this issue.

That said, Firebase is critical for my work, and they use a similar model for authenticating with their firebase-tools CLI. I’ll have to give that a shot soon to see if it will be a problem.

Another important activity that I did today was hosting a two-hour Hangouts Meet video call. I did the whole call connected to my LG HBS 700 Bluetooth headset without any issues. I did some screen sharing and navigated through a few tabs while on the call. Everything was smooth for about 99% of the call. I didn’t notice any excess heat being generated and the keyboard and palm rests were still comfortable to use.

The other person on the call was also using a Pixelbook. While the video quality on both sides was acceptable, I wasn’t really impressed. The Pixelbook has a 720p 60 FPS webcam which should be similar in quality to my MacBook Pro mid-2014’s 720p webcam. However, in this small sample, I felt that it wasn’t really up to par with my MacBook Pro. There was a bit of graininess and as it got dark, the low light performance didn’t seem to be very good.

Note that this is just anecdotal evidence based on a general feel and not head-to-head comparison.

I also have some feedback on the keyboard, palm rests, and track pad. In general, the keys have a really nice feel and are a pleasure to press. I do still get a little disoriented at times and end up pressing keys 1 column to the right, but I don’t see that being a long term issue.

I VERY frequently press the Assistant key when I do not desire to speak with the Assistant. I really wish that it was up near the function keys, perhaps replacing the hamburger/settings key. However, I haven’t taken the step to disable it yet, but it’s certainly under consideration.

The palm rests are excellent! They are very comfortable and keep quite cool! Similarly, the track pad is really a pleasure to use! Sometimes Chrome OS doesn’t scroll quite as smoothly or responsively as I would like, but that isn’t an issue with the track pad itself.

I did some interesting reading today over at the Crostini Wiki and Simos Xenitellis’ Blog. The wiki has some great resources and guides for installing and configuring different tools. The blog post covers some internals of how Crostini is built.

Oh! Finally, I learned how to insert emojis 🌟! This is also helpful for adding in some special characters like jalepeño. Unfortunately, the emoji picker doesn’t have text search (like macOS or Slack) 😞 and there are no tooltips on hover to help you differentiate similar emojis. Additionally, there appears to be a bug where I’m not able to use the trackpad to scroll through all the emojis (the touch screen does allow you to do this though).

Day 4

While I have not run into Bluetooth issues with my Pixelbook, there are a lot of other reports out there. It looks like a firmware fix from Intel will help mitigate some of these issues in Chrome 71 (beta). Stay up to date by starring this bug.

I’m finally running into random Bluetooth disconnections. I had 3 of these today in about 30 minutes of SWGOH with my LG HBS 700 connected. One note on the positive side, this is certainly the best sound I’ve ever had on SWGOH. On some Android devices (like the Nexus 9), I can sometimes get poor, crackling audio. On the Pixelbook, it was so crisp and deep! I heard sounds that I had never been able to discern before!

It looks like there is some bad news for Pixelbook Bluetooth users in the above bug. Today, the Chromium team responded that while things have been improved with the firmware update in Chrome 71, there is still an underlying hardware issue that won’t be able to be resolved in existing hardware (Pixelbooks included).

If you need a device with solid Bluetooth performance, it doesn’t look like the Pixelbook will work out for you. The bug mentions that the Pixel Slate and ‘Nami’ devices, including the Acer Chromebook 13 and Spin 13, should have the hardware capability to have Bluetooth that auto-recovers (without a reboot) when it has issues.

I spent a couple of hours coding while streaming Google Play Music over Bluetooth via the web (not the Android app). I wanted to try this to see if my earlier disconnects were related to actively using an Android app. It wasn’t related. I had about 6 more disconnects (with no auto reconnection) over this time. Again, the sound seemed very clear, but the disconnections make it problematic to use the Pixelbook with any Bluetooth accessories 😞

Day 5 — Beta Channel

Today I decided that it was time to try the Beta Channel of Chrome OS. The main reason was to try out the Intel firmware update for the Bluetooth/Wi-Fi chip. It took about 15 minutes to download, install the updates, and reboot.

This evening I streamed music while coding for about 5 hours with numerous breaks, disconnections due to going out of range, turning my headset on/off, etc. I also got in about 30 minutes of SWGOH with BT. Thankfully, I can report that I did not have a single bogus disconnection, and the system’s BT did not disable itself.

I didn’t do any coding or fiddling with configuration today. I needed to get my productivity up, so I stuck with my MacBook Pro for dev today.

Day 6

I was busy working on my MacBook Pro for most of the day, but I streamed Google Play music for at least 3–4 hours on BT without any disconnections or issues.

I also ordered a set of USB-C to HDMI adapters so that I could do some testing with dual external monitors. I didn’t want to spend the money on a whole USB-C Hub with video out yet.

Day 7

I hooked up the following today

• Uni USB-C to HDMI adapter to AOC 27" monitor

• Anker 10 port USB-A 3.0 Hub

• Logitech K800 Wireless Keyboard

• Logitech M570 Trackball

• Western Digital 1 TB My Book for Mac

In this configuration, I was only using one of two monitors, but this allowed me to have WebStorm running side by side: macOS vs. Chrome OS.

I messed with the scaling in the Chrome OS display settings a bit. However, with this configuration, anything but 100% scaling resulted in blurry text in WebStorm. I needed to bump my font size in WebStorm up from 9 to 12 (same as in macOS). I had previously lowered it for the Pixelbook display. Later when I opened WebStorm settings, it appears that the font size was auto converted to 28.

I also had to tweak the font since the Menlo font that I use on macOS isn’t available on Chrome OS. I settled with Fira Code Medium.

With the scaling and font sizes sorted out and both displays of WebStorm (macOs, Chrome OS) looking similar, here’s what I noted

• The text in the Project panel (where your files and directories are) has a real nice contrast in macOS, but it’s smaller and dull in Chrome OS.

• Many parts of WebStorm on Chrome OS are smaller and need to be scaled up to match the size on macOS. Unfortunately, I can’t do that due to the blurring.

• Fonts and UI elements are significantly sharper on macOS. This actually used to be a weakness when running any IntelliJ product on macOS compared to Windows. However, JetBrains solved this issue a couple of years ago. It looks like some kind of similar fix is needed for Chrome OS’ Freon graphics stack.

After this, I decided that I needed to get two external monitors set up. However, this meant losing my external mouse and keyboard since I don’t have a USB-C Hub. The good news is that the Pixelbook’s keyboard and trackpad are excellent, so I’m using them in that configuration to write up this post. Of course this also means that I can’t charge in this configuration due to only having 2 USB-C ports. For any longer term use, you would certainly want a USB-C Hub to solve that.

So configuration #2 consisted of the following

• Uni USB-C to HDMI adapter to AOC 27" monitor

• Uni USB-C to HDMI adapter to AOC 27" monitor

I had to plug in the 2nd monitor twice as the first time it wasn’t recognized by Chrome OS. The second time it worked fine and was available in the Display settings. I was able to set up the monitor positioning (each 27" on one side of the PB’s internal display. This was quite a nice experience.

The first thing I tried was to move an open Chrome window from my PB’s internal display to one of the external monitors. This crashed Chrome OS and I lost my WebStorm instance which was hosting an Angular CLI project and Firebase Functions.

I was able to open the Chrome window again and move the tab back to the external display. I have read online this is a common issue with Chrome OS. However, I haven’t yet tracked down the related bug on https://crbug.com.

The other issue that I ran into here, which I don’t think is restricted to external monitors, is that Linux apps which are running in fully expanded windows don’t have their position remembered when they restarted. This means that I have to use an extra click every time that I open an app to make it take up the full screen.

These are software bugs which should be fixed. I’m not sure if the blurry scaling and lack of sharpness in WebStorm is 100% a software problem, but it certainly needs to be addressed by either the Chrome team or JetBrains. For now, these issues make the whole external monitor experience on Chrome OS sub-par. It’s certainly workable but, much like tablet mode, there seems to be quite a lot of space for improvement.

Some additional positive notes:

Letting the Pixelbook go to sleep connected to external monitors worked well. I was able to wake it using a variety of options including an external mouse, external keyboard, and the Pixelbook’s trackpad and keyboard. All the window positions and states were intact.

Issue with moving Android apps between monitors - Solved

When I open certain Android apps, like SWGOH, the app appears to open in the first monitor. This happens even if you launched the app from the launcher on another display. In my case, it opens in the left external monitor. However, I want it to open on the Pixelbook’s internal display so that I can use the touch screen. There doesn’t appear to be a way to move a full screen app like this from one display to another. It’s impossible to take the app out of full screen mode either via the mouse cursor, or the full screen button on the Pixelbook. There are some articles about shortcuts for moving windows across displays, but they reference the out of date Launcher+Alt+Arrow shortcut.

The shortcuts for snapping windows to the left/right half of the screen with alt+[ or alt+] work for me, but that’s not what I want to do here, and they don’t work with full screen Android apps like this.

Finally, I decided to open the Chrome OS shortcut search panel via Launcher+Alt+/. Then searching for “move” immediately showed me the proper shortcut: Launcher+Alt+m. This works!

Like a number of functions in Chrome OS, a keyboard shortcut is the only way to access the functionality, and the discoverability of this functionality is poor.

More notes on the general developer experience

I mentioned in a day 3 that the Google Cloud Tools plugin login didn’t work due to the redirect not being mapped between Crostini and Chrome OS. This wasn’t the case for logging in from the Firebase CLI via firebase login. Everything worked smoothly there. I also tried the Google Cloud SDK via the gcloud auth login command and that worked well.

On the Pixelbook, I always saw an accumulation of the same error in my browser console when I have a site open in live reload (dev) mode:

Unchecked runtime.lastError: The message port closed before a response was received.

I’m not sure what is causing this or how to solve it. However, it does not appear to be causing a significant issue.

I did some performance tests with Angular CLI v7.1.0. Eventually, I decided to test against a brand new ng new project. I used the existing project only for build times, but not reload times as they were too funky due to the project using a number of different libraries. For comparison, I included some numbers from my primary dev machine: a mid-2014 i7 16GB RAM 256GB SSD MacBook Pro.

Pixelbook Performance in a new project

Time to run ng serve: ~16s

Time to refresh the browser on a page served via ng serve: ~1s

Round trip for making a change and seeing it live in the browser: ~2–3s

Production build time: ~33s

Pixelbook Performance in an existing project

I had to throw out the browser refresh and round trip times here due to an issue with this project that caused both platforms to run much slower than they should.

What about that production and dev build times though?

Production build: ~3 minutes

Dev Build: ~29s

For the production build, looking at the CPU cores in Cog, a few of the longer running tasks like the TerserPlugin have significant portions that run on a single CPU. When this happened, the other CPUs were hanging around 5–25% while one CPU was around 90–100%.

This was done on battery power and none of these tests really drove up the thermals in any significant way. Everything continued to run around 105–140F.

Building significant AngularJS project

I also tried and AngularJS project that just uses Gulp and gulp-connect. In this case the build took ~22s and live reload did not work at all. On the MacBook Pro, this project builds in ~17s. This app also had the same console errors.

By default, the app used http://localhost:35729/livereload.js?snipver=1 for live reload. I was able to get gulp-connect livereload working using the following config:

livereload: { hostname: ‘penguin.linux.test’ },

This did not fix the console errors, but it fixed live reload.

MacBook Pro Performance in a new project

I wanted to provide some comparable times for the above data points in the same project on my 2014 MacBook Pro. These are numbers that I’m mostly fine with and would like to see equaled or improved upon by a new laptop.

Time to run ng serve: ~10s

Time to refresh the browser on a page served via ng serve: ~1.5s

Round trip for making a change and seeing it live in the browser: ~2–3s

Production build time: ~26s

MacBook Pro Performance in an existing project

Production build: ~2m 19s

Dev Build: ~26s

Android App Launch Performance

On Android, one of the slowest tasks that I do with apps is opening up SWGOH.

Here’s the data:

• Nexus 9: ~70s
• Pixel XL: ~34s
• Pixel 3: ~21s
• Pixelbook: ~15s

Performance Summary

The Pixelbook was 10–40% slower for CPU intensive tasks like running builds. I was surprised that it refreshed pages in dev mode approximately 0.2–0.4s faster than the MacBook Pro. This may be explained by the fact that the Pixelbook is running Chrome 71 while the MacBook Pro is running Chrome 70. Or the Pixelbook is just slightly better tuned for running Chrome?

These results aren’t overly surprising. The Pixelbook is running a newer generation i7 processor, but it’s also tuned for mobility and thermal performance in a laptop w/o fans. The Pixelbook is also half of the price of this mid-2014 MacBook Pro.

Overall, performance-wise the i7 Pixelbook packs enough punch to do web, backend, and Android development, but it won’t blow you away with speed.

Day 8 - Powerwash

One of my goals when picking up the Pixelbook i7 16GB RAM 512 SSD was to see if it could serve as an effective backup development machine.

This is due to the fact that my mid-2014 MacBook Pro i7 16GB 256GB SSD w/ Intel graphics is well outside of it’s extended Apple Care warranty. The MacBook Pro still works great and does most everything that I need. I’ve found that the 256 GB SSD is a little too small for me, and I’ve run into cases where I wish that I had more graphics power. That said, it has proven to be an incredibly reliable, performant, and productive tool over the last 4.5 years. It was clearly one of my best tech purchases, ever.

My testing in the last week has proven that the Pixelbook can indeed fill in as an emergency backup development machine.

That said, there are still enough rough edges in Chrome OS and Crostini (beta) that getting things set up properly and keeping things running over time will be too large of a drain on my productivity. This is obviously a personal decision. If you don’t have kids and find that you have a lot of spare time in your life, then you may make the opposite choice here.

Another aspect of this decision also relates to productivity. That is the speed and smoothness with which I would be able to make the transition from a temporarily or permanently disabled primary development machine (my MacBook Pro). While I use almost no macOS-specific apps, preferring mostly Linux-based apps, it is still not a simple transition for me to switch my dev environment from macOS to Linux. There are a number of contributing factors here:

1. My MacBook Pro time machine backups are on a USB-A 3.x drive that my Chromebook cannot read due to the Mac OS Extended Volume Hard Drive Format (HFS+).

2. The Pixelbook does not support Thunderbolt 2 or Thunderbolt 3. So peripherals for my MacBook Pro need extra adapters and if I upgrade to a new MacBook Pro there will be peripherals that may not work with the Pixelbook. This problem is especially painful when it comes to \$300+ docking stations to support dual external monitors.

3. There are minor differences between the two systems which would cost me a good deal of time to mitigate. These include font and resolution settings in IDEs, differences in window management behaviors and shortcuts, differences in keyboard layouts, etc.

I’ve seen some reviews out there about Chrome OS and the Pixel Slate. They mention the idea of a thousand little cuts. Each one may have a work around or mitigation, but taken on a whole there are enough of them that the total impact is significant.

Thankfully, most of these issues are on the software side and will be improved or resolved over time! I feel strongly that Chrome OS has a strong future in most all markets (even development).

The Pixelbook is an amazing device for so many people today. It’s going to keep improving over time, especially since it will get updates for 7 years after its launch date instead of 5 like many other Chromebooks.

Now the Pixelbook hardware

Most of it is amazing. The keyboard and trackpad are superstars. The overall feel is very solid and premium. I was happy with the thermal performance and quiet fan-free usage.

The hinge worked great for me in most all cases. It has a little more movement than I’d like when touched in non-tablet and tent modes. Plus you need to hold down the keyboard when opening the screen. This is a hard problem. In one case I want the hinge to be more stable and in another I want it to open more easily.

I have very positive and negative opinions on the Pixelbook’s screen. The bezels are indeed enormous, but it’s not a deal breaker for me. I much prefer the 3:2 aspect ratio over the wide screens seen on many of laptops (Dell, etc.). This gives more vertical space for productivity tasks like reading, writing, or coding. The screen is impressively thin. The webcam worked well enough, but did not impress me.

The Pixelbook has 235 pixels per inch, and my MacBook Pro has 220 pixels per inch. The Pixelbook’s display has 400 nits of brightness which makes it usable outdoors. My MacBook Pro only has 320 nits of brightness, and it doesn’t excel outdoors. That said, new MacBook Pros have 500 nits of brightness.

On paper, the Pixelbook’s screen is very solid. However, in practice I found that changing resolution or scaling display output resulted in blurry or pixelated images and text. This was likely due to Chrome OS’ Freon graphics stack, Linux apps being in beta, and Android apps not being fully tuned to Chrome OS yet. This resulted in a display experience that I wasn’t completely satisfied with.

Stone Peak 2 by Intel

The Intel Bluetooth/Wi-Fi combo chip is the primary reason that I am returning the Pixelbook. I had many occurrences in Chrome OS 70 (Stable) of Bluetooth disconnecting and not auto reconnecting on me.

This device has been on the market for a year now. Lately, I’ve been waiting to buy a number of tech products until they have been in the market for a few months. This gives me the chance to see which products have serious flaws and which have flaws that can be addressed via software updates. This strategy has saved me a lot of wasted time, frustration, and money in the last 4 years.

That said, the Pixelbook still having serious feature-breaking problems in the Stable channel after a year is too much for me to ignore. Yes, I had better luck with Chrome 71 (Beta), but there are numerous users who are still reporting Bluetooth issues with that build. I don’t have the luxury of waiting to see since the return period is only 15 days. Plus I’ve already spent as much time testing this device as I can afford.

Additionally, comments in the various Bluetooth bugs in the Chrome OS issue tracker seem to indicate that there is a hardware flaw or missing feature with the Pixelbook’s Intel Stone Peak 2 Bluetooth/Wi-Fi chip. There is some additional discussion of this issue on Reddit.

Final Decision

It doesn’t seem wise for me to spend \$1,700+ on a device that has an issue like this that may never be fully fixed. Bluetooth is something that I make heavy use of, so issues with this chip could seriously impact productivity.

That combined with the many little cuts to productivity, mentioned above, resulted in me making the decision to return the Pixelbook.

Next Steps

If I can pick up the cheaper model on a big discount, then I would love to have a Pixelbook, but I can’t justify keeping the top end model.

I will certainly continue to keep my eye on high-end Chromebooks which can be used for development. I’m excited by the progress and goals of Crostini. Additionally, I’m also confident Android apps on Chrome OS will continue to improve each year. I do plan to make a Chromebook my primary development machine at some time in the future.

Until then, I am planning to stick with MacBook Pro devices for my primary development platform. I’m very happy I’m able to test my web apps on Android, macOS, iOS, Windows, and Chrome OS using a MacBook Pro. You can find out more about running Chrome OS in a VM on a MacBook Pro in this Twitter thread.

If you haven’t checked it out yet, DevFest Florida is happening at Disney World’s Contemporary Resort on January 19th. The list of speakers is really impressive. Tickets for students and professors are only $99 (plus fees) and general tickets are $175 (plus fees).

If you are interested, I am happy to offer readers 25% off of general ticket prices using this link! I hope to see some of you there.

Note: I wrote a separate, detailed post about my initial Pixelbook Developer experience.

Now let’s get down to the business of getting your machine ready for some Angular development!

Get updated

First, make sure you update to the latest patch by checking for an update in your status bar (click the clock). Select the option to reboot and install the update if one exists. Ideally you are on Chrome OS 70 or later.

You can check your Chrome OS version in Settings->Hamburger menu->About Chrome OS.

Enable Linux Apps (beta)

Go to the Support Page for Linux Apps and follow the instructions. In my case, there were some upgrades available from apt-get.

Install Java

From your Linux terminal:

sudo apt install openjdk-8-jdk

Install WebStorm

Go to the JetBrains WebStorm Download page and click the Download button.

In your Linux terminal, create a downloads folder:

mkdir ~/downloads

Open the Files app. Copy your download from My files->Downloads to Linux files->downloads via drag and drop.

In your Linux Terminal, extract the WebStorm archive into /opt:

sudo tar xf ~/downloads/WebStorm-2018.3.tar.gz -C /opt

In your Linux Terminal, launch WebStorm:

/opt/WebStorm-183.4284.130/bin/webstorm.sh

Note that your path to the WebStorm directory will be slightly different per version.

Go through the setup steps and make sure the box to create a Desktop Entry is checked (default) but don’t check the box for All Users. Complete the wizard, give WebStorm a minute to settle, and then close it.

Launch WebStorm from the Chrome OS Launcher

That last step made WebStorm available in the Linux apps directory of the Chrome OS Launcher.

Launch WebStorm from the Chrome OS Launcher and repeat the setup steps other than creating a Desktop Entry.

Setup SSH

Now for using GitHub, you will want to setup SSH and GPG. We’ll start with SSH.

Follow these steps to generate a SSH public and private key for your Pixelbook. If the part about “Adding your SSH key to the ssh-agent” is empty, scroll to the top and make sure Linux is selected. Then follow those steps. I reported this issue to GitHub, so manually selecting Linux for Chrome OS should not be required once they fix their user-agent detection.

Open GitHub SSH and GPG keys and create a new key with the contents of id_rsa.pub. You can get the contents via

cat ~/.ssh/id_rsa.pub

Now back in WebStorm, you need to set up GitHub under File->Settings->Version Control->GitHub. Check the box for “Clone git repositories using ssh”. Then click “Add account”.

Fill in your username and password. It will prompt you for your 2FA code in the next step. If that is successful, GitHub will be configured properly.

Additional SSH Agent Configuration (optional)

If you created your SSH key with a password (recommended), then you need to make sure the SSH Agent prompts you for your password after a reboot. There are many options available for doing this task. We’re going to use a simple setup that uses an open source package called keychain.

In your Linux Terminal, install keychain:

sudo apt-get install keychain

Open your ~/.bashrc file and add the following line at the end:

eval `keychain --eval id_rsa -q`

This setup will prompt you for your SSH key’s passphrase only once per reboot.

Note: You can use vi to make this change or install something like nano if you prefer. Remove the -q if you want keychain to print some information every time you open a shell. This comes from a couple different sources: StackOverflow, Unix StackExchange.

Setup GPG

Check if you already have GPG2 via

gpg --version

If not, in your Linux Terminal, install GPG2:

sudo apt-get install gpg2

If you have a new Pixelbook, then you can go straight to installing GPG. If your Pixelbook is not new, then you should check if you have any existing GPG keys.

Follow these steps to generate your GPG key and export it to a format for adding to GitHub.

Setting up a GPG key allows GitHub to show the green “Verified” label next to the commits in your Pull Requests.

Clone a repository in WebStorm

In WebStorm, checkout a Git repository:

If you successfully logged into GitHub earlier, then your repositories will be available in the URL drop down.

Note that the first time you clone, it should warn you about an unknown host and allow you to add that host and remember it.

Also make sure that you choose a directory in your home directory and not in /root/. It picked ~/Webstorm/Projects/ for me.

Configure WebStorm

If you use WebStorm on another computer, you can sync your settings there and have your Pixelbook pick those settings up easily.

On your Pixelbook, in the bottom right-hand corner of the screen, click on the Gear with the question mark. Then select “Enable Sync…”

Select the option that works best for you. Then after a minute, you should be able to click on the Gear again and either Sync your Plugins silently (e.g. install all the plugins that are on your other computer and disable plugins that are disabled on your other computer) or choose which plugins should be synced and which should not.

Install NodeJS and NPM via NVM

As described in the NVM docs, in the Linux Terminal run:

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash

Reload your terminal to get access to NVM by running: source ~/.bashrc

Now running nvm --version should output 0.33.11.

Install NodeJS LTS (Long Term Support) and the matching version of NPM by running:

nvm install 10

Setup NodeJS in WebStorm

In WebStorm, open File->Settings->Languages and Frameworks->Node.js and NPM. Node and NPM should be automatically detected. Check the box for “Coding assistance for Node.js” and press OK.

Now restart WebStorm so that it can initialize some more NPM features. When WebStorm opens again, you should see a popup where you can have the IDE run npm install for you.

Run a NPM Script

WebStorm makes it easy for you to open your package.json file and run one of the scripts provided by the repository.

Install Yarn

Many Angular projects now require Yarn.

The easy way is to do npm i -g yarn, but you can also use the following steps taken from the Yarn Install docs for Debian:

Add Yarn’s public GPG key and repository to Debian’s package manager by running the following in your Linux Terminal:

curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -

echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list

In your Linux Terminal, install yarn:

sudo apt-get update && sudo apt-get install --no-install-recommends yarn

Check the installation was successful by running yarn --version which should output a version similar to 1.12.3.

Similar to above, WebStorm will prompt you to run yarn install when you open a new project that uses Yarn.

Conclusion

Please note that the steps above for WebStorm are nearly identical if you are installing IntelliJ IDEA or many of the other JetBrains IDEs.

I hope that this post is useful to some intrepid developers who are ready to get productive with their Pixelbooks! Please leave comments if you run into any issues or if something doesn’t work, and I will try to update this post.

If you haven’t checked it out yet, DevFest Florida is happening at Disney World’s Contemporary Resort on January 19th. The list of speakers is really impressive. Tickets for students and professors are only $99 (plus fees) and general tickets are $175 (plus fees).

If you are interested, I am happy to offer readers 25% off of general ticket prices using this link! I hope to see some of you there.

References

Some information for this post was taken from the helpful Crostini community on Reddit.

I was also able to get Gimp 2.10.x installed thanks to the ChromeOS community on Reddit.

This old, locked support forum post mentions the Dell D6000 dock which people have had some luck with. There appears to be an issue where the dock will lose connection with the monitors every couple of hours. This seems to be commonly reported by users of Dell docks (across reviews of many of their existing USB-C docks). I’m not sure if any of those posters using the D6000 were able to solve this issue or not.

Keith Meyers’ blog mentions successfully using the Pixelbook along with the Plugable USB 3.0 Universal Laptop Docking Station. This is a dock from 2013.

The Plugable USB-C 4K Triple Display Docking Station with Charging Support is from 2017 and has 4K@60fps support via DisplayPort. It also supports charging the Pixelbook.

In the Q&A, the Plugable states that the Pixelbook is fully supported. However, I’d like to hear from the community whether you were able to get this dock working and if you ran into any issues.

Another interesting option is the CalDigit USB-C Docking Station. It only supports two monitors, but that is sufficient for me. For two monitors, you need to use DisplayPort Multi-Stream Transport which Chrome OS added support for in the Spring of 2018. This means that the DisplayPort port would drive both monitors, and the HDMI port would be unused. Since my monitors are HDMI, I would need to use a MST Hub to split the signal and then DP->HDMI adapters.

This CalDigit setup seems a bit involved and possibly slightly risky. I’d love to know if anyone has gotten it to work this year.

Are you using another dock that you’ve found works great for you? Please let me know.

This release is now available in our Online Documentation, NPM, and Bower. It is also available on the Google CDN (JS, CSS).

You can find the details for all releases in our Change Log.

Highlights

v1.1.10 should be our most stable release in many months. Here are some highlights:

• Fixed four significant regressions to chips that were introduced in 1.1.2 and 1.1.9. Two of these were also a11y issues.

• Fixed a memory leak when elements using md-theme are removed from the page

• Fixed select to support selecting options by typing when the option contains a period (i.e. 255.255)

• Improved dark mode theme support for menu-bar and datepicker

• Fixed ripple animations getting stuck on iOS in certain situations

• Fixed a couple layout issues

• Significant improvements to the project’s documentation including 3 new demos

This is a patch release with non-breaking changes (fixes and enhancements).

Bug Fixes

• chips: editable chip gets removed after editing

• chips: improve ability to receive focus on click

• chips: regression where chips model gets out of sync with view

• chips: unwanted re-focus of last chip after blur

• compiler: remove dependency on AngularJS private API

• datepicker: calendar panel theme supports dark mode in multi theme scenario

• layout: allow flex-offset to be a child of layout-margin

• layout: reduce layout CSS size by reverting some of #11247

• menu-bar: md-menu-bar panel theme supports dark mode themes

• nav-bar: missing [disabled] scss selector

• ripple: fix iOS Safari stuck ripple issue

• select: doesn’t search correctly when pressing period character

• theming: md-theme leaks when child elements are removed

Features

• mdMaxlength: support use with required and ng-trim

Documentation

• datepicker: fix typos, general clean up, add calendar demo, add moment.js demos

• dateLocaleProvider: add missing documentation for isDateComplete() and longDateFormatter()

• virtual-repeat: fix typos, clean up, and clarifications

• tabs: add link to tab docs, clarify the notes about nav-bar

• select: clarify the behavior of the multiple attribute

Contributors

Thank you to the contributors, especially the first timers, who helped with the v1.1.10 release:

However, if you read deeper into the article, you’ll find that the eye tracking research actually confirmed the importance of a number of key UI design guidelines.

If you are building user interfaces and you haven’t embraced the acronym CRAP yet, then I highly recommend that you look into it.

It stands for Contrast…. your important, interactive UI elements need to stand out.

Repetition… consistent UI patterns train user’s brains where to look.

Then you build a clear visual hierarchy through the use of Alignment and Proximity. This includes intelligent use of negative space (or whitespace) along with grouping items that belong together near each other.

This study hits on a key human factors issue. Complex, high density user interfaces cause users uncertainty and delay their ability to take action.

Now let’s take a look at some details of the study and how Material Design is already built to address these challenges.

“Flat UI” vs Material Design

On the left, we see a traditional link with the blue color and underline. The right side shows an example of an ultra-flat UI where positioning is the only signifier that the element may be interactive.

The eye tracking results showed that users of the flat design would try to click on the header first and often ignore the flat button completely because it’s click ability signifiers were too weak.

Material Design provides a number of different button types to address this type of situation. First there is the flat button. It stands out through the use of a contrast color in addition to capitalization. However, these buttons are not designed to be used for your more important actions.

In this case, taking the user to your pearl storefront is a primary action.

Material Design provides raised buttons for the cases where you want a strong click ability signifier, and the user’s gaze to be attracted by the color and height of the button.

In my next post, I’ll discuss the basic concepts of Material Design and try to distill the marketing and design language into something that a developer can make sense of.

If you don’t want to wait, you can start reading the Material Design Specifications now.

This release brings support for the typing changes in Firebase JS SDK 4.8.1+ and much awaited support for Firebase Cloud Storage!

Many thanks to @_davideast, @jamesuriah, and a number of community contributors for helping get this update out!

Full changelog here.

Troubleshooting

If you run into an issue using Phone Auth due to the types of firebase.app.App and FirebaseApp no longer agreeing like this:

ERROR in src/app/auth/auth.component.ts(67,5): error TS2345: Argument of type 'FirebaseApp' is not assignable to parameter of type 'App'.
  Types of property 'auth' are incompatible.
    Type '() => FirebaseAuth' is not assignable to type '() => Auth'.
      Type 'FirebaseAuth' is not assignable to type 'Auth'.
        Types of property 'app' are incompatible.
          Type 'FirebaseApp' is not assignable to type 'App'.
            Types of property 'auth' are incompatible.
              Type '() => FirebaseAuth' is not assignable to type '() => Auth'.
                Type 'FirebaseAuth' is not assignable to type 'Auth'.

Then you can solve the issue by the following steps

Add the new @firebase packages to your package.json:

"@firebase/app": "0.1.7",
"@firebase/auth": "0.3.2",

Change your firebase import

import * as firebase from 'firebase/app';

to use the new format (with the default export syntax)

import firebase from '@firebase/app';

This may then spit out the following error

error TS2503: Cannot find namespace 'firebase'.

For me, this was caused by setting the following type

phoneRecaptchaVerifier: firebase.auth.RecaptchaVerifier;

You can solve this by using the new @firebase/auth-types package

import { RecaptchaVerifier } from '@firebase/auth-types';

Then just remove the firebase.auth. so that you have the cleaner version

phoneRecaptchaVerifier: RecaptchaVerifier;

Note: when calling a constructor like new firebase.auth.RecaptchaVerifier(), you’ll still need the firebase.auth. prefix.

What do these duplicated styles look like?

You can see the .mat-toolbar.mat-primary style at the top. Then you can see it down below once more. This time with the same exact styles (background, color) and values, but all of them overridden.

In this example, there is only 1 duplicate set of styles, but it is very easy to suddenly see 3 duplicate sets or 5 or more! As you might imagine, this can significantly impact your bundle size in addition to complicating the styling of your app.

Now show some examples to showcase how easy it is to get into this situation…

From the Angular Material Theming Guide

A typical theme file will look something like this:

styles.scss:

@import '~@angular/material/theming';
// Plus imports for other components in your app.

// Include the common styles for Angular Material. We include this here so that you only
// have to load a single css file for Angular Material in your app.
// Be sure that you only ever include this mixin once!
@include mat-core();

// Define the palettes for your theme using the Material Design palettes available in palette.scss
// (imported above). For each palette, you can optionally specify a default, lighter, and darker
// hue.
$candy-app-primary: mat-palette($mat-indigo);
$candy-app-accent: mat-palette($mat-pink, A200, A100, A400);

// The warn palette is optional (defaults to red).
$candy-app-warn: mat-palette($mat-red);

// Create the theme object (a Sass map containing all of the palettes).
$candy-app-theme: mat-light-theme($candy-app-primary, $candy-app-accent, $candy-app-warn);

// Include theme styles for core and each component used in your app.
// Alternatively, you can import and @include the theme mixins for each component
// that you are using.
@include angular-material-theme($candy-app-theme);

Now if this is all you do, you won’t run into problems, even if you ignore most of the comments.

However, we all know that real production apps need to integrate this code into a much more complex system. For instance, the full Angular Material theme may not be included in the App Shell (used to quickly paint the screen and let users on low bandwidth devices know that your app is bootstrapping).

In this article, we’ll use https://angular.io and its code as an example since many developers look at this AIO repo and copy the code from it into their own apps.

ng-io-theme.scss:

@import '~@angular/material/theming';
// Plus imports for other components in your app.

// Include the base styles for Angular Material core. We include this here so that you only
// have to load a single css file for Angular Material in your app.
@include mat-core();

// Define the palettes for your theme using the Material Design palettes available in palette.scss
// (imported above). For each palette, you can optionally specify a default, lighter, and darker
// hue.
$ng-io-primary: mat-palette($mat-blue, 700, 600, 800);
$ng-io-accent: mat-palette($mat-red, 700, 600, 800);

// The warn palette is optional (defaults to red).
$ng-io-warn: mat-palette($mat-red);

// Create the theme object (a Sass map containing all of the palettes).
$ng-io-theme: mat-light-theme($ng-io-primary, $ng-io-accent, $ng-io-warn);

// Include theme styles for core and each component used in your app.
// Alternatively, you can import and @include the theme mixins for each component
// that you are using.
@include angular-material-theme($ng-io-theme);

There’s a very important comment that has been removed from this version. // *Be sure that you only ever include this mixin once!*

Now if you miss that, and you use some other examples like the following, you may start to see duplicate styles and even need to resort to !important on many of your styles that target Angular Material classes like .mat-form-field or .mat-raised-button.

I have run into apps with these issues, and it has resulted in 500 kB to 1.5 MB of bloat in the developer build of the site. In production builds the impact is smaller, but every kB counts when shooting for great WebPageTest or Lighthouse scores!

main.scss:

// import global themes
@import '~@angular/material/theming';
@import './ng-io-theme';

// import global variables
@import './constants';

// import global mixins
@import './mixins';

// import directories
@import './0-base/base-dir';
@import './1-layouts/layouts-dir';
@import './2-modules/modules-dir';

You can see here that main.scss is including ng-io-theme.scss which includes @include mat-core();.

styles.scss:

/* You can add global styles to this file, and also import other style files */
@import './styles/ng-io-theme';
@import './styles/main.scss';

You can see here that styles.scss is including ng-io-theme.scss as well. Then including main.scss which also includes @include mat-core();. There is another include here that is getting duplicated as well, @include angular-material-theme($ng-io-theme);.

The AIO repo uses considerably more (custom scripts, rollup, etc.) than just the Angular CLI to bundle and deploy their application. I wasn’t able to determine exactly how they avoid duplicate Angular Material styles with this setup, but I did verify that there are not any duplicate Angular Material styles on the production site.

How should I do this in my app?

You probably want to stick closer to the Angular CLI only approach for your own apps as long as you can. So I’ll provide an example to use in that case.

styles.scss:

@import './styles/theme';

// Include the base styles for Angular Material core. We include this here so that you only
// have to load a single css file for Angular Material in your app.
// Be sure that you only ever include this mixin once!
@include mat-core();

// Include theme styles for core and each component used in your app.
// Alternatively, you can import and @include the theme mixins for each component that you are using.
@include angular-material-theme($app-theme);

html {
...

This is the src/styles.scss file found in Angular CLI projects with SCSS enabled.

• Styles in this file are applied globally without any ViewEncapsulation.

• This file is included in your app only once via the .angular-cli.json file via “styles”: [“styles.scss”].

• You should not import this file into any other SCSS file.

• The Angular Material @include statements should be in this file.

Note: If you are using an App Shell for your app, the Angular Material @include statements are probably in another file. Just make sure that it is only included once.

However, this file is free to include other SCSS files like your src/styles/_theme.scss found below

_theme.scss:

@import '~@angular/material/theming';

// Define the palettes for your theme using the Material Design palettes available in palette.scss
// (imported above). For each palette, you can optionally specify a default, lighter, and darker hue.
$app-primary: mat-palette($mat-teal, 700, 100, 900);
$app-accent: mat-palette($mat-orange);

// The warn palette is optional (defaults to red).
$app-warn: mat-palette($mat-red);

// Create the theme object (a Sass map containing all of the palettes).
$app-theme: mat-light-theme($app-primary, $app-accent, $app-warn);

In this file we define the $app-theme variable that is later used in src/styles.scss.

Note: We’re using a feature of SCSS here that is called “Partials”. You can find out more about them in this StackOverflow answer or in the official SASS docs. Note that the _ in the filename is very important here and changes the behavior of SASS.

Now this file can be imported in many places in your app to give you access to variables like $app-accent for use in a statement like the following without duplicating styles.

app.component.scss:

@import '../../styles/theme';

.noRecordsContainer {
  padding: 48px;
  background-color: mat-color($app-accent, 50);
  width: 100%;
}

.errorMessageContainer {
  padding: 48px;
  background-color: mat-color($app-warn, 50);
  width: 100%;
}

This lets you use your Material Design palette in your custom components. In this case, we’re using the lightest accent color (50) as the background of the container which provides a message about the empty search result set. We’re also using the lightest accent color of the warn palette as the background color of our error panel.

These are just two very simple examples of the powerful capabilities of using SCSS along with the Angular Material Theming system. Find our more in their guide to theming your own components.

Summary

• Be careful of how you set up SCSS in your Angular Material and Angular CLI project. It can lead to bloat and styling complications.

• Follow the architecture above to eliminate duplicate styles if you have them

• Brush up on the basics of SASS and the capabilities of the Angular Material Theming system

• Keep leveraging these great tools to build amazing high performance web applications with solid UX!

I hope that you find this helpful. If you would like to see more Angular Material content, please let me know.

There will be some great presentations next week (Oct 10–12th) at AngularMix in Orlando, FL USA. I’ll be presenting “Delight your Organization with Material Design” on 10/12. There will be many other talks including Angular’s new Component Dev Kit (CDK), which Angular Material leverages, and Angular CLI’s new DevKit and schematics.

Tickets are still available, and you can get \$100 off with the code MIXPRENTICE! They include an after party at the Wizarding World of Harry Potter in Universal Studios Orlando. I hope to see you there!

#Angular v4 upgrade in one Tweet. Only missing the updates to package.json versions. https://t.co/BlxP6VBu6B

Update app.module.ts:
import {BrowserAnimationsModule} from '@angular/platform-browser/animations';
imports: [BrowserAnimationsModule, ...]

— Michael Prentice (@Splaktar) March 24, 2017

For most projects not using Angular Universal, it’s just that easy to upgrade from Angular v2 to Angular v4!

The blog post announcing the release contains details on the new features, performance improvements, and the upgrade path.

To recap the major features

• Animations pulled out of core for performance, separation of concerns

• *ngIf supports and else syntax

• *ngFor supports an as syntax to assign local variables

• Angular Universal is now officially part of Angular core

• TypeScript 2.1+ support

• Improved template error messages

Angular CLI v1

Thankfully the Angular CLI update from 1.0.0 RCs to 1.0.0 final is also quite straightforward. The changelog for the updates is useful reading, but what you really need is their excellent migration guide!

Obviously if you are using the CLI, then the migration guide is where you should start. It will handle everything you need regarding upgrading both the CLI and Angular.

Troubleshooting

If you do run into issues with your upgrade, then this interactive Angular Upgrade Guide may help you. Note that this guide is just getting started and will improve over time.

If you see warnings about typing checking being required when linting via the CLI, just update your link command to the following:

"lint": "ng lint --type-check"

I also ran into issues with the CLI’s production builds due to template validation.

• One issue was regarding static variables in my components. Using these in templates results in an error that the property does not exist. I converted those variables to nonstatic as a temporary work around.

• The other was related to checking that a string variable in an object was defined inside of *ngFor. This threw a very confusing template error (with the wrong line number). I was able to work around this by moving the checks into the component and assigning the result to a boolean which was then used in the template.

Type 'string' is not assignable to type 'boolean'

I’m waiting for some feedback before opening bugs for these last two issues.

If you run into issues not found in these guides, please post a question to StackOverflow.

However, I decided that I want to update the DevIntent website from Angular 1.5.7 to the latest version of Angular over the Christmas break!

Since this is a marketing website, I need it to be super fast, especially on mobile, and have excellent SEO! I’m also using this as a testing ground for some work on an upcoming client project.

Current website status

Times listed for No throttling / Regular 3G.

• 36 requests

• 1.2 MB

• 459ms / 3760ms DOMContentLoaded

• 920ms / 13850ms Load

This is fairly typical of a smaller Angular 1.5.x application that is using a few libraries (Angular Material, Font Awesome, etc.) and is hosted on Firebase Hosting. It’s fine on desktop with broadband internet, but not good enough on a mobile 3G device.

Bust out the Angular-CLI

My first choice is generally the Angular-CLI because I believe in what they are doing to make Angular more approachable to new users. I use it as much as I can so that I can provide feedback, open bug reports, and even submit PRs.

The first step was to see if Universal and AOT was working yet in the CLI. I found that they were both working, just not together. The Angular-CLI does not support Angular Universal. It does support AOT, but there are around 63 open issues related to AOT.

There is a separate fork for a version of the CLI that supports Universal, but it doesn’t support AOT. It appears that they created this fork because the Angular-CLI team didn’t have the resources to support Universal.

Grab one of the hot seed projects

From the latest presentations that I’ve seen at conferences, I knew that there were a number of great Angular seeds out there.

The first one I looked at was angular-seed from Minko Gechev. It is really well-known, has 3,344+ stars, and supports AOT, Docker, etc. Unfortunately it doesn’t support Angular Universal or Webpack. After using Webpack with the Angular-CLI, I decided that I don’t want to use another bundler in my non-Angular-CLI projects.

I checked into Universal Starter from the Angular Universal team. It uses Webpack and has basic support for AOT. But it is really minimal and doesn’t include support for SASS/SCSS. I decided that I might come back to it.

Angular2-Webpack-Starter from AngularClass was another that caught my eye since it obviously supported Webpack, but it also had a lot of the other stuff ready to go. This included Router, HTTP, Forms, Hot Module Reload (HMR), Async/Lazy Routes, Material Design, and tests! It also has a great list of guides and tips like setting up SASS/SCSS. Unfortunately, it doesn’t yet support AOT compilation or Angular Universal.

Found a number of seeds w/ #AngularUniversal support, but they all seem to be broken (#ngMaterial2 / #AOT) or stuck on #Angular 2.1.

— Michael Prentice (@Splaktar) December 15, 2016

Finally picking a seed

I settled on giving Anthony’s (qdouble) fork of angular2-webpack-starter a shot. It combines all the great stuff from the original angular2-webpack-starter with support for AOT and Universal! One thing I quickly noticed was that the project is stuck on an older version (v2.1) of Angular (latest is v2.3).

After a lot of research, it became obvious that changes to Angular core in v2.2 and v2.3 broke Angular Universal. Apparently the Angular core team has realized that this is a problem.

But I just saw this https://t.co/eJtyJEVZrw which mentions that #Universal is moving to angular core. #ngMaterial2 is waiting on the move.

— Michael Prentice (@Splaktar) December 14, 2016

Because of this, they decided a couple weeks ago to move key pieces of Angular Universal into the Angular core. Unfortunately, a number of key people have been on vacation since this decision was made. So we’re stuck in this state where using Angular Universal means staying on Angular v2.1.

This also means that support for Angular Universal in a new version of Angular will have to wait for at least v4 which just entered beta.0.

Angular 4.0.0-beta.0 is out. You're wondering why it's Angular 4? Read about the reasoning behind here: https://t.co/9AhXTMnlXc #angular

— Juri Strumpflohner (@juristr) December 15, 2016

Measuring the benefits

The main purpose of the chosen seed/starter is performance (i.e. Angular Universal, Webpack 2, and AOT compilation). I checked the README for some stats for nerds (i.e. perf goodies) but sadly found none. Thus, I set to gathering some performance stats on the current build of the starter.

• Times listed for No throttling / Regular 3G.

Dev Mode

npm start

• 29 requests
• 5.8 MB
• 1300ms / 66000ms DOMContentLoaded
• 1350ms / 66000ms load

Universal

npm run universal

• 16 requests
• 363 KB
• 928ms / 4480ms DOMContentLoaded
• 973ms / 5020ms load

AOT mode

npm run compile + npm run prodserver

• 16 requests
• 301 KB
• 432ms / 3530ms DOMContentLoaded
• 495ms / 3930ms load

Universal + AOT

npm run universal:aot or npm run compile:universal+ npm run prodserver

• 16 requests
• 392 KB
• 494ms / 4410ms DOMContentLoaded
• 535ms / 5030ms load

Tests Ran on

• Chrome 57.0.2951.0 canary (64-bit)

• Cache disabled

• MacBook Pro (Retina, 15-inch, Mid 2014)

• 2.8 GHz Intel Core i7

• 16 GB 1600 MHz DDR3

• OS X El Capitán 10.11.6 (15G1212)

• NodeJS 6.7.0

Analysis

Now I know that Universal and AOT are still undergoing a lot of breaking changes and needed improvements, but I found it a little odd that the combination (Universal + AOT) was slower than the build with AOT alone.

Since the angular-cli isn’t supporting Universal + AOT yet, I was looking to find a solid seed for Universal, AOT, Webpack 2, Material 2, SCSS, etc. and this one seems to be the closest that I can find which isn’t significantly broken.

With the numbers above, I was wondering if I should even bother with Universal at this point. Then I thought, well Universal should help get that initial paint a lot faster. But on any network with 3G+, the time between initial paint and interactivity is under 50ms and isn’t even noticeable. If I drop down to Regular 2G, then I do see the initial DOM loaded for about 2s before JavaScript takes control and the page is re-rendered and fully ready for interaction.

Perhaps part of this issue is that the app doesn’t have an appShell (it’s just a white “Loading…” page), but either way I’m not sure I should go to the extra trouble of running a NodeJS server for Universal at this point. I could just host a client-only app in Firebase Hosting using their Edge CDN w/ AOT and maybe that would be even faster than the numbers above.

SEO is something that I really need, but I’m not convinced that Universal will work properly here and deliver the desired results. There’s some possible hacks discussed in the universal-starter project where the meta tags can be manipulated. However, Angular’s new Meta Service just landed in Angular v4-beta.0 thanks to Dzmitry Shylovich! Unfortunately Universal isn’t compatible with the latest versions of Angular yet.

TL;DR

It appears that I should just stick with AOT compilation and wait until Universal gets better support from the Angular core team (in progress, no ETA).

Thankfully the chosen starter makes that a well-supported option in addition to supporting these configurations used in the benchmarks above. This is what enabled the ability to gather these numbers using different approaches, while keeping the code-base exactly the same. Thanks to Anthony for the hard work on this starter and for sharing what’s been working for him on his projects!

It’s clear the Angular 2 Release Candidates were actually Alphas and what we’re using now in 2.1.1 is Beta. You could say that the Angular Core is in Release Candidate state currently, but the ecosystem of semi-mandatory modules that make up the platform are mostly in some form of Alpha or Beta.

Let’s get started

If you update your version of the CLI first from beta.10 to beta.19, you may see this error message:

Note that there is an updated guide here: https://github.com/angular/angular-cli/wiki/Upgrading-from-Beta.10-to-Beta.14

I also submitted a PR to improve the grammar of this upgrade warning message.

The first step of this helpful guide is to make sure that you are up to Angular RC6 or greater. So you would then find that you need to upgrade from Angular RC4 to the latest which includes the major breaking change of ngModules announced in this blog post. This blog post announcing Angular RC5 includes a really helpful link to a migration guide. Unfortunately, that migration guide (https://angular.io/docs/ts/latest/cookbook/rc4-to-rc5.html) is a 404 on the Angular.io docs site.

Now the task is to find a migration guide that works for RC4 to final

There was a Reddit discussing this lost migration guide, but it doesn’t point to a new location.

There is StackOverflow question that poses this exact question, but it’s first suggested solution appears to be the most time intensive option… review the changelogs for RC5, RC6, RC7, and final for breaking changes and then make adjustments to your project. The second option here is one that I have been considering, generate a new project with the latest angular-cli beta.19 and then pull that configuration into your existing project.

After quite a bit of looking, I didn’t really find something that I was happy with. A few guides hit about 25% of what I needed, but I couldn’t find anything that was much more complete.

Get up to speed with the concepts first

I highly suggest reading the following before starting:

The first is the Angular team blog post that covers the reasons why ngModule exists and how it helps you.

Then the official docs on ngModule cover some key patterns like having a Core Module and Shared Module. It also covers lazy loading modules.

Start with a single ngModule

This step involves just creating a single module and adding everything to it. This makes sense for small to medium-sized projects. If your project is already large, you’ll want to move on to the next step.

Basically this step just involves using the docs links above to create your AppModule and plumb everything together.

Away with the boilerplate!

After you’ve got an ngModule, you’ll need a lot less boilerplate. Unfortunately, you (or angular-cli) already wrote it, so you’ll have to go and remove it now. This includes changing all of your components by removing their directives, providers, pipes, and lots and lots of imports that aren’t needed anymore.

Create a Shared Module

Use the docs on creating a Shared Module and move your application-wide services and common Angular modules (FormsModule, RouterModule, etc.) into this new SharedModule.

Evaluate your project for modularity

Now you’ll want to think about your project and find out if it makes sense to break up specific routes into lazily loaded modules. Ideally, your module that is bootstrapped at the root of your app should be as lean as possible. Once you’ve identified these modules, it’s time to create them and start setting up the lazy loading in the router.

Migrate Angular-CLI

OK, now you’ve setup ngModules and updated your package.json to use @angular/xxx: 2.1.2, you are ready to proceed with the angular-cli migration guide. Carefully follow the guide, and you will be about 90% of the way there.

Many people noticed that their favicon and 404 pages weren’t showing up in dist/ after upgrading. The community filed numerous bugs, but in beta.19 this was fixed. Make the changes below to take advantage of this new feature that allows specifying an array of assets.

angular-cli.json (old)

"assets": "assets",

angular-cli.json (new)

"assets": [
  "assets",
  "elements.html",
  "404.html",
  "favicon.ico",
  "manifest.webapp",
  "icons"
],

Obviously the contents of this array will be specific to your application.

Migrate Angular Material2

Their getting started guide provides the minimal level of help required to get this working. This has changed quite a bit from what was found in the RC5 blog post. There is now a single MaterialModule that you need to load.

src/app/app.module.ts

import { MaterialModule } from '@angular/material';

@NgModule({
  imports: [MaterialModule.forRoot()],

If you are using any of their sliders, you’ll need to import hammer.js with the new angular-cli process.

angular-cli.json

{
  "scripts": ["../node_modules/hammerjs/hammer.js"]
}

Additionally, material2 now has a theming system which you will need to configure for the styling of your UI components to look good (i.e. not be mostly grey). See their theming guide here to set this up.

Migrate Firebase

If you are using the Firebase SDK (required for many features like Firebase Storage that aren’t yet supported in AngularFire2) then the way that you load that library has changed in the angular-cli.

Make sure you don’t also include the @types/firebase definitions in your package.json.

angular-cli.json

{
  "scripts": ["../node_modules/firebase/firebase.js"]
}

Upgrade AngularFire2

Their docs are quite helpful, but they only covered about 95% of what I needed to do. That last 5% was pretty painful as what I got working in angular-cli beta.17 needed more tweaking with beta.19.

For just using AngularFire2 without Firebase Auth, you can do this:

src/app/app.module.ts

import { AngularFireModule } from 'angularfire2';

const firebaseConfig = {
  apiKey: '<your-key>',
  authDomain: '<your-project-authdomain>',
  databaseURL: '<your-database-URL>',
  storageBucket: '<your-storage-bucket>'
};

@NgModule({
  imports: [
    BrowserModule,
    AngularFireModule.initializeApp(firebaseConfig)
  ],

If you’re using Firebase Auth, you’ll need a bit more. They cover this in their Auth docs.

I submitted a PR to help make these docs a little more straightforward.

src/app/app.module.ts

import { AngularFireModule, AuthProviders, AuthMethods } from 'angularfire2';

const myFirebaseConfig = {
  apiKey: '<your-key>',
  authDomain: '<your-project-authdomain>',
  databaseURL: '<your-database-URL>',
  storageBucket: '<your-storage-bucket>',
}

const myFirebaseAuthConfig = {
  provider: AuthProviders.Google,
  method: AuthMethods.Redirect
}

@NgModule({
  imports: [
    BrowserModule,
    AngularFireModule.initializeApp(myFirebaseConfig, myFirebaseAuthConfig)
  ],

**Troubleshooting **I needed to do a bit more here to deal with some TypeScript issues. Their existing docs here seemed to be designed for an older version of the angular-cli. I needed to remove @types/firebase from my package.json and use the typedefs from the Firebase SDK.

src/tsconfig.json

"files": [
  "../node_modules/firebase/firebase.d.ts"
]

If you are on the new AngularFire2 beta.6, this step is not needed since these typedefs are included in AngularFire2. Adding them again here will cause many duplicate type errors.

Upgrade Angular2-Google-Maps

The docs here are quite comprehensive and once I followed them, everything seemed to just work. The main change is related to ngModule.

They also fixed some pesky bugs in the latest v0.15.0 release.

src/app/app.module.ts

import { AgmCoreModule } from 'angular2-google-maps/core';

@NgModule({
  imports: [
    BrowserModule,
    AgmCoreModule.forRoot({
      apiKey: 'YOUR_KEY'
    })
  ],

Upgrade Angular2-Polymer

The Vaadin team has done a lot of the tough work to streamline this process. Their documentation can be found here.

As part of this process, I sent them a PR to correct their README’s link to these docs.

One of the key changes here is the way that bootstrapping the Web Components polyfill is accomplished due to changes to the angular-cli. This includes creating a main-polymer.ts file which kicks off the bootstrapping of your Angular application after the WebComponentsReady event is fired.

src/main-polymer.ts

document.addEventListener('WebComponentsReady', () => {
  // Load Angular app
  require('./main.ts');
});

Then you need to update angular-cli’s config to use this new main-polymer.ts as your app’s entry point.

angular-cli.json

"main": "main-polymer.ts",

Another key change from the angular-cli is that loading the webcomponents-lite.min.js file is now easier. I also decided to get it from NPM instead of Bower.

angular-cli.json

{
  "scripts": ["../node_modules/webcomponents.js/webcomponents-lite.js"]
}

Fix issues with Basic Web Components

I found that the key here was to require the Basic Web Component scripts in the main-polymer.ts file defined as part of the Angular2-Polymer configuration above. These web components don’t have type definitions for TypeScript and importing their ES6 modules was a nightmare.

src/main-polymer.ts

document.addEventListener('WebComponentsReady', () => {
  // Load basic web components
  require('../node_modules/basic-arrow-selection');
  require('../node_modules/basic-carousel');
  require('../node_modules/basic-page-dots');

  // Load Angular app
  require('./main.ts');
});

This worked somewhat, but still resulted in errors since the angular-cli doesn’t have an ES6 loader configured (separate from the TypeScript loader) and they don’t allow for customization of the Webpack configuration. This ES6 still ran OK on the latest Firefox, Chrome, and Safari, but it failed on IE11.

Due to this, I ended up removing Basic Web Components from my project and using ngBootstrap’s Carousel instead.

myApp.config([
  '$compileProvider',
  '$logProvider',
  function ($compileProvider, $logProvider) {
    $compileProvider.debugInfoEnabled(false);
    $logProvider.debugEnabled(false);
  },
]);

Note that this is in addition to whatever else your app needs to do in its .config() function. For this to be fully effective, you should use Angular’s $log service instead of console.log() throughout your app.

As Ben Nadel noted, if your app is doing element.scope() anywhere, it will no longer work after $compileProvider.debugInfoEnabled(false) is called.

RC 5 brings with it the significant new ngModule feature along with updates to forms, the router (Lazy Loading), material design, and more!

This is the first RC of the new router. You can find out more about the router in Victor Savkin’s new e-book.

The associated Angular team blog post is located here: http://angularjs.blogspot.com/2016/08/angular-2-rc5-ngmodules-lazy-loading.html

The migration guide used to be found in the Angular 2 docs here but it has been removed. If you need help with upgrading from the RCs, please see my blog post on this topic.

The more detailed Changelog can be reviewed here: https://github.com/angular/angular/blob/master/CHANGELOG.md#200-rc5-2016-08-09

You may have worked around this problem (I know I've spoken to and see many people doing this) by changing your styles to target the new "private" styles (i.e. the _md-visually-hidden class on md-tabs' md-tabs-dummy-wrapper) introduced in 1.1.0 RC.

I cautioned a number of people against this, pointing out that these are meant to be private styles which will see unannounced breaking changes.

Unfortunately, it turns out that these changes were far too disruptive and in some cases there was no work around outside of using the private styles. So these private style changes have all been reverted in master via this commit. These changes will be in the next 1.1.0-RC.6 build.

If you have already updated your entire application to rely on these private styles, then unfortunately, you will need to revert those changes as well in order to move to the final 1.1.0 release.

Note that this does not remove all private styles. There remain some styles, that existed prior to 1.1.0-RC1, that are still preceded with an underscore ("_"). These styles remain private and should not be used as breaking changes to them will not be announced.

The Good News

If your project is on the latest stable release (1.0.9), then your upgrade path to 1.1.0 should now be a bit smoother when 1.1.0 final lands.

Additionally, if you are trying out Angular Material, you should note that they are planning to include similarly denoted private styles.

Please read this post for additional details and to ask questions.

Google defines Responsive UI as:

Responsive layouts in material design adapt to any possible screen size. This UI guidance includes a flexible grid that ensures consistency across layouts, breakpoint details about how content reflows on different screens, and a description of how an app can scale from small to extra-large screens.

Similar to Responsive Design, the system uses breakpoints which match up with the screen width of various devices.

The Material Design site has some great examples of the UI grid. They include animated images to demonstrate how the grid reacts to changes in screen width.

For me, the most interesting and powerful part of Responsive UI with Material Design are the UI Patterns. They demonstrate how to apply the breakpoints, grid, and surface behaviors to real-world UI design challenges.

These patterns include

• Reveal
• Transform
• Reflow
• Expand
• Position

I've taken some time to update my slides from November to fix some of the broken links and add links to previously unavailable tools. One of these tools, the exciting "Resizer", was previewed at the Polymer Summit in 2015.

Video here:

Since then it has finally been made available for use. Please do check it out!

For more in depth details, discussion, and links, please check out the slides from this presentation.