DEV Community: Christian Kohler

Angular Modules Best Practices 2021

Christian Kohler — Mon, 05 Jul 2021 00:00:00 +0000

Angular Modules are used to organize an application and consolidate components, directives, and pipes into blocks of functionality.

A good strategy can improve code organization, optimize the bundle size and make it easy to extend and refactor an application. A bad strategy can lead to dependency hell and larger bundles than necessary.

In this blog I will cover different strategies and give you tips on how to choose a strategy for your application.

TLDR;
Example Application
Aspects
Strategies
Summary

TLDR;

I use various aspects like bundle size, scalability, simplicity, and boilerplate to compare different module strategies.

The outcome is that there is not a single strategy for all types of applications but this post should help you in the decision-finding process for which strategy to choose.

Example Application

I will show you how I would organize an application. It is neither a simple counter nor a large enterprise app. So it might not fit your app size but I think it is a good structure to start a new app.

We take a music player as an example application. This should be a very familiar application to most of you. It has a global player reachable at the bottom and a few views to find and browse songs.

Folder Structure

Let’s forget about angular modules for a moment and let’s see how we can structure our application.

Folder structure and code organization are subjective and depend on the app you are working on. This is only an inspiration for how you could structure your app.

I use three main folders:

core
shared
views

Views contains the 3 views we can route to:

home-view
search-view
album-view

Core contains all the components which need to be available when the app starts. This includes the shell and the bottom menu. Also part of the core is the mini-player and the fullscreen player.

Shared contains all the components which are shared between the views. In our example we have two shared components:

horizontal-albums
main-title

View Specific Components is one folder (type) I didn’t mention at the beginning. Some components are reused in different views, some are only used in one view. Keeping code as close as possible to where it is used is a good practice. Therefore we place components that are only used in one view into that view folder. In this example that would be the search-bar which is only used in the search view.

Use Angular Modules

Angular Modules can now be used to combine those components into modules. There are many ways how to slice an app into Angular modules and there is no right or wrong way.

Aspects

There are a few aspects we should consider when deciding on one or the other approach.

Bundle size can be affected by how the modules are sliced. It can be the overall bundle size or also the individual lazy loaded bundles. This impacts the loading time of your app in a browser.

Scalability is about how easy it is to navigate and make changes in your code. Depending on how you slice your application, reorganization of code can be more difficult.

Simplicity is about how easy it is for someone in the team to understand when and where to create an Angular module.

Boilerplate How much boilerplate do we need for our Angular modules? The more modules the more boilerplate. This can usually be resolved by generating boilerplate with a CLI or an IDE.

Testabilty How easy is it to test a single component? If the component is part of a large module, we may have to mock many services.

Strategies

There are 3 strategies I want to have a closer look at today:

Everything in one module
One module per feature / view (Lazy Load)
One module per component (SCAM)

All strategies have their pros and cons. The radar chart compares the different approaches visually.

One module for all components is very simple. Whenever we create a component, we add it to the app.module declaration.

This approach is very simple but has a few downsides:

All components are eagerly loaded which results in a longer initial load time
The app.module file gets bloated and refactoring means touching this file all the time
Resolving dependencies is a nightmare. For example, it is very hard to figure out what we can remove after deleting a component. Maybe a component was only used in the deleted component and miss to remove that one as well.

This approach might work for very small applications but I wouldn’t recommend it for bigger projects.

One module per component (SCAM) is the exact opposite of the previous approach. In this strategy, we create a single module for every component. SCAM is an abbreviation for “Single Component Angular Module”. Lars Gyrup Brink Nielsen coined the term in this blog post.

What I like about this approach is that it is much easier to understand which dependencies a component has. Each component module only imports the modules it directly uses. That means if we remove a component we also remove all its dependencies automatically. Nice.

Another benefit of this approach is that Angular can build the optimal bundles for lazy loaded routes thanks to the clear dependency tree.

And last but not least, the rule is very simple: Every component has its module. That’s it, no discussions about how to slice the modules.

The only downside I see is that it adds some boilerplate since we have more module definitions and we have to import all dependencies explicitly. But that might change in the future with a new API on the @Component decorator which allows standalone components (without NgModules). For more on that, you can follow that spike on Github.

One module per feature / view (Lazy Load) is probably the most common pattern.

We get the optimal bundle size when we load all the view lazy. Since the shared module is used in multiple lazy loaded modules, it gets loaded in a separate common module. For more details on that, I wrote a blog post about how Angular bundles modules. Bundling Angular Modules.

This pattern is somewhere in the middle of the two other approaches. We get small bundle sizes with little boilerplate and we still have a clear structure.

If your application is larger you can also split the modules again into smaller feature modules or bundle views together into bigger feature bundles. This can either help you organize your code or lead to confusion on when to create those sub-modules. Angulars official documentation is a good read to learn more about this pattern.

How to decide what pattern to use?

The easiest decision is to rule out putting everything into one single module. If the application has routes and has more than 10 components, don’t go with that strategy.

To decide between the view/feature module and the single component module you have to ask yourself:

How much boilerplate are you willing to add for a clear dependency tree and a simple rule to follow?

Going with the classic feature/view module approach is still my go-to approach as long as the feature module imports and declarations are manageable.

If you build a library, the SCAM strategy is perfect since it allows the library consumer to only import the components they use. It is also good if you have difficulties defining a good strategy due to its simple rules.

Both SCAM and the classic feature/view module approach result in the same bundle structure. So both are very good from a performance perspective. However, this is only the case as long as we do not accidentally import a feature module in the app or core module, which does not happen with SCAM.

Summary

In this blog post, you learned different module strategies and various aspects like bundle size, scalability, simplicity, and boilerplate which helps you to decide on a strategy.

The three strategies I've shown here are the ones I mainly see and know. If you use another strategy, let me know, maybe I'll have to update the blog post soon with a new strategy 🙃

If you liked the article 🙌, spread the word and follow me on Twitter for more posts on web technologies.

Did you find typos 🤓? Please help improve the blogpost and open an issue here or post your feedback here

Angular Change Detection Infographic

Christian Kohler — Mon, 10 May 2021 00:00:00 +0000

Angular Change Detection Infographic

The Angular way of change detection is very powerful and makes it easy to start building Angular apps. It is basically magic since it doesn't require the developer to do trigger it manually, it just works. Unless it doesn't where it can be a daunting task to debug the change detection process.

This cheatsheet is for everyone who wants to know more about how change detection in Angular works.

👩‍🚀 Protip: 🖨 Print this cheatsheet as a poster and hang it in the toilet. Within a few weeks your work colleagues are Angular experts 😀

✅ Also feel free to use the cheatsheet for education purposes like workshops or in classes.

👆 It took me hours to complete this cheatsheet. If you like it follow me on twitter and spread the word 🙌

🤓 Did you find a mistake? Please help improve the infographic and open an issue here or give your feedback here

Download Angular DI Infographic as PDF

Bundling Angular Modules

Christian Kohler — Fri, 22 Jan 2021 00:00:00 +0000

Bundling Angular Modules

NgModules are controversial. They make it harder getting started with Angular. They might become optional in the future. But today they are here and it is helpful to understand how they work and how you can use them to write modular and performant applications.

