The most popular Angular Community Questions (October 2020)

In the first Angular Discord Q&A, the Angular team member Minko Gechev answered the most popular questions from the community. Read on to find out what questions were asked and how Minko answered!

You have more questions about Angular, want to interact with the community or have questions for the next Q&A? Join the Angular Discord.

A huge thanks to the moderators delasteve, @beeman and Alex Okrushko for making this happen. You can find the full recording on youtube.

All Questions

1. What role does RxJS play in Angular? With many people using observables more and more, would deeper integration be a possibility (for example @Input() as Observable)?
2. Before Ivy one of the Angular's motto was "never touch the DOM", because we always had to use the platform abstraction (for example through Renderer2), but since Ivy that seems to have changed. What is the current recommendation?
3. Where do you see Angular in 2 years? What will the main difference be for developers?
4. What is the status and priority of Angular Elements? How does Ivy affect Angular Elements?
5. There is currently no type safety when using reactive forms. Can we expect to see type safety in reactive forms?
6. What will be the future of Angular Material? Are any new features coming to Material?
7. The ::ng-deep pseudo-class is helpful to create stylistic consistency with certain component composition patterns but it is deprecated. How long will ::ng-deep be supported and what patterns should be used to phase out ::ng-deep?
8. When will Bazel integration with Angular (possibly having it built into the CLI) mature out of Labs? How do you see it compared to what Nx is providing these days?
9. What about lazy loading components without routing? Is it officially supported?
10. Was ViewEncapsulation.Shadow DOM supposed to become the default for Angular components as browsers matured? What was/is the vision for this feature?
11. Could you explain a bit how the Angular roadmap is developed? It would be interesting to learn a bit about who the most important stakeholders are (Community vs Google) and how prioritization is done.
12. The roadmap mentions dev tooling. What is the state of development and what features can we expect?
13. I have multiple teams working on their own Angular projects. How or when do you imagine building and deploying multiple Angular apps and having them effectively run together on a single page? Would this be module federation?
14. What should we look out for in Angular 11?
15. In regards to sharing data between parent and child components, can you elaborate on the benefits of using ViewChild vs services and vice-versa? Are there any specific cases when you SHOULD use one over the other or is it just developer preference?
16. What do you think about the current state of the JS ecosystem, popular frameworks and how does Angular improve the user experience compared to other frameworks?

What role does RxJS play in Angular? With many people using observables more and more, would deeper integration be a possibility (for example @Input() as Observable)?

There are some challenges with having a hard dependency on Observables inside @angular/core. While the hard dependency currently exists, it could be relaxed in the future.

We are very cautious on introuducing an even harder dependency on RxJS

— Minko Gechev

Here are the reasons for not integrating RxJS that Minko lists:

1. Bundle size: RxJS and operators add to the bundle size. For people that do not want to use RxJS features, this is an extra cost without benefits.
2. Learning Curve: A lot of users are excited about RxJS. These users are mostly "power users". However, for beginners that are new to Angular, Observables are yet another thing that they have to learn. Learning RxJS would be an extra barrier that beginners would have to overcome to be productive.
3. Limitations on the way that components can be loaded: The Angular team is looking into out of order component loading with progressive hydration. Observables would block the team from implementing this. Specifically, the framework would need to be aware of subscribers ahead of time to know in which order components can be loaded.

This doesn't mean that @Inputs as Observables are not possible. It would be possible to allow both the traditional way as well as @Input as Observables. Supporting two ways of doing things however has additional cost as well.

Beeman brings up an additional point: would there be a difference if Observables were to become a web standard and shipped as part of the browser (like Promises do)? Minko replies that if Observables were part of the browser, this would help with the bundle size. It would however not help with the other two points - the learning curve and adding limitations on the future development of Angular.

Given these difficulties, Minko provides some information on the timeline: we should not expect a definite answer to the topic of Inputs as Observables in the next couple of months (or maybe even longer).

2. Before Ivy one of the Angular's motto was "never touch the DOM", because we always had to use the platform abstraction (for example through Renderer2), but since Ivy that seems to have changed. What is the current recommendation?

Minko explains that there has been a mind shift from previous recommendations.

If you are doing applications for the web [...] it's absolutely fine touching the dom

— Minko Gechev

Furthermore, the recommendation to not touch the dom is not so much related to Ivy, but rather to the platform that you want to run your Angular application on. The new recommendations are:

• If you run your application only on the web you can modify the DOM directly. There are some caveats: if you want to query the structure of your components use Angular features such as @ViewChild. This is because Angular has an internal understanding of what currently exists in the component structure and your templates and what does not. If you need to write to the DOM, feel free to do that.
• If you plan to write a cross-platform application that does not run on the web, you need to be more careful. For example, if you develop your app using NativeScript (a way to write native apps for Android and iOS using Angular) you should not use DOM APIs since there is no DOM to modify.

