The most popular Angular Community Questions (October 2020)
Command Palette
Search for a command to run...
Search for a command to run...
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.
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:
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).
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:
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
ng update to get the new version and have access to the new features. This is called a feature drop.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.
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.
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!
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!
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.
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).
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.
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.
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.
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!
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.
Minko tells us about a lot of exciting features to expect in the upcoming version:
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
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