With the recent updates, especially with Ivy, NgModules became less intrusive and easier to use. In this blogpost I want to give you an overview what you need to know about NgModules in the Ivy world.

Tldr;
Why do we need NgModules?
How to make a component available in a NgModule
How modules are bundled
Best practices
Summary

Tldr;

Today NgModules are mainly used to register components, directives and pipes
There are two types of NgModules: Eagerly loaded and lazy loaded modules
Eagerly loaded modules are always bundled in the main bundle
Lazy loaded modules have their own bundle file

Note

Most of the learnings in this blog post apply not only to components but to directives and pipes as well. I use components as a drop in replacement for components/directives/pipes to keep it simple.

Why do we need NgModules?

With Ivy, one of the main reasons we need NgModules is to register components, directives and pipes.

When Angular parses a template and sees a custom tag/element (e.g. <component-a></component-a>), the parser looks for a registered angular component which matches the selector.

Every framework has this challenge. React uses JSX, Vue solves it with a components property on the component:

var ComponentA = {
  /* ... */
};

var ComponentB = {
  components: {
    "component-a": ComponentA
  }
  // ...
};

Angular solves it with the declaration property on @NgModules:

@Component({
  selector: "component-a",
  template: "hello"
})
export class ComponentA {}

@Component({
  selector: "component-b",
  template: "<component-a></component-a>"
})
export class ComponentB {}

@NgModule({
  declarations: [ComponentA, ComponentB]
})
export class MyModule {}

The Angular compiler uses that information and adds all registered components which are used to the component definition. Actually, the directives array in the compiled component looks somehow similar to Vue's approach with the components definition.

In a simplified example, ComponentB would be compiled to this:

class ComponentB {}

ComponentB["ɵcmp"] = ɵɵdefineComponent({
  template: function(rf, ctx) {
    // template: <component-a></component-a>
    ɵɵelement(0, "component-a");
  },
  directives: [ComponentA] // <- register ComponentA
});

With that, Angular makes sure that:

The component is included in the bundle since it is referenced
The component template can compile its child components

If you want to go more into detail, here is a working example of an Angular app without NgModules and with the directives array to register components: https://stackblitz.com/edit/example-ng-without-modules

Other use cases

The AppModule is also responsible to define how the application is bootstrapped.
Even though nowadays most providers/services can be defined without NgModules it is still a solution for more complex scenarios.
In pre-Ivy applications, entryComponents needed to be defined. Not required anymore in the Ivy-world.
Additional schemas can be defined. For example to use custom elements with Angular.

How to make a component available in a NgModule

As we now learned, by declaring a component in a NgModule, we make it available to use in other components.

Let's have a closer look how we can make components available in different NgModules.

Directly declare it

@Component({
  selector: "my-component",
  template: "hello"
})
export class MyComponent {}

@NgModule({
  declarations: [MyComponent]
})
export class MyModule {}

This is the easiest way to make a component available within a NgModule.

Import it from a different NgModule

Let's say the component is declared in a different NgModule (e.g. "MyComponents") and we want to use it in "MyModule". We need to do two things:

1. Export the component to make it available for other components (think of it as public components)

@Component({
  selector: "my-component",
  template: "hello"
})
export class MyComponent {}

@NgModule({
  declarations: [MyComponent],
  exports: [MyComponent]
})
export class MyComponents {}

2. Import the NgModule (e.g. "MyComponents") in "MyModule"

@NgModule({
  ...
  imports: [MyComponents]
})
export class MyModule {}

If you only import the NgModule without exporting the component, the component is not available in the other module:

That is why you have to make sure to also export components you want to make "public".

A common question is:

Can I import my component library module in the main NgModule and then use the components in all feature modules?

Answer is no. You have to explicitly import the component library module in every feature module.

That brings up the question:

Will it have an impact on the bundle size if I import a NgModule in every feature module?

Short answer is no. But let's have a closer look in "How modules are bundled".

How modules are bundled

Angular knows two kind of NgModules:

Eagerly loaded modules
Lazy loaded modules.

The AppModule is always loaded eagerly. Lazy modules can be loaded when we navigate to a lazy route. That way the browser doesn't need to load the full application initially.

The way we define NgModules affects the resulting JavaScript bundle files.

Let's have a closer look.

Component not declared

If you don't declare a component in a NgModule, the component is not bundled. Luckily the compiler throws an error in that case.

Most simple example

The simplest example is a single module declaring a single component. In that case, as you would expect, the component is bundled in the main JavaScript bundle.

Separate EagerModule

Every eagerly loaded module is bundled in the main JavaScript bundle. Eagerly loaded modules are always defined in the AppModules import array or in a transitive module (e.g. AppModule <- EagerModule <- OtherModule).

Lazy loaded Modules

A lazy loaded module is not directly imported via the imports array but is defined within the router configuration.

const routes: Routes = [
  {
    path: "lazy-route",
    loadChildren: () =>
      import("https://raw.githubusercontent.com/ChristianKohler/Homepage/master/content/posts/2021-01-22-ng-modules/lazy.module").then(m => m.LazyModule)
  }
];

That way the module is only loaded when the user navigates to this page. Angular creates a separate JavaScript bundle for the lazy loaded module.

Shared modules

Shared modules are NgModules which declare and export some components / directives / pipes or services. We could also say it is a small library.

If a shared module is only imported in a lazy loaded module, it is bundled in the lazy bundle.

If the shared module is imported in both, an eager loaded module and a lazy loaded module it is only bundled in the main bundle.

If the shared module is imported in two lazy loaded modules (but not in an eagerly loaded module) a common bundle is generated for the shared code and loaded together with the first lazy loaded module.

Noteworthy

As you can see, Angular is very clever to split the application in multiple bundles. What you need to know though:

If you import a module, all components are bundled, even if not all are used.
The smaller the modules the better Angular can optimise the bundles.

Best practices

So now we know why and how components are bundled. But we don't now when to create a module. Should you make small or big bundles? What are the best practices?

There is no simple answer to those questions. This is why I will create a follow up post where I try to answer those questions. Stay tuned ;-)

Summary

NgModules are required to register components, directives and pipes. All eagerly loaded NgModules are bundled in the main bundle. Lazy loaded modules all have a separate bundle. Shared modules are bundled in an optimal way to not load them too early.

If you liked the article 🙌, spread the word and follow me on Twitter for more posts on web technologies.

Did you find typos 🤓? Please help improve the blogpost and open a pull request here.

Papertown - GitHub Actions Submission

Christian Kohler — Mon, 31 Aug 2020 13:50:46 +0000

My Workflow

The Papertown GitHub Action takes your personal markdown blog and syncs it with platforms like dev.to.

Setup is simple and straight-forward. It only needs a master-id in the frontmatter and then automatically creates and updates you blog articles.

I use it on my personal blog: https://github.com/ChristianKohler/Homepage

For more about Papertown read my blogpost linked below.

Submission Category:

Maintainer Must-Haves

Yaml File or Link to Code

 - name: Papertown Sync
        uses: ChristianKohler/papertown-github-action@v1.0.5
        with:
          devto-api-key: ${{ secrets.DEVTO_API_KEY }}