3. Where do you see Angular in 2 years? What will the main difference be for developers?

A few points are mentioned by Minko on what developers can expect from Angular:

We see individual releases of Angular itself as feature drops

— Minko Gechev

• You’re getting new features that are going to make you more productive, improve the compiler and improve your development experience - without having to deal with breaking changes. Just run ng update to get the new version and have access to the new features. This is called a feature drop.
• No Rewrites: there are no plans for major rewrites as we saw during the transition from Angular.JS to Angular. The goal is to have Angular as an evergreen framework, where you can do upgrades as part of your normal work and CI. You will be able to get faster applications with each ng update. The Angular Team will keep breaking changes to a minimum. However, breaking changes could be required if the underlying platform changes and forces the team to rethink some architectural decisions.
• There are larger efforts such as Zone-less and Angular Devtools that will have a big impact. There are also efforts to make it easier for beginners to get started with the framework.
• Stability: Beeman asks a question comparing asking if we can expect a situation as with React (for example moving class-based to function based components). Minko replies that Angular aims to have a single way of doing things to make it easy to switch from one project to another.

4. What is the status and priority of Angular Elements? How does Ivy affect Angular Elements?

Angular Elements work and are widely adopted by the community. The Angular team maintains and will continue to maintain Web Components.There are two different asks that the community has: compatibility with web components and build system and distribution.

Angular Elements works and it's going to continue working, like we're not planning to change anything around that

— Minko Gechev

Compatibility with Web Components
There are some differences between Web Components and Angular for similar functionality. For example, the Web Component Shadow DOM slots behave differently from content projection and default content in ng-content as implemented in Angular. The Angular team is actively working on improving compatibility with web standards.

Build system and distribution
A large concern with using Angular Elements is the size of the bundle of components that are distributed and used in different apps, which could be for example React apps. Optimizing the build system and distribution of Angular Elements to solve this problem is difficult. Elements are very dynamic and flexible systems. To make the bundle small, you need to know ahead of time which parts of Angular the Components on a page are going to use. This means you give up some flexibility - it is no longer possible to dynamically assemble the UI using different elements.

One option for distribution could be to have a single, full Angular UMD bundle that you add to the page, which all your different Angular Elements can then consume. A disadvantage is, that the bundle which you need to add is fairly large. This is because Angular is written to be tree-shaken, which Elements can’t do because of the flexibility that is required.

Around building & distribution the Angular team has nothing planned on the roadmap and likely there won’t be improvements. There is no trivial solution that can be shipped and allow the team to move forward.

Generally, you can use Angular Elements if you have a use case that requires it. Minko mentions an example where a team uses Angular Elements to distribute components to their customers. The customers use those components across applications that use WordPress, React and other technologies. Since they are writing applications for internal use, bundle size is not a large concern for them.

5. There is currently no type safety when using reactive forms. Can we expect to see type safety in reactive forms?

As Minko outlines, this is something that the Angular team really wants to do and is actively working on. There are a few challenges that are still work in progress: Firstly, adding type safety to forms includes some breaking changes, so a clear path to updating your applications is needed.

There are some technical challenges which are going to have some breaking implications on top of reactive forms so we need to plan them better

— Minko Gechev

Another challenge is adding typings to dynamic forms. When you add your form controls dynamically, the typing can not be inferred ahead of time. The Angular team is currently considering different approaches and solutions to these challenges.

Angular Team Member Alex Rickabaugh might write a post detailing the technical challenges and possible solutions - stay tuned!

6. What will be the future of Angular Material? Are any new features coming to Material?

The Angular team is working on migrating Angular Material to MDC Web, which is the official implementation of Material Design by the Material Design team. Angular will preserve the public API of the current implementation so that the change is easy for developers. The benefits of this change are improved accessibility and close compatibility with the Material Design specification. Mirko estimates that out of all the time that is spent on Angular Material, about 50% is spent on the migration to MDC and another 50% on triaging issues in the material repository to see what the community needs (e.g. date picker).

We're going to take our material components, preserve the exact same public API and migrate them to MDC-Web

— Minko Gechev

Minko also touches on the challenges that the Angular Material Team is currently facing: since the internal DOM structure of components changes, the migration to MDC Web is most likely going to break unit and End-to-end tests. Even though the internal structure is considered part of the private API, the Angular Team nevertheless wants to make it easy for developers to fix their tests after the migration. For this purpose they will provide test and component harnesses that you can use in your tests. This approach is similar to how Page Objects work in End-to-end tests.

