Check out your Company Bowl for anonymous work chats.
All good things must come to an end! We're wrapping up our series on Angular Development this week with a focus on testing, specifically addressing some of the trickier, complex testing scenarios that arise with component interaction and how to test the situation accurately. We hope you've found our 11-part series to be a helpful resource in advancing your Angular know-how. Should you want to revisit the topics, make sure to bookmark this page for easy reference: http://ow.ly/i9gy50D5Jo0
The most appropriate summary of the RouteReuseStrategy is this: with great power comes great responsibility. RouteReuseStrategy is an extremely powerful tool to customize Angular and greatly improve the user experience of your application – however, there are various pitfalls to consider to safely implement its usage in a way that prevents some mysterious and difficult to identify bugs. Learn all about it in the latest blog post of our series on Angular Development.
Say goodbye to large components that encompass the entire form. Learn a new approach that can make it easier to build reusable, shareable form sections.
The ControlValueAccessor can provide much more than just custom inputs – it can serve as a gateway to better form organization and reusability within an application. Learn more about the well-known and lesser-known uses of this interface in our latest blog post.
Angular’s development team strongly encourages following the single responsibility principle when creating components and classes. When components grow too large, we should turn to services to help separate complex functionality to improve the readability, complexity, and testability of an application. However, there are times when the singleton nature of services can provide unexpected results. In the latest post of our series on Angular Development, we take a deep dive into how to control the scope of Angular providers and provide the desired functionality within an application.
Most Angular components are created by adding a reference directly into a template. However, there are times where the type of component won't be known ahead of time and will need to be dynamically created. In part six of our series on Angular Development, we cover the extra steps and precautions you'll need to know to open the door to this advanced functionality within your applications.
Input, Output, and services are often all that is needed to communicate between components in Angular. However, there are instances where these methods do not provide the control and flexibility needed. The solution lies in the use of ViewChild / ViewChildren and ContentChild / ContentChildren decorators. Learn more about it in the latest post of our series on Angular development.
Most tutorials and training stick with the simple approach of binding data to components through an input. This is a simple to implement and effective way to pass data to a child component. However, when real-life requirements arise such as adding links, images, or other styling, this approach quickly hits limitations. Part four of our series on Angular Development aims to show the flexibility and power that comes from content projection, opposed to (or often in conjunction with) component inputs.
One of the most common patterns seen in Angular components is to subscribe to an Observable and display the resulting data in a component. Unfortunately, this process can easily add bloated boilerplate code. The async pipe is a powerful tool to keep that to a minimum. In part three of our Angular series, we dive into the general use and some extended functionality of the ngIf directive in conjunction with the async pipe to quickly and easily create effective display components.
Observables are streams of data used to inform various parts of the application of a change that may be relevant to that functionality. In part two of our Angular Development series, we discuss some best practices when it comes to Observables, some opinionated ideas, and a few potential pitfalls to watch out for.