ChristianKohler / papertown-github-action

Github Action for https://github.com/ChristianKohler/papertown

Papertown Github Action

This action runs https://github.com/ChristianKohler/papertown

Papertown syncs you personal markdown blog with blog platforms like dev.to

Inputs

Example usage

 - name: Papertown Sync
        uses: ChristianKohler/papertown-github-action@v1.0.5
        with:
          devto-api-key: ${{ secrets.DEVTO_API_KEY }}

View on GitHub

Additional Resources / Info

This GitHub actions uses the Papertown API.

Repo: https://github.com/ChristianKohler/papertown

Blog post: https://dev.to/christiankohler/introducing-papertown-1lb7

How to avoid Prop-drilling in Angular

Christian Kohler — Sun, 02 Aug 2020 00:00:00 +0000

How to avoid Prop-drilling in Angular

How to avoid Prop-drilling in Angular, or how to apply the idea of React Context to Angular.

Should I be interested?
The „how“ and the „where“
What is Prop Drilling?
The problem of Prop Drilling by example
How to avoid prop drilling
Global state vs. Context-like state vs. Prop drilling
Summary

Tldr;

If you prefer to use Input/Outputs in Angular you might find yourself writing a lot of boilerplate code to propagate events up the component hierarchy. As a solution you could add that state into a global service.

A better approach is to put the state into a service provided by a component on the highest level necessary. This can be achieved by using the hierarchical dependency injection system of Angular.

Should I be interested?

If you have all your state in a global store, this article is not for you. But..

if you try to keep your state and logic as close as possible to where it is used
and you often end up propagating state and actions through multiple components

..then read on 👇

The „how“ and the „where“

State management is a broad topic. To make it easier the topic can be divided into two parts. The "how" and the "where".

The "how" defines how to handle state. Are you using redux, mobx, ngrx or just a simple class with getter and setter? Is your data immutable or not?

The "where" defines whether you have multiple stores / states. For example a common pattern with redux is to have one global store. But it's possible to have local stores or feature stores. State can be within a single component or within a subtree of components.

In this blogpost I don't cover the "how" but look into the "where". I try to keep the examples as simple as possible. That's why I don't use any "fancy" state management library, only pure typescript and a mutable data structure.

What is Prop Drilling?

Kent C. Dodds wrote a good blog post about Prop Drilling.

Prop drilling is propagating or threading data through multiple levels of components. Since we don't use props in Angular we could also call it input/output drilling.

The problem of Prop Drilling by example

Let's look at the problem by writing a small todo app.

Disclaimer: The example is not complete. Some parts might be oversimplified or overengineered.

Simple List

We start with a simple "one-component" application with a list of todos.

@Component({
  selector: "todo-list",
  template: `
    <div *ngFor="let todo of todos">
      {{ todo }}
    </div>
  `
})
export class TodoList {
  todos = ["Buy milk", "Pay bills"];
}

Add a Filter

Now we want to add a filter. Since we want to share our state we create a component called "Todos" which contains the state.

@Component({
  template: `
    <todo-filter [(filter)]="filter"></todo-filter>
    <todo-list [todos]="filteredTodos"></todo-list>
  `
})
export class Todos {
  todos = [
    { title: "Buy milk", due: "today" },
    { title: "Pay bills", due: "tomorrow" }
  ];
  filter = "today";

  get filteredTodos() {} // return filtered todos
}

Add a TodoItem Component

Now we want to replace the todo string in the TodoList component with a component. We create a "TodoItem" component for that.

@Component({
  selector: "todo-list",
  template: `
    <todo-item
      *ngFor="let todo of todos"
      [todo]="todo"
    ></todo-item>
  `
})
export class TodoList {
  @Input() todos;
}

@Component({
  selector: "todo-item",
  template: `
    <div>{{ todo.title }}</div>
  `
})
export class TodoItem {
  @Input() todo;
}

Add a ToggleTodo Component

Now we want to add another component within "TodoItem" called "ToggleTodo". This component should display a checkbox and call a method named "toggleTodo()" on the state.

Note: For such a simple application this ToggleTodo component definitely is too much component splitting. I do it here to make the problem of prop drilling more visible.

/**
 * The toggle event is handled here
 */
@Component({
  template: `
    <todo-filter [(filter)]="filter"></todo-filter>
    <todo-list
      [todos]="filteredTodos"
      (toggle)="toggleTodo($event)"
    >
    </todo-list>
  `
})
export class Todos {
  todos = [
    { title: "Buy milk", due: "today" },
    { title: "Pay bills", due: "tomorrow" }
  ];
  filter = "today";

  get filteredTodos() {} // return filtered todos

  toggleTodo(id: number) {} // handle toggle
}

/**
 * TodoList has to pass the event on
 */
@Component({
  selector: "todo-list",
  template: `
    <todo-item
      *ngFor="let todo of todos"
      [todo]="todo"
      (toggle)="toggle.emit($event)"
    ></todo-item>
  `
})
export class TodoList {
  @Input() todos;
  @Output() toggle = new EventEmitter<number>();
}

/**
 * TodoItem has to pass the event on
 */
@Component({
  selector: "todo-item",
  template: `
    <toggle-todo
      [todo]="todo"
      (toggle)="toggle.emit($event)"
    ></toggle-todo>

    <span>
      {{ todo.title }}
    </span>
  `
})
export class TodoItem {
  @Input() todo;
  @Output() toggle = new EventEmitter<number>();
}

/**
 * The event starts here
 */
@Component({
  selector: "toggle-todo",
  template: `
    <input
      type="checkbox"
      [checked]="todo.done"
      (change)="toggle.emit(todo.id)"
    />
  `
})
export class ToggleTodo {
  @Input() todo;
  @Output() toggle = new EventEmitter<number>();
}

As you can see, this leads to a lot of boilerplate since we have to emit the toggle event from component to component.

This is the problem of prop drilling. To set the state from the ToggleTodo we have to go through TodoItem and TodoList.

How to avoid prop drilling

React has a nice solution for that problem. It's called context.

https://reactjs.org/docs/context.html

Context provides a way to pass data through the component tree without having to pass props down manually at every level.

Angular doesn't have a functionality like context but we can use its powerful dependency injection system to achieve the same goal.

Note that React's context and Angular's DI are fundamentally different in how the work.

Angular's hierarchical dependency injection system

Angular comes with a hierarchical dependency injection system. I've created a infographic poster to visualise that system.

What you need to know for know is that every component has its own injector and that child components can access the services from further up in the hierachy.

Todo App with context-like state

So let's use the power of Angular's DI system to create a context for our state.

We are going to provide the state in the Todos component and inject it in the ToggleTodo component.

/**
 * Create the state service
 */
export class TodoState {
  todos = [
    { id: 0, title: "Buy milk", done: true },
    { id: 1, title: "Pay bills", done: false }
  ];

  get filteredTodos() {} // return filtered todos

  toggleTodo(id: number) {} // handle toggle
}

/**
 * Provide the TodoState in the Todos component
 */
