Forem: Mark Thompson

Why Your Angular Bundle Is Bloated

Mark Thompson — Wed, 29 Jun 2022 22:06:33 +0000

A common reason why an Angular bundle is bloated is that it uses a library like MomentJS that isn't tree-shakable.

This blog post will go over how to analyze your Angular bundle and pinpoint libraries that are bloating your application.

Why You Should Analyze Your Angular Bundle

It's important to keep an eye on your project dependencies and call out the ones that are bloating your application. MomentJS used to be a staple in my projects until I realized how huge it was.

The following section will walk through how I came to the conclusion to avoid MomentJS using this demo application where I display tomorrow's date.

How to Analyze Your Angular Bundle

A quick way to analyze your Angular bundle is to use ngx-builders/analyze, a custom Angular CLI builder which allows you to run source-map-explorer with Angular. This will show you how your application is bundled and which dependencies are bloating your application.

Install ngx-builders/analyze
```
ng add @ngx-builders/analyze
```
Install source-map-explorer
```
npm i -D source-map-explorer
```

Update package.json to have an analyze npm script:

{
"name": "[YOUR_PROJECT_NAME]",// Likely will be your project name, but doesn't have to be
"scripts": {
    "ng": "ng",
    // ...
    "analyze": "ng run [YOUR_PROJECT_NAME]:analyze",// You can find your project name in angular.json under the projects property
},
}

Run analyze npm script
```
npm run analyze
```

You should see your application build and your browser should open the results provided by source-map-explorer.

Why Replace MomentJS

This demo has been implemented 3 ways:

Using Native Date API
Using MomentJS
Using date-fns

Tests

Each of these solutions use the same tests to verify implementation achieves the expected behavior:

Comparing the Results

Analyzing how each solution affects the overall bundle for my demo shows:

Implementation	Total Size
Native Date API	202 KB
MomentJS	575.18 KB
date-fns	222.65 KB

Using Native Date API negatively impacts my bundle size the least. Total size is 202 KB.

This makes sense since by avoiding any extra libraries, there's no risk of bloating my bundle size. Only downside is that implementation took much longer than using an existing library.

Using MomentJS impacts my bundle size the most. Total size is 575.18 KB. Using MomentJS bloats my application significantly resulting in being 64.8% of my total bundle size. This is because MomentJS is not tree-shakable and results in importing the entire library regardless of how little it is used.

Using date-fns increases my bundle size by 20.79 KB. Total size is 222.65 KB resulting in being 9.3% of my total bundle size. This is a huge improvement over importing MomentJS. This is because date-fns is tree-shakable.

Conclusion

When considering adding a library to an Angular application, tools such as ngx-builders and source-map-explorer can verify that the library won't bloat that application's bundle size.

Depending on how much time I want to spend implementing all my features from scratch, I might avoid using any library. But if I want to spend less time reinventing the wheel, I'll reach for a well-known libraries such as date-fns that are tree-shakable. One thing is certain, I'll avoid libraries like MomentJS since they result in an unnecessary increase in bundle size.

Long story short, please consider the alternatives to MomentJS.

Want to read more blog posts by Bitovi? Check out more posts at our blogs at Bitovi.com

Need help analyzing your Angular application? Bitovi is here to help! Contact us today!

RFC: Strictly Typed Reactive Forms Gotchas Every Angular Developer Needs to Know

Mark Thompson — Thu, 19 May 2022 19:41:23 +0000

Angular is a robust framework suitable for large codebases and enterprise applications. One significant contributing factor is Angular’s support for TypeScript. Angular is built entirely in TypeScript, and because TypeScript is Angular’s primary language, Angular’s documentation treats TypeScript as a first-class citizen.

With RFC: Strictly Typed Reactive Forms complete, many expect to have strictly typed reactive forms in the upcoming Angular 14 update. After playing around with the Strictly Typed Reactive Forms prototype, I am super excited about this upcoming feature. Not only are we getting strict types for reactive forms, but we are also getting a minor feature: the initialValueIsDefault option for FormControlOptions which will allow for resetting form values back to their initial value rather than null by default:

Strictly Typed Reactive Forms Gotchas

Strictly typed Reactive Forms should be enough of a selling point to migrate to Angular 14, but it doesn’t come without flaws:

Reactive Forms have tricky types involving null and undefined.
FormArray generic doesn’t support Tuples.
FormBuilder syntactic sugar doesn’t infer proper generic types.
Template-driven Forms and Control Bindings mismatch underlying control type and bound FormControl type.

