Ng-News Special Summer Edition

This is a special summer edition of ng-news, which covers the Angular community from late July to the end of August.

Angular Q&A Session July

In the Angular Q&A session for July, regular hosts Mark Thompson and Jeremy Elbourn were joined by Jessica Janiuk, another member of the Angular team. This session covered a range of topics, with Jessica providing updates on the ongoing work related to Server-Side Rendering (SSR) and hydration in Angular.

At around the 37:45 mark of the session, Jeremy Elbourn revealed some behind-the-scenes work known as the “data story” for Signals. This work is believed to be closely connected to the development of a future, or perhaps alternative, version of Angular’s HttpClient, which may eventually eliminate the dependency on RxJs.

Ryan Carniato: Derivations in Reactivity

Exploring Reactivity: Ryan Carniato’s Insights on Signals
In a related context, Ryan Carniato, the creator of SolidJS—a framework that has significantly popularized the use of Signals—recently published a three-part article series titled “Derivations in Reactivity” on dev.to. This series delves into the intricacies of reactivity and the role of Signals within it.

In the first part of the series, Carniato discusses the concepts of “push” and “pull” mechanisms, and how their combination is implemented in Signals. He highlights that using derivations, or computed values, in Angular ensures that tasks are only executed once, in contrast to other approaches that might trigger multiple executions.

The second part of the series addresses the challenges associated with scheduling—whether to execute derivations eagerly or lazily—and the impact this choice has on performance, particularly with regard to garbage collection.

The third and final part of the series looks to the future, exploring the potential of asynchronous Signals. Currently, when a Signal holds an asynchronous value, it must be typed as either undefined or the eventual value type. However, Carniato suggests that future frameworks could handle these scenarios more seamlessly, managing the undefined state until the value is resolved. This could also offer insights into the direction of the Signal/HttpClient solution that Jeremy mentioned during the Q&A session.

Superpower with Directives and Dependency Injection

Armen Vardanyan, author of Modern Angular, has published a lengthy article on Angular Space, where he delves into Angular’s directives and their potential when combined with dependency injection. Angular Space is a website with free membership that publishes articles, and where content is reviewed by community members.

Armen’s article, titled “Superpower with Directives and Dependency Injection,” isn’t just theoretical—in fact, it’s quite the opposite. He begins with the basics of directives and then progresses to more advanced topics, all while using real-world examples that you’ll probably want to use in your own applications.

For example, Armen introduces a universal evaluator for password strength, which allows you to apply different algorithms and activate it with just a directive. He also presents a click-away directive, which triggers a specific action when users click anywhere outside a designated element. Additionally, there’s a permission directive that only renders elements if the users have the required permissions. These practical examples demonstrate the power of Angular’s directives and make Armen’s article a valuable resource for developers looking to enhance their applications.

Angular Vienna Meetup: Partytown, Code PushUp & more

The Angular Vienna meetup took place recently, with several insightful presentations from speakers like Vojtech Mašek or Robert Maier-Silldorff.

Among the highlights was Matec Chalk’s introduction of Code PushUp, a quality tool similar to SonarQube but specifically designed for frontend applications. By default, Code PushUp analyzes projects in four categories: ESLint, Code Coverage, Security, and Performance via Lighthouse. In essence, it helps developers measure and eliminate technical debt.

Another notable talk was given by Julian Jandl, who provided an in-depth look at Partytown. This tool shifts heavy scripts from the main thread to a web worker, allowing them to run in parallel without blocking the application.

What sets Partytown apart is its ability to bypass the typical constraints of a worker thread, enabling scripts to access the DOM and send requests.

Julian’s talk stemmed from his experience with a real-world project at bwin.com, a large betting platform that had to overcome challenges with third-party libraries like Google Analytics and Tag Manager. He elaborated on how they applied Partytown to improve performance on a site with millions of users, and the specific hurdles they faced in doing so.

Angular Graz Meetup: Zoneless, State and Future of Angular, etc.

The recordings from another Austrian Angular meetup, this time in Graz, have been published. The event featured talks from notable speakers like Manfred Steyer, Dariusz Kalbarczyk, and Fabian Gosebrink, along with presentations by two members of the Angular team.

Emma Twersky delivered a comprehensive overview of the current state of Angular and its future roadmap. She highlighted key areas of ongoing work and research, including topics like streaming and selectorless components—an approach that could potentially eliminate the need for importing components, making the development process even smoother.

Matthieu Riegler gave a talk on the implications of going zoneless in Angular. Traditionally, Angular has relied on zone.js to track asynchronous tasks and determine when they have completed, which is particularly important for server-side rendering. Without this, the server wouldn’t know when the application is fully ready to be sent to the browser.

Matthieu also introduced new experimental services, such as the ExperimentalPendingTasks service, which Angular services like the HttpClient are beginning to use internally. This service could become a valuable tool for developers to track asynchronous tasks originating from their own application or library code.

Angular 18.2

Angular 18.2 has been released, and the standout features this time are the new migration scripts. One of these scripts will automatically replace all your constructors that use dependency injection with the inject function. While constructor-based DI is still supported, this change might suggest the direction the Angular team is considering for the future.

Another migration script focuses on lazy-loaded routes for standalone components. If your route configuration utilizes the loadComponent property, you can now automatically enable lazy loading for these routes.

For testing, there’s a new option related to the use of fakeAsync. Previously, developers had to ensure that no asynchronous tasks were left when a test concluded. Now, Angular can automatically flush and end those tasks, simplifying the testing process.

The official Angular blog post also mentioned a different feature: the isolatedModules option in TypeScript. This setting has the potential to improve build times when using the ApplicationBuilder. For more information, you can refer to the official blog post.

Angular Q&A Session August: Testing Guideline

The August Q&A session had a unique tone, as it quickly became apparent that Jeremy was on a mission—to provide the ultimate testing guideline.

According to Jeremy, testing should strive to replicate the end user’s experience as closely as possible. This means testing components via their templates and, when available, leveraging existing testing harnesses that require you to interact with components as a real user would.

Regarding dependencies, particularly services, Jeremy advised against replacing them with test doubles if you can avoid it—using the original service is often best. If you do need to replace a service, consider creating a fake. A fake allows you to maintain control over the test double while providing a meaningful implementation.

Mocks are also an option, but Jeremy warned that they should be used with caution. The risk with mocks is that they often lead to simply verifying that a function was called, without testing the broader functionality.