@Component({
  template: `
    <todo-filter
      [(filter)]="todoState.filter"
    ></todo-filter>
    <todo-list
      [todos]="todoState.filteredTodos"
    ></todo-list>
  `,
  providers: [TodoState] // <--- provide it here
})
export class Todos {
  constructor(public todoState: TodoState) {}
}

/**
 * Use the TodoState in the ToggleTodo component
 */
@Component({
  selector: "toggle-todo",
  template: `
    <input
      type="checkbox"
      [checked]="todo.done"
      (change)="todoState.toggleTodo(todo.id)"
    />
  `
})
export class ToggleTodo {
  @Input() todo;

  /**
   * Inject the TodoState here
   */
  constructor(public todoState: TodoState) {}
}

Introducing the TodoState service in this example reduced the boilerplate of propagating the toggle event from component to component. It's a nice way to reduce boilerplate without the need to throw the state into the "global bucket".

Global state vs. Context-like state vs. Prop drilling

I think there is a place for all concepts, even in the same application.

Personally I try to start with Inputs/Outputs. It is easier to follow and refactor (like a pure function) and change detection is also easier to understand.

When I feel that the added boilerplates negates the benefits of Inputs/Outputs I switch to context-like state services. This reduces boilerplate but still keeps the state as close as possible to where it is used.

Some state is global. One common example is the selected theme. In this case I'd use a global service like this one:

@Injectable({
  providedIn: "root"
})
export class ThemeProvider {
  selectedTheme = "light";

  selectLightTheme() {
    this.selectedTheme = "light";
  }
  selectDarkTheme() {
    this.selectedTheme = "dark";
  }
}

You might ask yourself why not make everything global. In small applications like the todo example from this post, putting the state into a global service is fine. But the more complex you application is, the more important it is to keep your logic and state as close as possible to where you use it.

Summary

In this blog post you learned that there is not just global or local state in Angular. With the power of the hierarchical DI system we can provide a state service in the the exact (highest) place in the component tree where we need it to be. This is often a nice compromise between having a local state and making it globally available.

If you liked the article 🙌, spread the word and follow me on Twitter for more posts on web technologies.

Did you find typos 🤓? Please help improve the blogpost and open an issue here

It’s a trap - The biggest pitfall of String.prototype.replace()

Christian Kohler — Tue, 30 Jun 2020 00:00:00 +0000

Replacing a substring is a very common task. It should also be a very simple one but actually it isn’t.

In this short post I will show you the biggest pitfall, how to avoid it and how a new JavaScript feature is going to improve the situation.

tl;dr

String.prototype.replace only replaces the first occurrence when used with a string as pattern argument. A global regex can be used to replace all occurrences instead.

String.prototype.replaceAll will fix that and also replace all occurrences with a string pattern.

What we want to achieve

We want to replace 🌧 with 🌈 in this weather forecast which is basically a string.

// Input:  "Mon: 🌧, Tue: 🌧, Wed 🌧"
// Result: "Mon: 🌈, Tue: 🌈, Wed 🌈"

Naive approach (the pitfall 🚨)

The first approach most (newbie) developers would use is String.prototype.replace with a substring argument.

replace takes two arguments. The first argument can be either a substring or a regex pattern, the second argument is the replacement substring.

"Mon: 🌧, Tue: 🌧, Wed 🌧".replace("🌧", "🌈");

The result would look like this. Only the first occurrence would be replaced.

// Result: "Mon: 🌈, Tue: 🌧, Wed 🌧"

String.prototype.replace only replaces the first occurrence when used with a substring argument.

The pitfall is that you might test your code for a single replacement but it then fails when the string has more then one occurrence.

I said that would be the approach taken by newbies but honestly I still find myself walking in this trap from time to time.

Now let’s have a look how you can replace all occurrences in a string.

Working approach (with regex)

When using a global regex pattern instead of a simple substring for the first argument the String.prototype.replace function replaces all occurrences.

// Input:  "Mon: 🌧, Tue: 🌧, Wed 🌧"
// Result: "Mon: 🌈, Tue: 🌈, Wed 🌈"
"Mon: 🌧, Tue: 🌧, Wed 🌧".replace(/🌧/g, "🌈");

This approach works, is supported by all browsers and is fast. But it’s harder to read and you have to remember to use the regex pattern if you want to replace all occurrences.

New approach (with replaceAll)

For many use cases a regex is not required and just makes the code a little bit harder to read. That’s were the new String.prototype.replaceAll comes in. ReplaceAll is a stage 4 proposal but is already supported by most modern browsers.

It allows you to replace all occurrences with the substring argument.

// Input:  "Mon: 🌧, Tue: 🌧, Wed 🌧"
// Result: "Mon: 🌈, Tue: 🌈, Wed 🌈"
"Mon: 🌧, Tue: 🌧, Wed 🌧".replaceAll("🌧", "🌈");

When to use which approach?

There are a few things to consider.

Compatibility. Check if your targets support String.prototype.replaceAll directly or if your toolchain (e.g. babel) polyfills it. You can check the status here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replaceAll

Performance. Both functions are very fast for short strings. If you don’t plan to parse a full book the difference is neglectable.

Here are the results of the benchmark in Safari. Those results differ depending on your browser and machine. They might also change with future browser versions.

"...".replace(/🌧/g, "🌈"); // 130,000,000 ops/s
"...".replaceAll("🌧", "🌈"); //   6,300,000 ops/s
"...".replaceAll(/🌧/g, "🌈"); //   1,600,000 ops/s

I came up with two simple rules which makes it easier to decide what to use.

Rule I

Always use replaceAll if your environment supports it. You can use it with the string pattern or the regex pattern and you avoid the pitfall of replacing only the first occurrence. This is imho how replace should work.

Rule II

If you have to use replace, avoid the string pattern and always use the regex patten. You could even add a linting rule to avoid the pitfall.

Summary

If you reached the end of the blogpost, congratulations on reading a full blogpost about a single JavaScript function 😉

I hope I could show you the problem with replace and how to avoid it.

If you liked the article 🙌, spread the word and follow me on Twitter for more posts on web technologies.

Did you find typos 🤓? Please help improve the blogpost and open an issue here

Resources

GitHub - tc39/proposal-string-replaceall: ECMAScript proposal: String.prototype.replaceAll
String.prototype.replaceAll · V8
core-js/esnext.string.replace-all.js at master · zloirock/core-js · GitHub
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replaceAll

Lessons learned from building a Grid List in React Native

Christian Kohler — Fri, 05 Jun 2020 00:00:00 +0000

tl;dr

Use the power of flexbox and aspectRatio to build a dynamic grid which works for all screens and orientations.

Goal

We want to build a photo grid which is easy to use, supports both portrait and landscape orientation and has configurable columns.

Flatlist

https://reactnative.dev/docs/flatlist makes it really easy to implement a photo grid. It handles all the hard work of big lists and comes with build in support for columns. We use Flatlist to build our grid.

Simple Flatlist Example

This is a full app example how to use a Flatlist. Try it out on expo.io

import * as React from "react";
import { Image, FlatList } from "react-native";

const picsumImages = new Array(11).fill("http://placeimg.com/640/360/any");

function renderItem({ item }) {
  return <Image source={{ uri: item }} style={{ height: 100 }} />;
}