We will go over each one of these gotchas and provide explanations so you can spend less time debugging and have more time building complex forms.

Reactive Forms Have Tricky Types Involving null and undefined

Reactive Forms having tricky types isn’t specific to the Strictly Typed Reactive Forms update, but if you’re not aware of how null and undefined play a role in Reactive Forms, you’re likely to run into type errors.

null is a common type when considering that FormControl value can be null whenever .reset() is called. This is documented and explained in RFC: Strictly Typed Reactive Forms under Nullable Controls and Reset. initialValueIsDefault option for FormControloptions can be used to avoid this situation by passing true. This will make the FormControl value non-nullable:

Any disabled control’s value can be excluded from its FormGroup or FormArray value. In these situations, it’s easy to stumble upon undefined when expecting some nested control value. This is documented and explained in RFC: Strictly Typed Reactive Forms under Disabled Controls.

And because FormGroup provides .removeControl() and .addControl(), you will have to explicitly mark that control’s key in the FormGroup as optional. This is documented and explained in RFC: Strictly Typed Reactive Forms under Adding and Removing Controls.

FormArray generic doesn’t support Tuples

Currently, FormArrays are homogeneous - every control in a FormArray is of the same type. Attempting to use a Tuple of FormControls for its generic type will result in a type error:

Luckily the Strictly Typed Reactive Forms update anticipates that most projects will not be 100% compatible with the update and provide a backward-compatible workaround. You can opt-out of strictly typed Reactive Forms by providing the explicit any generic to the FormArray. Or, in this specific situation, you can union the expected generic types for each FormControl:

For now, we’ll have to settle for FormArrays with a single-typed FormControl array as its generic. Support for Tuple-typed FormArrays will likely become added in a follow-up update.

FormBuilder Syntactic Sugar Doesn’t Infer Proper Generic Types

FormBuilder provides syntactic sugar that shortens creating instances of FormControl, FormGroup, or FormArray. Typically this reduces the amount of boilerplate needed to build complex forms. Still, since FormBuilder can’t infer the generic types like how FormGroup or FormArray constructor does, you end up with type errors complaining that AbstractControl isn’t assignable to type FormControl:

Template-driven Forms and Control Bindings

Angular's template type checking engine will not be able to assert that the value produced by the underlying control (described by its ControlValueAccessor) is of the same type as the FormControl. This is documented and explained in RFC: Strictly Typed Reactive Forms under Control Bindings.

The above restriction also applies to NgModel and template-driven forms. This is documented and explained in RFC: Strictly Typed Reactive Forms under Template-driven Forms.

You won’t get a type error when binding a FormControl with a string value to a DOM element that has a numeric value.

This is a limitation introduced by the current template type-checking mechanism where a FormControlDirective which binds to a control does not have access to the type of the ControlValueAccessor.

Conclusion

The RFC: Strictly Typed Reactive Forms may not be perfect, but it’s a feature that has been asked for since 2016 and is highly anticipated by many seasoned Angular developers. Strict types for Reactive Forms in Angular will help developers write better code and help significantly with debugging. It will ensure better code quality, but it will provide an easier comprehension of how the Reactive Forms API works in general.

Please try out the Strictly Typed Reactive Forms prototype, fork the demo repo, and share your thoughts.

I've done a presentation on this topic if you want to check it out

Want to read more blog posts by Bitovi? Check out more posts at our blogs at Bitovi.com

Why Good Interviewers Still Use FizzBuzz

Mark Thompson — Sun, 09 Jan 2022 21:25:54 +0000

Why Interviewers Use the FizzBuzz Problem

FizzBuzz is a well-known, simple coding assignment that is commonly used as an entry, technical whiteboard exercise in interviews.

Since the problem is "simple", the focus isn't on whether or not someone can solve it, but how one goes about solving problems and gives that developer a chance to showcase their process on writing maintainable code as a member of a team.

Bad interviewers only care whether or not the interviewee can actually solve the problem. Good interviewers are looking out for strong coding habits:

Writing self-documenting/commented code
Naturally writing/refactoring code to be DRY
Deliver code that can be easily maintained

Let's go over some solutions for the FizzBuzz problem and highlight bad patterns to avoid in an interview.

We'll also highlight good alternatives that demonstrate an understanding on how to write maintainable code.

The FizzBuzz Problem

There are many variations of this problem, we'll be using:

[interactive demo]

Write a function that accepts one argument: Array of possible whole numbers.