Alex Okrushko adds that the Firebase Console uses Angular Material, and that the Firebase Console is actually part of the test suite for Angular Material. This helps the Angular Material team to do changes with high confidence, as the Firebase Console has a lot of testing, including screenshot comparison and visual tests - with a codebase of close to 1 million lines of code!

7. The ::ng-deep pseudo-class is helpful to create stylistic consistency with certain component composition patterns but it is deprecated. How long will ::ng-deep be supported and what patterns should be used to phase out ::ng-deep?

Minko explains that there is no better solution to the deprecated ::ng-deep yet. This is not only an Angular problem - the matching functionality (/deep/) was also removed from Shadow DOM. However up until now no better approach has been added to the spec. The Angular team will provide a migration path from ::ng-deep when they find a better way of doing things (while collaborating with web standard groups) since ::ng-deep is widely used both inside and outside of Google.

We're not planning to remove it anytime soon. Actually I would say that it wasn't right to deprecate it given that there is clearly no solution for this

— Minko Gechev

The takeaway is that while ::ng-deep is deprecated you can still safely use it inside of your app.

8. When will Bazel integration with Angular (possibly having it built into the CLI) mature out of Labs? How do you see it compared to what Nx is providing these days?

This is a big topic which Minko says he could talk about for 2 hours to cover it! In short, the Angular team was experimenting and explored moving the Angular CLI from to use Bazel as an underlying build system. Bazel works well, especially on large codebases with lots of different technologies.

There are however some drawbacks with using Bazel: you need to configure your build graph, which are the dependencies of your project and much more. This process of writing Buildfiles is usually done manually. While tooling can generate Buildfiles automatically, generating Buildfiles is tricky, especially with dynamic languages. The goal was originally to hide the build files from the user so that you can use the CLI as you do now - but with Bazel under the hood. The issue is that it is not always possible to generate this build graph. While automatic generation mostly works, when it does not work it is extremely difficult to figure out what’s going on.

This is going to work probably 90% of the time and the other 10% of the time you will have no idea what's going on

— Minko Gechev

The tooling also doesn't always generate the most optimal build graph, negating some of the advantages. The Angular team concluded that the integration of Bazel with the Angular CLI is not the right way to go and the Angular team is no longer pursuing the integration.

Bazel still makes sense for many large applications. Bazel has graduated from Angular Labs and you can use it today. There area number of larger projects and enterprises that are using Bazel today to build their Angular apps.

[Nx is a] much more ergonomic approach that you could take advantage of

— Minko Gechev

Nx can be a good solution to get incremental builds without adding extra configuration overhead. At the same time, you’re not getting the same strong guarantees that Bazel offers. Sometimes the encapsulation of the builds does not work 100% of the time. This could still be fine for the majority of the cases. Nx still offers a much more ergonomic approach that you can take advantage of. There are plugins for Nx for different languages such as Go as well. Minko recommends that if you hit limits with your projects and want to try incremental builds try Nx and go to Bazel from there (if that makes sense for you).

9. What about lazy loading components without routing? Is it officially supported?

Lazy loading components without routing is possible, officially supported and you should feel free to use it. Minko even recommends lazy loading components outside of lazy routes, since it can sometimes be the only way to reduce your initial bundle size.

We're going to come up with a more ergonomic approach in the future

— Minko Gechev

In the long run, the Angular Team wants to offer a better API for lazy-loading components without the router. This requires removing the so-called “ngfactories”, that were relevant before Ivy, but are not relevant anymore. Ngfactories will be deprecated which will pave the way to a more usable API.

10. Was ViewEncapsulation.Shadow DOM supposed to become the default for Angular components as browsers matured? What was/is the vision for this feature?

The vision for Angular is to heavily use web standards in the long run, which would reduce the bundle size. There is much work to be done to make sure that ViewEncapsulation.Emulated works in the same way as Shadow DOM and that Angular has compatibility with web standards with the polyfills that Angular has created.

11. Could you explain a bit how the Angular roadmap is developed? It would be interesting to learn a bit about who the most important stakeholders are (Community vs Google) and how prioritization is done.

Minko tells us that the reason Google likes Angular as much as it does is that there are only very few differences between how Angular is used inside and outside of Google. This makes the life of Google easier because people already know the technologies that are used inside of Google when they join. The Angular team wants to make sure that there is as much overlap as possible between how Angular is used inside and outside of Google.

There are some small differences, which concentrate mainly around the build system. Outside of Google Webpack is generally used, whereas inside of Google different build tools are used. There is only one Google-specific item on the Angular roadmap, which is the integration of Angular with the Google internal serving stack.