export default function App() {
  const [images, setImages] = React.useState(picsumImages);
  return <FlatList data={images} renderItem={renderItem} />;
}

We only need to provide those attributes to make it work:

data -> array of items we want to iterate over
renderItem -> the component we want to render per item

The result is a list of images with a height of 100 and stretched to full width.

Flatlist with columns

To create a grid from the previous example is straight forward. We only have to define the number of columns:

<FlatList data={images} renderItem={renderItem} numColumns={4} />

👉 If you coded along you might have noticed that the screen is now white and no images are displayed. The is because we didn't define a width for the individual items.

Let's just add a fixed width for now:

<Image source={{ uri: item }} style={{ height: 100, width: 100 }} />

The result is a grid. But since the width is fixed to 100 the last image is clipped. Open in snack.expo.io

Set tile size with dimension api

One approach to fix the clipping problem is to read the width of the screen and then calculate the the tile width:

import { Image, Dimensions } from "react-native";

const screenWidth = Dimensions.get("window").width;
const numColumns = 4;
const tileSize = screenWidth / numColumns;

<Image source={{ uri: item }} style={{ height: tileSize, width: tileSize }} />;

The result is a nice photo grid that works. Here is a working example

What I don't like about the solution is that I have to calculate the tile size manually. With my web background I always prefer a fluid solution.

Set tile size with flexbox

React Native comes with a great support for flexbox. So let's get rid of the dimension api and replace it with flexbox.

<Image source={{ uri: item }} style={{ height: 100, flex: 1 }} />

So my first approach gives me this result. Live example

There are two problems here:

The height is fixed which breaks the aspect ratio of 1
If the number of items can not be divided by the number of columns the bottom items are stretched

Introducing the aspect ratio

The aspect ratio problem is easy to fix. Just remove the height property and define the aspectRatio:

<Image source={{ uri: item }} style={{ aspectRatio: 1, flex: 1 }} />