The return of the function should map each value of the Array to some string given these cases:

1. If the number is divisible by 3, map to "Fizz"
2. If the number is divisible by 5, map to "Buzz"
3. If the number is divisible by 3 and 5, map to "Fizzbuzz" instead
4. If the number is NOT divisible by 3 or 5, map number to itself

I've always hated how the instructions for displaying "Fizzbuzz" came somewhere in the middle or the end when in most cases displaying "Fizzbuzz" handled first. I would suggest clarifying that order matters and request that the requirements reflect it:

1. If the number is divisible by 3 and 5...
2. If the number is divisible by 3...
3. If the number is divisible by 5...
4. Else...

I believe exercises start with badly ordered requirements on purpose to simulate the real world: you're likely to get badly ordered requirements. In this situation, it's important for developers to be proactive.

Solutions to the FizzBuzz Problem

Here is a clever solution to the problem: [01]

/**
 * Map an Array of numeric values to Fizzbuzz values
 * @param values Array of numeric values
 * @returns Fizzbuzz values
 */
export const getFizzbuzzValues = (values: number[]): string[] => {
  let results = [];

  for (let i = 0; i < values.length; i++) {
    results.push(
      (!(values[i] % 3) && ((!(values[i] % 5) && 'Fizzbuzz') || 'Fizz')) || (!(values[i] % 5) && 'Buzz') || `${values[i]}`
    );
  }

  return results;
};

If this was an open PR, I'd suggest a refactor that made the code changes more clear on what's going on. One-liner solutions are all fun and games until someone reports a bug and I have to cypher all this madness.

Here's a quick refactor to break down the one-liner solution: [02]

  /**
   * Map an Array of numeric values to Fizzbuzz values
   * @param values Array of numeric values
   * @returns Fizzbuzz values
   */
  export const getFizzbuzzValues = (values: number[]): string[] => {
    let results = [];

    for (let i = 0; i < values.length; i++) {
      if (!(values[i] % 3)) {
        if (!(values[i] % 5)) {
          results.push('Fizzbuzz');
        } else {
          results.push('Fizz');
        }
      } else {
        if (!(values[i] % 5)) {
          results.push('Buzz');
        } else {
          results.push(`${values[i]}`);
        }
      }
    }

    return results;
};

I'm happier with this solution since it is more readable. I value readability over optimization every time since when trying to achieve both, it's always easier to refactor readable code. To further improve the readability of the code, I'd then suggest avoiding nested if statements: [03]

  /**
   * Map an Array of numeric values to Fizzbuzz values
   * @param values Array of numeric values
   * @returns Fizzbuzz values
   */
  export const getFizzbuzzValues = (values: number[]): string[] => {
    let results = [];

    for (let i = 0; i < values.length; i++) {
      if (!(values[i] % 3) && !(values[i] % 5)) {
        results.push('Fizzbuzz');
        continue;
      }

      if (!(values[i] % 3)) {
        results.push('Fizz');
        continue;
      }

      if (!(values[i] % 5)) {
        results.push('Buzz');
        continue;
      }

      results.push(`${values[i]}`);
    }

    return results;
};

Now I'm happy, but it could be better. One big problem is that this code is imperative. Since we know that there is a direct mapping of values of the Array. Why not use Array.map? [04]

 /**
   * Map an Array of numeric values to Fizzbuzz values
   * @param values Array of numeric values
   * @returns Fizzbuzz values
   */
  export const getFizzbuzzValues = (values: number[]): string[] => {
    return values.map(value => {
      if (!(value % 3) && !(value % 5)) {
        return 'Fizzbuzz';
      }

      if (!(value % 3)) {
        return 'Fizz';
      }

      if (!(value % 5)) {
        return 'Buzz';
      }

      return `${value}`;
    });
};

Now I'm very happy: code is declarative. Any seasoned developer should understand what this code is doing at a glance.

But if we wanted to consider some optimizations, !(value % 3) is done twice. And there could be minor confusion on how the remainder operator works to determine if something is divisible by another number: [05]

/**
 * Checks if a number (dividend) is divisible by another number (divsor)
 * @param dividend - number being checked if divisible
 * @param divisor {number} - what is used to determine if number is divisible by
 * @returns number is divisible
 */
export const isDivisible = (dividend: number, divisor: number): boolean => {
  // modulo operation will return 0 if there's no remainders => divisible
  return !(dividend % divisor);
};