The harder task for the Angular team is to prioritize feature requests that are coming in - no matter from where they are coming. For example the Angular Language Service has 1.7 million downloads, so there are a lot of requests, feedback and pull requests coming in even from this smaller component. Minko explains that these are mostly from experienced developers that know very well what they are doing.

Making sure that we're able to look from the perspective of a beginner developer is also very important and that's probably the hardest part

— Minko Gechev

To prioritize, the Angular team looks at feature requests that are coming in and how often they have been requested. Each team member comes up with proposals that are discussed and ranked in a list. The team also considers technical debt that needs to be dealt with. Minko explains that when ranking each proposal, it is both important and difficult to see things from the perspective of a developer who is new to Angular - since most members of the Angular team have been working in the industry for a long time. These features are considered controversial. For example strict mode, which enables aggressive tree shaking and advanced optimizations, also makes types more strict and thus makes Angular harder to learn.

For controversial features the Angular team has two approaches: RFCs, which allow for collecting good feedback but have the downside of being biased towards advanced users that read the feature tracker. Secondly, actively increasing visibility of features by sending out features, publishing on the Angular blog and talking to Angular trainers that have close contact with new developers.

12. The roadmap mentions dev tooling. What is the state of development and what features can we expect?

We're going to think about the right way to make it available for everyone not only for folks who are testing it

— Minko Gechev

There are some prototypes of development tools that help developers understand the component structure in an app. The new tools also allow you to profile the performance and find out how long your app spends inside of change detection. The Angular team is working on integrating these development tools into the Angular public API to guarantee stability in the long run. Once this is done these tools will be made available to everyone!

13. I have multiple teams working on their own Angular projects. How or when do you imagine building and deploying multiple Angular apps and having them effectively run together on a single page? Would this be module federation?

We're looking into this and probably the module federation is going to be the right way to go

— Minko Gechev

As part of Angular 11 there will be an opt-in preview of Webpack 5, which supports module federation. There are no design documents yet but it is something that the Angular team is looking at since module federation support is frequently requested by developers.

14. What should we look out for in Angular 11?

Minko tells us about a lot of exciting features to expect in the upcoming version:

1. Easier HMR (hot module reloading) support will be released. This makes it quicker to see code changes in your browser after changing. While HMR is currently supported already, it will be much easier than before. You will be able to enable HMR by using a simple flag.
2. The Angular team has worked closely with James Henry (ESLint team) and the community to improve ESLint support and provide a migration path from TSLint to ESLint.
3. There will be an opt-in preview for the Ivy Language Service - this will mean better type checking and autocomplete in your templates!
4. Ngcc - the Angular compiler - will be 4x faster in Angular 11. This means you spend less time waiting for builds and rebuilds to complete. When profiling the Angular compiler, Angular contributor Joost had to make the Typescript compiler faster to improve Ngcc! This change will land in Typescript 4.1 - so when Angular supports Typescript 4.1 you’ll automatically get faster builds.

15. In regards to sharing data between parent and child components, can you elaborate on the benefits of using ViewChild vs services and vice-versa? Are there any specific cases when you SHOULD use one over the other or is it just developer preference?

Minko explains that this is mostly a state management topic - on which Alex Okrushko has just done an awesome talk! If you want to learn more about state management and how to pass state through your component structure, watch it: https://www.youtube.com/watch?v=Azus3_CEkpw

16. What do you think about the current state of the JS ecosystem, popular frameworks and how does Angular improve the user experience compared to other frameworks?

When i'm thinking about the the biggest advantages and strengths of Angular i usually think about four different ones and some of them are more unique to compared to other frameworks

— Minko Gechev

1. Angular is opinionated. This means that best practices are baked into the framework and tooling such as the Angular CLI. When generating projects, the Angular CLI uses a baked-in style guide which means that most Angular applications you look at will have a similar structure. You start with typescript from the beginning, which gives you many advantages. You are encouraged to use dependency injection which is also considered a best practice.
2. Angular scales very well - you can go from a hello world application to applications with millions of lines of code (such as the Firebase Console) very well. Of course Angular can not provide everything for you - you still have to think about state management and how to architect your app when you reach millions of lines of code, however the build system and tooling to this exists and is proven to work at scale.
3. Angular is evergreen: extensive test coverage makes sure that there are no breakages introduced by changes and pull requests to Angular. Inside of the Google monorepo there are over 2600 Angular applications. Each of these applications uses different functionality which is covered by the application's tests. This allows Angular to provide automatic migrations that update your code to the newest versions and they were tested on all of those projects. This way everyone can automatically stay at the newest version of the framework without manual work.
4. The community: there are many community projects such as state management frameworks, components and tooling.