Live example (Make sure you run it in the simulator since the web view doesn't support the aspectRatio property)

Using flex with 1/numColumns

There are at least two ways how to fix the stretched bottom items issue:

Add fake empty items to fill it up
Use flex 1/numColumns

I want to focus on the flex/numColumns solution.

It's actually pretty simple. Just set the flex to 1/numColumns

const numColumns = 4;

<Image
  source={{ uri: item }}
  style={{ aspectRatio: 1, flex: 1 / numColumns }}
/>;

Here is a live example (Make sure you run it in the simulator since the web view doesn't support the aspectRatio property)

Summary

Flatlist makes it very easy to build a photo grid with React Native. flexbox helps to create fluid layouts without the need to know the exact dimensions of the screen.

Creating a grid is a very common problem and I hope I could show you an easy and robust way how to do that.

If you liked the article 🙌, spread the word and follow me on Twitter for more posts on React Native, Angular and web technologies.

Did you find typos 🤓? Please help improve the blogpost and open an issue here

Final code

import * as React from "react";
import { Image, FlatList, Dimensions } from "react-native";

const picsumImages = new Array(11).fill("http://placeimg.com/640/360/any");

const numColumns = 4;

function renderItem({ item }) {
  return (
    <Image
      source={{ uri: item }}
      style={{ aspectRatio: 1, flex: 1 / numColumns }}
    />
  );
}

export default function App() {
  const [images, setImages] = React.useState(picsumImages);
  return (
    <FlatList data={images} renderItem={renderItem} numColumns={numColumns} />
  );
}

Reactive Angular with ngrx/component

Christian Kohler — Sun, 22 Mar 2020 00:00:00 +0000

tl;dr

Angular change detection relies on Zone.js which works well in most situations but is hard to debug and might lead to performance problems.

With the rise of reactive programming in Angular we might not need Zone.js at all and instead trigger change detection whenever the view state changes.

Michael Hladky and the ngrx team are working on a library named ngrx/component to make it easier to trigger change detection with observables.

In this article we look at how this new library helps us write maintainable code without Zone.js

🤔 What's wrong with Zone.js?
🔦 When should we run change detection?
🚲 Zone less approach in Angular
💡 Change detection in a reactive application
🚧 Async Pipe
🚀 ngrx PushPipe and let directive
❓ Should I now rewrite my code?
👩‍🚀 Be ready for a reactive (zone-less) future
📚 Resources

What's wrong with Zone.js? 🤔

Most Angular developers learn about Zone.js when they run into change detection issues. Zone.js doesn't do change detection but triggers it after async operations were completed. One good example is a setTimeout() callback after which Zone.js triggers change detection.

In general Zone.js just works and helps Angular developers write less code.

But every design decision has its pros and cons.

The problems withs Zone.js are

it's hard to debug
it might lead to performance issues
no native async await support (Typescript target: ES2017 or higher)

Zones.js allows for a mix of imperative and reactive code

I often see how part of an Angular application is written in a imperative way and part of it reactive. It's not always a bad thing but I feel that the mix often makes it harder to read code.

In 2019 Rob Wormald talked about Zone.js in his keynote. He said:

Zones are great until they are not.

Watch the full keynote here: Rob Wormald - Keynote - What's New and Coming in Angular | AngularUP 2019

When should we run change detection? 🔦

With Zone.js Angular change detection magically works for almost any scenario. To make it work, it assumes that whenever you have an event like a click event, the state changed and the view has to be rerendered.

Let's take that simple example:

@Component({
  template: `
    <div>Count is {{ count }}</div>
    <button (click)="increment()">Increment</button>
    <button (click)="noEffect()">Dummy Button</button>
  `
})
export class AppComponent {
  count = 0;

  // triggers change detection
  increment() {
    this.count = this.count + 1;
  }

  // also triggers change detection
  noEffect() {}
}

In this example Angular needs to trigger change detection after the increment method because we want to update our view. But we don't need to trigger change detection after we call the noEffect method

Ideally we only trigger change detection when the view state changes

The React way

In React you change the state explicitly which then triggers a rerender. In the following example the setCount sets part of the state.

function Example() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
}

This approach is easy to understand and to debug.

Zone less approach in Angular 🚲

So let's get rid of Zone.js and let's try to make change detection more predictable and easier to debug.

We can easily disable Zone.js in Angular by setting ngZone to "noop":

platformBrowserDynamic().bootstrapModule(AppModule, {
  ngZone: "noop"
});

Since change detection is not triggered anymore by Zone.js we need to trigger it manually:

export class AppComponent {
  count = 0;

  constructor(private cdRef: ChangeDetectorRef) {}

  increment() {
    this.count = this.count + 1;
    this.cdRef.detectChanges();
  }

  noEffect() {}
}

This approach works but involves a lot of manual work and pollutes our code with change detection logic. Also due to the imperative nature of that code it can become very difficult to understand what triggered change detection the more complex the code gets.

Change detection in a reactive application 💡

In a reactive application we know exactly when a change happens. Every time a new value is emitted in a observable. And whenever a change happens we can trigger change detection. This means we don't need to rely on Zone.js to trigger change detection.

When every view state is an observable, we know exactly when to trigger change detection.

Notice how this is a very similar to Reacts approach?

Async Pipe 🚧

With Zone.js deactivated the first idea for a reactive approach would be to use Angulars async pipe to trigger change detection when a new value is emitted.

@Component({
  template: `
    <div>Count is {{ count$ | async }}</div>
    <button (click)="increment()">Increment</button>
    <button (click)="noEffect()">Dummy Button</button>
  `
})
export class AppComponent {
  increment$ = new Subject();

  count$ = this.increment$.pipe(
    scan(count => count + 1, 0),
    startWith(0)
  );

  increment() {
    this.increment$.next();
  }
}

Unfortunately that doesn't trigger change detection since the async pipe only runs markForChecked on the components ChangeDetectorRef.

So we need an async pipe which can trigger change detection. Luckily there is a library coming up for exactly that.

ngrx PushPipe and let directive 🚀

Michael Hladky and the ngrx team are working on a new library named ngrx/component. It's not released yet but we can already try it out. It's a collection of tools to make it easier to write reactive angular components.

Or as Michael Hladky says:

"The idea of ngrx/component is building applications where the word subscribe is not present."

In #rxjs .subscribe() is where reactive programming ends
— Michael Rx Hladky (@michael_hladky ) October 5, 2019

Currently it consists of two features:

PushPipe, a drop in replacement for the async pipe
Let directive, an enhancement/alternative to ngIf for binding observable values

PushPipe

The PushPipe is a drop in replacement for the async pipe. It triggers change detection in a zone-less context or triggers markForCheck like the async pipe in a zone context.

Usage

Replace the async pipe:

{{ count$ | async }}

with the ngrx PushPipe:

{{ count$ | ngrxPush }}

Example

Here is a Stackblitz example with the counter and the PushPipe. Try it out and replace the ngrxPush with async to see how it affects change detection. Also check the PushPipe documentation for more examples.

Let Directive

Another great addition to make it easier to build reactive Angular components is the let-directive.

The let directive is similar to *ngIf but handles 0 values and supports zone-less the same way the PushPipe does. That means it also triggers change detection when a new value is emitted.

The let-directive does not provide the show/hide funtionality which is imho a good design decision. The let-directive binds to observable values and the ngIf can then be used for the show/hide logic. It's a nice seperation of concerns.

Usage

Replace the *ngIf:

<div *ngIf="count$ | async as count">Count is {{ count }}</div>

width *ngrxLet:

<div *ngrxLet="count$ as count">Count is {{ count }}</div>

Example

Here is a Stackblitz example with the counter and the let directive. Try it out and replace the ngrxLet with ngIf to see how it affects change detection. Also check the Let directive documentation for more examples.

How PushPipe and the let-directive improve performance?

PushPipe and the let-directive improve performance in two ways:

Only trigger change detection when a new observable value is emitted
Trigger change detection only for the component and its children

Should I now rewrite my code? ❓

Short answer: Keep Zone.js for now but start using PushPipe and let-directive

What I showed you in the examples is a zone-less full reactive Angular example. You don't have to go zone-less to make your application more reactive. Let's look at the different motivations behind using ngrx/component.

Motivation "Reactive Angular"

If you don't have any problems with Zone.js or performance I would keep Zone.js turned on. Focus on writing reactive code. Ngrx/component makes it easier with features like the let-directive.

Motivation "Zone-less Angular"

You want to get rid of Zone.js and improve performance by only rerendering the current component and its children. A good use case would be Angular Elements. It would simplify the usage of Angular Elements and reduce the bundle size. Ngrx/component is the easiest way to go Zone-less. Only replace the async pipe with the new PushPipe.

🧨 If you turn off Zone.js, some 3rd party libraries might not work anymore. For example, Angular Material select doesn't work out of the box without Zone.js. Try it out and disable Zone.js here.

✨ Start using PushPipe and the let-directive

👉 PushPipe and the let directive are not released yet (as of 23 March 2020). I will update this post after the release.

Since both, PushPipe and let-directive, work with Zone.js enabled you can use them as a drop in replacement today. When you ever decide to turn off Zone.js it just works (which is not the case with the async pipe).

The let-directive is also more than just a zone-less ngIf. It seperates the show/hide functionality from binding to observable values.

Be ready for a reactive (zone-less) future 👩‍🚀

Angular makes it easy to write reactive code. Default libraries like the router and the http client provide observables. Ngrx builds on observables. With ngrx/component it gets even easier to write full reactive code. Full reactive code makes it also much easier to know when to trigger change detection and to write zone-less code.

If you are a developer, embrace RxJS and write your code in a reactive way. It will make it easier for you to use new features like the PushPipe.

If you are a 3rd party library maintainer make sure your library works in a zone-less environment.

If you liked the article 🙌, spread the word and follow me on Twitter for more posts on Angular and web technologies.

Huge thanks to Michael Hladky for his inputs and reviews, and the work he put into ngrx/component.

Did you find typos 🤓? Please help improve the blogpost and open an issue here

Resources 📚

How to use ResizeObserver with Angular

Christian Kohler — Mon, 24 Feb 2020 00:00:00 +0000

tl;dr

Sometimes we need to execute JavaScript when an element is resized.

Current solutions are based on the viewport dimension, not on element dimensions.

ResizeObserver is a new API which allows us to react to element resizing.

There are a few steps required to use it properly with Angular. You have to make sure:

to unobserve on destroy
that change detection is triggered

I found it to cumbersome to do it on every component. That's why I've created a library to simplify the usage with Angular. 🚀

✨React to element dimension changes

Many changes in screen size or element size can be handled with pure CSS. But sometimes we need to know when an element is resized and execute some logic in JavaScript.

This is usually implemented with either window.onchange or matchMedia. Both solutions are based on the viewport dimension, not the element dimension.

ResizeObserver ResizeObserver - Web APIs | MDN is a new API to solve exactly this problem. In this article we will have a look at how it works and how we can use this new API together with Angular.

Let's start with why we need a new API.

💣 What's the problem with window.onchange?

We are only interested in events where our component changes its width. Unfortunately window.onchange sometimes fires too often or not at all.

onchange fires too often

This happens when the viewport changes but our component doesn't. Do you see the first window.onresize (colored in red)? We are not interested in this event. Running to much code on every onresize could lead to performance problems.

onchange doesn't fire (but should)

This happens when the viewport doesn't change but the elements within change.

Examples

New elements are added dynamically
Elements are collapsed or expanded (e.g. Sidebar)

In the graphic below the viewport doesn't change and the sidebar gets expanded. The ResizeObserver triggers but the window.onresize doesn't.

Now that we know why we need the new ResizeObserver Api we will take a closer look at it.

🚀 ResizeObserver in a nutshell

Here is an example on how to use ResizeObserver to subscribe to a resize event of an element.

You can observe multiple elements with one ResizeObserver. That's why we have an array of entries.



const observer = new ResizeObserver(entries => {
  entries.forEach(entry => {
    console.log("width", entry.contentRect.width);
    console.log("height", entry.contentRect.height);
  });
});

observer.observe(document.querySelector(".my-element"));

This is how an entry looks like:



{
  "target": _div_,
  "contentRect": {
    "x": 0,
    "y": 0,
    "width": 200,
    "height": 100,
    "top": 0,
    "right": 200,
    "bottom": 100,
    "left": 0
  }
}

Since we subscribed to an observer, we need to unsubscribe as well:



const myEl = document.querySelector(".my-element");

// Create observer
const observer = new ResizeObserver(() => {});

// Add element (observe)
observer.observe(myEl);

// Remove element (unobserve)
observer.unobserve(myEl);

That's ResizeObserver in a nutshell. For a full overview of what you can do with ResizeObserver, check out ResizeObserver - Web APIs | MDN

🏁 Status ResizeObserver

At the time of writing (Feb 2020), ResizeObserver is a EditorsDraft Resize Observer. This means it is still in a very early phase World Wide Web Consortium Process Document

Chrome and Firefox support ResizeObserver, Edge and Safari don't. A ponyfill is available.

🛠 How to use it with Angular

Let's create a component which displays its width.

1: Create the component



@Component({
  selector: "my-component",
  template: "{{ width }}px"
})
export class MyComponent {
  width = 500;
}

2: Add Observer

Now let's observe the nativeElement of our component and log the current width. Works like a charm (in Chrome and Firefox 😉)



export class MyComponent implements OnInit {
  width = 500;

  constructor(private host: ElementRef) {}

  ngOnInit() {
    const observer = new ResizeObserver(entries => {
      const width = entries[0].contentRect.width;
      console.log(width);
    });

    observer.observe(this.host.nativeElement);
  }
}

3: Trigger change detection

If you are following this example you may have tried to bind the width directly to the class property. Unfortunately the template is not rerendered and keeps the initial value.

The reason is that Angular has monkey-patched most of the events but not (yet) ResizeObserver. This means that this callback runs outside of the zone.

We can easily fix that by manually running it in the zone.



export class MyComponent implements OnInit {
  width = 500;

  constructor(
    private host: ElementRef, 
    private zone: NgZone
  ) {}

  ngOnInit() {
    const observer = new ResizeObserver(entries => {
      this.zone.run(() => {
        this.width = entries[0].contentRect.width;
      });
    });

    observer.observe(this.host.nativeElement);
  }
}

4: Unobserve on destroy

To prevent memory leaks and to avoid unexpected behaviour we should unobserve on destroy:



export class MyComponent implements OnInit, OnDestroy {
  width = 500;
  observer;

  constructor(
    private host: ElementRef, 
    private zone: NgZone
  ) {}

  ngOnInit() {
    this.observer = new ResizeObserver(entries => {
      this.zone.run(() => {
        this.width = entries[0].contentRect.width;
      });
    });

    this.observer.observe(this.host.nativeElement);
  }

  ngOnDestroy() {
    this.observer.unobserve(this.host.nativeElement);
  }
}

Want to try it out? Here is a live example.

5: Protip: Create a stream with RxJS



export class MyComponent implements OnInit, OnDestroy {
  width$ = new BehaviorSubject<number>(0);
  observer;

  constructor(
    private host: ElementRef, 
    private zone: NgZone
  ) {}

  ngOnInit() {
    this.observer = new ResizeObserver(entries => {
      this.zone.run(() => {
        this.width$.next(entries[0].contentRect.width);
      });
    });

    this.observer.observe(this.host.nativeElement);
  }

  ngOnDestroy() {
    this.observer.unobserve(this.host.nativeElement);
  }
}

Follow me on 🐦 twitter for more blogposts about Angular and web technologies

☀️ Use ng-resize-observer to simplify the usage of ResizeObserver

💻 https://github.com/ChristianKohler/ng-resize-observer

📦 https://www.npmjs.com/package/ng-resize-observer

Install ng-resize-observer
Import and use the providers
Inject the NgResizeObserver stream



import { NgModule, Component } from "@angular/core";
import {
  ngResizeObserverProviders,
  NgResizeObserver
} from "ng-resize-observer";

@Component({
  selector: "my-component",
  template: "{{ width$ | async }} px",
  providers: [...ngResizeObserverProviders]
})
export class MyComponent {
  width$ = this.resize$.pipe(
    map(entry => entry.contentRect.width)
  );

  constructor(private resize$: NgResizeObserver) {}
}

NgResizeObserver is created per component and will automatically unsubscribe when the component is destroyed. It's a RxJS observable and you can use all operators with it.

Want to try it out? Here is a live example on Stackblitz

Make the web resizable 🙌

ResizeObservers allow us to run code exactly when we need it. I hope I could give you an overview over this new API.

If you want to use it in your Angular application, give ng-resize-observer a try and let me know what you think.

If you liked the article 🙌, spread the word and follow me on twitter for more posts on Angular and web technologies.

Angular Dependency Injection Infographic

Christian Kohler — Mon, 03 Feb 2020 00:00:00 +0000

Angular has its own dependency injection framework. It's very powerful and helps increase the efficiency and modularity of your application. It can also be quite complex when compared to traditional DI frameworks.

The official documentation is very well written and a must read for every Angular developer. The only thing missing for me was a good graphical overview. This is why I created this infographic poster.

👩‍🚀 Protip: 🖨 Print your DI poster and hang it in the toilet. Within a few weeks your work colleagues are DI experts 😀

✅ Also feel free to use the poster for education purposes like workshops or in classes.

👆 It took me hours to complete this cheatsheet. If you like it follow me on twitter and spread the word 🙌

🤓 Did you find a mistake? Please help improve the infographic and open an issue here

Download Angular DI Infographic as PDF

Update 20.02.2020

Added providedIn: Module example
Simplified Provider Syntax (removed string tokens)
Minor design improvements

Improved Dependency Injection with the new providedIn scopes 'any' and 'platform'

Christian Kohler — Sun, 15 Dec 2019 00:00:00 +0000

Have you looked at the changelog of Angular 9 and found the new functionality of providedIn and want to know what 'any' and 'platform' are for? In this article we look at the two new scopes of providedIn.

tl;dr

'platform' and 'any' are two new ways to define where a service should be resolved.



@Injectable({
  providedIn: "root" | "any" | "platform"
})
export class MyService {}

'platform' makes a service available between multiple apps or Angular Elements
'any' creates isolated (not singleton) services for every child injector.

Official Angular 9 documentation

The offical documentation describes the new scopes as follows:

'root' injector, which will be the application-level injector in most apps.
'platform' injector, which would be the special singleton platform injector shared by all applications on the page.
'any' injector, which would be the injector which receives the resolution. (Note this only works on NgModule Injectors and not on Element Injector)

The documentation already gives us a good overview of the new scopes. In the next chapters I'll go into the individual scopes in more detail.

Quick Angular DI recap

** Module Injectors **

There are two injector hierarchies in Angular:

ModuleInjector
ElementInjector (NodeInjector in Ivy)

See Hierarchical injectors

In this article we only look at the ModuleInjectors.

A simplified visualization of the module injector hierachy would like this:

Your services are in one of those injectors (Most likely in the root injector).

Platform Injector (special things like DomSanitizer)
root Injector (main injector and place for all eagery loaded module providers)
LazyModules Injectors (all lazy loaded modules create a child injector)

** Pre Angular 6 **

The only way to define providers was with the providers array. Services were singletons in eagerly loaded modules but could be instatiated multiple times with lazy loaded modules.



@NgModule({
  providers: [MyService]
})
export class MyModule {}

** Angular 6+ **

Angular 6 introduced tree-shakable providers with providedIn: 'root'.



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

This has 3 big advantages:

Services are tree-shakable
Services are singleton for the whole application, also for lazy loaded modules
No need to explicitly register the service with a NgModule

If you want to know more about this, read the excellent article by Tomas.

** Angular 9 ✨ **

Now with Angular 9 we have two new ways to define providedIn scopes:

any
platform

Let's have a look at them.

ProvidedIn: root

Every service defined with 'root' will be provided in the root injector and is a singleton for the whole application. Lazy modules will use the instance from root.

providedIn: 'root' will still be the default choice for most services.

ProvidedIn: platform

Every service defined with 'platform' will be provided in the platform injector and is a singleton for all applications. Lazy modules will use the instance from platform.

The difference between 'root' and 'platform' is only noticeable when running multiple Angular application in the same window. Both make sure that only one singleton exists even for lazy loaded modules. But when running two applications in the same window, each application has it's own root injector but both share the platform injector.

This means that the best use case for providedIn: 'platform' is for sharing services over application boundaries. E.g. with Angular Elements.

Use providedIn: 'platform' for sharing services over application boundaries. E.g. with Angular Elements.

ProvidedIn: any

Every service defined with 'any' will be provided in every module it is used. That means there might be multiple instances of the same service. That means that every lazy loaded module has it's own instance of the service. All eagerly loaded modules share one instance provided by the root module injector.

In the following example is the service used twice. Once within an eagerly loaded module (provided by root) and once in Lazy Module B (provided by its child injector).

What's really cool with that approach is, that you can make sure that a child injector always has it's own instance without the need to register the service in the providers list. 💪

Summary

'Root' will still be the default for most services. It makes it very convenient to create tree-shakable services which are singleton within an application.

'Platform' is most likely used for creating shared services for Angular Elements. If you know another use case, please let me know an create a PR on this article.

'Any' is very helpful to make sure a service is a singleton within module boundaries. It's a robust alternative to 'root' to make sure the individual modules don't have a side effect on each other.

All in all a very welcome feature 🥳

👆 If you like the article follow me on twitter 🙌

One bite at a time - How to introduce new lint rules in a large codebase

Christian Kohler — Tue, 26 Nov 2019 00:00:00 +0000

Linters such as ESLint or TSLint can help make your code more readable and maintainable, and help you detect errors earlier. It's good to use linters from the beginning, but it's also a good idea to introduce linters into an existing code base.

This article focuses on the introduction of linters into existing code bases.

tl;dr;

Use autofix if possible
Extend lint config with a second config
Add new rules to the second config
Run linter with the second config with a precommit hook

The problem

Let's say the codebase is 1000 files large. You create a linter config, run the linter and you get like 1000000 errors. 🤯😱

Now what can you do?

Autofix

A lot of linting rule can be autofixed. For example the tslint rule

"no-var-keyword": true

can be autofixed. The autofixer replaces the var keyword with a let keyword.

Tip: All autofixable keywords in the list have the "Has Fixer" tag.

Manually fix

If you can't fix it automatically, you have to fix it manually. This can be a "Herculean task". So what often happens is that a rule is simply not used because it's too much work to fix all existing bugs.

The solution: The Boy Scout Rule

Leave your code better than you found it. ...

The boy scout approach to apply new rules is:

Fix existing errors when you touch existing code
Don't add new errors

Different Rules for CI/CD and changed files

We need two sets of rules. The main one and one which extends it and adds new rules.

Name	Usage	Rules
tslint.json	CI/CD	Rules which apply for all files
tslint.newrules.json	precommit hook	New rules which only apply for changed files

Example tslint.json

Used by the CI/CD pipeline.

{
  "defaultSeverity": "error",
  "rules": {
    "no-empty": true
  }
}

Example tslint.newrules.json

Used during the precommit hook.

{
  "defaultSeverity": "error",
  "extends": ["https://raw.githubusercontent.com/ChristianKohler/Homepage/master/content/posts/2019-11-25-lint-one-bite-at-a-time/tslint.json"],
  "rules": {
    "no-any": true
  }
}

Important: The tslint.newrules.json extends the main ruleset.

{
  "extends": ["https://raw.githubusercontent.com/ChristianKohler/Homepage/master/content/posts/2019-11-25-lint-one-bite-at-a-time/tslint.json"]
}

Enforce tslint.newrules.json with a precommit hook

This part is very easy nowadays thanks to the amazing libraries lint-staged and husky.

So just install lint-staged and then configure the precommit hook to run tslint or eslint with the the correct configuration.

npm install --save-dev lint-staged@beta

{
  "lint-staged": {
    "**/*.{ts}": ["tslint --project tsconfig.json -c tslint.newrules.json"]
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  }
}

Summary

It is easy and very little work to set up a "newrule" configuration and enforce the configuration with a pre-commit hook. Now your codebase should get better every day as people work on it. Without the upfront costs, you would have to fix all the bugs in a commit. That's how you eat an elephant. One bite at a time.

“How do you eat an elephant? One bite at a time.”

* I am strongly against eating elephants. It's a saying. Google it 😉

Hero photo by @keilahoetzel

DEV Community: Christian Kohler

Angular Modules Best Practices 2021

Table of Contents

TLDR;

Example Application

Folder Structure

Use Angular Modules

Aspects

Strategies

How to decide what pattern to use?

Summary

Angular Change Detection Infographic

Angular Change Detection Infographic

Bundling Angular Modules

Bundling Angular Modules

Table of Contents

Tldr;

Note

Why do we need NgModules?

Other use cases

How to make a component available in a NgModule

Directly declare it

Import it from a different NgModule

1. Export the component to make it available for other components (think of it as public components)

2. Import the NgModule (e.g. "MyComponents") in "MyModule"

How modules are bundled

Component not declared

Most simple example

Separate EagerModule

Lazy loaded Modules

Shared modules

Noteworthy

Best practices

Summary

Papertown - GitHub Actions Submission

My Workflow

Submission Category:

Yaml File or Link to Code

ChristianKohler / papertown-github-action

Github Action for https://github.com/ChristianKohler/papertown

Papertown Github Action

Inputs

devto-api-key (required)

root-folder

image-root-url-github

dry-run

Example usage

Additional Resources / Info

How to avoid Prop-drilling in Angular

How to avoid Prop-drilling in Angular

Table of Contents

Tldr;

Should I be interested?

The „how“ and the „where“

What is Prop Drilling?

The problem of Prop Drilling by example

Simple List

Add a Filter

Add a TodoItem Component

Add a ToggleTodo Component

How to avoid prop drilling

Angular's hierarchical dependency injection system

Todo App with context-like state

Global state vs. Context-like state vs. Prop drilling

Summary

It’s a trap - The biggest pitfall of String.prototype.replace()

tl;dr

What we want to achieve

Naive approach (the pitfall 🚨)

Working approach (with regex)

New approach (with replaceAll)

When to use which approach?

Rule I

Rule II

Summary

Resources

Lessons learned from building a Grid List in React Native

tl;dr

Goal

Flatlist