/**
 * Map an Array of numeric values to Fizzbuzz values
 * @param values Array of numeric values
 * @returns Fizzbuzz values
 */
export const getFizzbuzzValues = (values: number[]): string[] => {
  return values.map((value) => {
    const divisibleByThree = isDivisible(value, 3);
    const divisibleByFive = isDivisible(value, 5);

    if (divisibleByThree && divisibleByFive) {
      return 'Fizzbuzz';
    }

    if (divisibleByThree) {
      return 'Fizz';
    }

    if (divisibleByFive) {
      return 'Buzz';
    }

    return `${value}`;
  });
};

Now I'm pretty happy. There should be a very clear understanding on what each part does. Now there's enough information for even those who don't know how the remainder operator works.

Only thing I'd suggest is that we migrate the logic for getting a "Fizzbuzz value" to its own function since determining a "Fizzbuzz value" isn't dependent on the Array of values as a whole, but instead depends on each specific value.

Also, how do we explain that the order of the if statements matter: write some comments! [06]

/** fizz-buzz.ts */

/**
 * Checks if a number (dividend) is divisible by another number (divsor)
 * @param dividend - number being checked if divisible by some other number (divsor)
 * @param divisor {number} - what is used to determine if a number (dividend) is divisible
 * @returns number (dividend) is divisible
 */
export const isDivisible = (dividend: number, divisor: number): boolean => {
    return !(dividend % divisor);
}

/**
 * Get a Fizzbuzz value based on a numeric value
 * @param value Numeric value
 * @returns Fizzbuzz value
 */
export const getFizzbuzzValue = (value: number): string => {
    const divisibleByThree = isDivisible(value, 3);
    const divisibleByFive = isDivisible(value, 5);

    // Check if value is divisible by 3 and 5 first
    if (divisibleByThree && divisibleByFive) {
        return 'Fizzbuzz';
    }

    // It is important to check if number is divisible 3 after checking if divisible by 3 and 5
    if (divisibleByThree) {
        return 'Fizz';
    }

    // It is important to check if number is divisible 5 after checking if divisible by 3 and 5
    if (divisibleByFive) {
        return 'Buzz';
    }

    // Default case: return numeric value as a string
    return `${value}`;
};

/**
 * Map an Array of numeric values to Fizzbuzz values
 * @param values Array of numeric values
 * @returns Fizzbuzz values
 */
export const getFizzbuzzValues = (values: number[]): string[] => {
    return values.map(value => getFizzbuzzValue(value));
};

And how do I ensure that the implementation actually works: write some tests! [07]

/** fizz-buzz.spec.ts */

import * as lib from './fizz-buzz';

describe('fizz-bizz', () => {
  describe('isDivisible()', () => {
    it('should return false if NOT divisible by', () => {
      expect(lib.isDivisible(1, 3)).toBe(false);
      expect(lib.isDivisible(2, 3)).toBe(false);
    });

    it('should return true if divisible by', () => {
      expect(lib.isDivisible(3, 3)).toBe(true);
    });
  });

  describe('getFizzbuzzValue()', () => {
    it('should return Fizzbuzz if divisible by 3 and 5', () => {
      expect(lib.getFizzbuzzValue(30)).toBe('Fizzbuzz');
    });

    it('should return Fizz if divisible by 3 and NOT 5', () => {
      expect(lib.getFizzbuzzValue(27)).toBe('Fizz');
    });

    it('should return Fizz if divisible by 5 and NOT 3', () => {
      expect(lib.getFizzbuzzValue(35)).toBe('Buzz');
    });

    it('should return input number if NOT divisible by 5 or 3', () => {
      expect(lib.getFizzbuzzValue(4)).toBe('4');
    });
  });

  describe('getFizzbuzzValues()', () => {
    beforeEach(() => {
      jest.restoreAllMocks();
    });

    it('should use getFizzbuzzValue to create its return value', () => {
      const spy = jest
        .spyOn(lib, 'getFizzbuzzValue')
        .mockImplementation((value: number) => { return `${value}_mock`});

      expect(lib.getFizzbuzzValues([9, 35, 30, 101])).toStrictEqual([
        '9_mock',
        '35_mock',
        '30_mock',
        '101_mock',
      ]);

      expect(spy).toHaveBeenNthCalledWith(1, 9);
      expect(spy).toHaveBeenNthCalledWith(2, 35);
      expect(spy).toHaveBeenNthCalledWith(3, 30);
      expect(spy).toHaveBeenNthCalledWith(4, 101);
    });

    it('should map values of the input array to Fizzbuzz values', () => {
      expect(lib.getFizzbuzzValues([9, 35, 30, 101])).toStrictEqual([
        'Fizz',
        'Buzz',
        'Fizzbuzz',
        '101',
      ]);
    });
  });
});

Awesome, now I'm super happy:

We have comments to show that the order matters.
Our code is fully tested to help ensure it doesn't break.
Code is very readable and declarative.

Maybe there's even more improvements you'd suggest. Or maybe you'd prefer different test cases or patterns to be used. Please leave a comment to share your thoughts!

Conclusion

Good interviewers don't only care whether or not the developer can find a solution to a problem.

They want to know if a developer can ask the right questions to clarify requirements and to convey they understand the problem. They care about hiring developers that can deliver maintainable code.

In an interview setting where time is a critical factor. We might not have enough time to go over everything we've discussed in this post:

Avoiding complex one-liner solutions
Avoiding nested if statements to make code more readable
When to use comments
Moving duplicate code into separate functions
Writing declarative code over imperative code
Writing tests to ensure code is working as expected

That's okay! Discussion is an important part of technical interviews. Use discussion to save time and demonstrate an understanding of these concepts.

Wanna learn more about imperative vs declarative code? Check out this informative post.

FizzBuzz solution | interactive demo | demo repo

How to Support IE11 Users as You Move to Angular 13

Mark Thompson — Thu, 11 Nov 2021 16:54:00 +0000

IE 11 won't be supported in Angular 13. You can support it in 12 while you migrate to 13, or drop support. Either way, you need to act.

Internet Explorer 11 is a legacy browser and support for it in Angular 13 is being dropped officially. Sticking with Angular 12 is not a viable long term option. Here are ways to support your users when upgrading your Angular version.

Update tsconfig.json and populate polyfills
Use Differential Loading
How to Customize User Experience for IE 11
How to Drop Support for IE 11 the Good Way

As an Angular developer, you want to provide support for as many browsers as you can, but in the case of Internet Explorer 11, this is becoming increasingly difficult, and soon will no longer be possible. Current market share is likely less than 1% and will drop even more as Microsoft retires IE 11 in June 2022.

Even more challenging is that Angular 12 doesn't offer support for IE 11 by default, and Angular 13, coming out next week, is completely dropping support.

Choose a Support Path

There are two ways you can support IE 11 with Angular 12 as you prepare to migrate to Angular 13:

Update tsconfig.json to use ES5 and update polyfills.ts for ES6/ES7
Use Differential Loading

Or you could decide to drop support for IE 11. You should customize the user experience because if you don't, users will get a blank screen.

Update tsconfig.json and populate polyfills

By default, Angular compiles ES6 or ES7. IE 11 only supports ES5. You can update your tsconfig.json to target ES5. You'll also need to populate your Angular project polyfills.

Advantages of updating tsconfig.json and including polyfills:

Configuration prepares building and local development for IE 11 support
Faster builds than using Differential Loading

Disadvantages:

Imports a lot of polyfills and bloat bundle for legacy AND modern browsers
This approach has been abandoned as a standard after Angular 7

Definitions

You'll change the target variable in tsconfig.json, and populate the polyfills file that came with the Angular project. If you're not familiar with these things, here's what they are.

target: JavaScript language version for emitted JavaScript.

Angular polyfills are fallbacks for missing JavaScript behavior. There are two types:

Browser polyfills that are applied before loading ZoneJS.
Application imports that are files imported after ZoneJS that should be loaded before your main file.

Polyfills are applied in this order: Browser polyfills → Import ZoneJS → Application imports. You will only need to focus on browser polyfills.

The Steps

Open tsconfig.json and update target to es5.

Open polyfills.js found in the src directory and add import 'core-js'; under browser polyfills.

NOTE: When serving the application, the build was at 505.3 kB. After adding the import of core-js, it's 1.2 MB. 😬

Use Differential Loading

Differential Loading is the more modern technique introduced in Angular 8. The approach here is to make two builds. One uses ES5 syntax and a more modern one that uses ES6 syntax. The ES6 build won't include as many polyfills and going to be much smaller. The ES5 build will have polyfills and be more bloated.

Considerations

Advantages of using differential loading:

Smaller bundle sizes for modern browsers
ES5 bundle includes all required polyfills for legacy browser support automatically
Latest approach to supporting legacy browsers

Disadvantages:

Creates two bundles so longer build times
Extra configuration is required for local development for legacy browsers

The Steps

Find your browser's list file. Depending on the version of Angular, it will be .browserslistrc or browserslist.
Remove the word "not" from the IE 11 line.

Before I continue, I'll explain what just happened.

After you changed the browser's list file, when you look at your Angular project through Inspector, you'll see three additional scripts. Here's what it looked like before:

And after:

You will have two runtimes, two polyfills, and two mains. Modern browsers will only run the top script that is of type module. Legacy browsers like IE 11 will run the second one, the nomodule.

NOTE: The rest of these steps are only needed if you want to run the project locally in development mode if you only use differential loading.

Next up, you're going to create two new custom files in your application, a polyfills.es5.js in the src directory and tsconfig.es5.json at the root of your project.
Next steps are similar what you did for older tsconfig.json method above. Populate the polyfills file with your import. Then switch the tsconfig target to ES5 and to include your new polyfills file.

Now you're going to update angular.json.

Add a new build configuration. You can see on line 72 that I've added development-es5, where I copied all of the properties for development, and added two extra ones:

"tsConfig": "tsconfig.es5.json",

"polyfills": "src/polyfills.es5.ts"

To use this build when you serve locally, you need to add this new build configuration to the serve configurations.

As I did starting at line 94 above, use the same identifier, development-es5, and set browserTarget to "handling-ie:build:development-es5". Now you can serve your project for IE 11 using ng serve --configuration development-es5.

Why You Shouldn't Just Drop Support

You could drop support for IE 11. If you do, here's what an IE 11 user will see:

Not a good user experience. Instead, we can change a few things to let our visitor know that they need a different browser.

How to Customize User Experience for IE 11

You don't want IE 11 users to see a white page. Instead, you can warn them about their browser or tell them to do something. Instead, you can use the same approach as you did with Differential Loading. Set a flag and take advantage of that flag to write specific code for legacy browsers.

So you can call a no-es6.js script that will only run for legacy browsers by using the nomodule attribute.

In this script, I set a property, nomodule, to true on window. Throughout my application, I can check for that value and I can see whether or not you are using IE.

Note that nomodule is a custom property. That's not something that window has. Create a window.d.ts in the src directory and add that property to global.

How to Drop Support for IE 11 the Good Way

Finally, there will probably come a time when you offer no support for IE 11 and you've turned off differential loading or whatever you were using. How do you still provide a good user experience?

You can update your browser's list to say not IE, but your users will see a blank page.

Instead, you can update the no-es6.js script.

You can do all sorts of things here. In my example, I check for iIE. If I think you’re using IE, I’m going to try to use the microsoft-edge handler and open Edge to navigate the site. On IE, I’ll navigate you to a Microsoft support page that explains that IE is dropping support soon. If you're not using IE, I navigate you to a generic "hey, your browser is bad"page.

What Will You Do?

To sum it all up, there are two main ways to support IE 11. You can update your tsconfig.json, or you can use Differential Loading.

And you can provide a better user experience when you are dropping support and you can also provide a better user experience when you fully drop support. It's definitely time to decide what you'll do.

What do you think you'll do? Have these methods been helpful? Do you have other techniques for managing IE 11 and Angular 13? We'd love to know your thoughts. Drop us a note in the comments section below.

Forem: Mark Thompson

Why Your Angular Bundle Is Bloated

Why You Should Analyze Your Angular Bundle

How to Analyze Your Angular Bundle

Why Replace MomentJS

Tests

Comparing the Results

Conclusion

RFC: Strictly Typed Reactive Forms Gotchas Every Angular Developer Needs to Know

Strictly Typed Reactive Forms Gotchas

Reactive Forms Have Tricky Types Involving null and undefined

FormArray generic doesn’t support Tuples

FormBuilder Syntactic Sugar Doesn’t Infer Proper Generic Types

Template-driven Forms and Control Bindings

Conclusion

Why Good Interviewers Still Use FizzBuzz

Why Interviewers Use the FizzBuzz Problem

The FizzBuzz Problem

Solutions to the FizzBuzz Problem

Conclusion

How to Support IE11 Users as You Move to Angular 13

Table Of Contents

Choose a Support Path

Update tsconfig.json and populate polyfills

Definitions

The Steps

Use Differential Loading

Considerations

The Steps

Why You Shouldn't Just Drop Support

How to Customize User Experience for IE 11

How to Drop Support for IE 11 the Good Way

What Will You Do?

Resources