Alex Rickabaugh clarified that tests without TestBed are not recommended. Matthieu Riegler talked about SSR, hydration, and things to come.

Testing without TestBed?

As discussed in former episodes, the inject function has advantages over the constructor-based dependency injection. The main drawback with the inject function, has been writing tests without the Test

With a constructor-based DI, we just call new and provide the mocks to the constructor. That doesn't work with inject, and Angular forces us to use TestBed.

Alex Rickabaugh, the lead of the Angular framework, now has a clear answer regarding testing. We should go via TestBed. Only with TestBed can the Angular team ensure that tests behave like the application.

If you need to write tests without the TestBed, use an abstraction layer to decouple your code from Angular's DI. The argument that tests are too slow doesn't apply anymore is running on Ivy. That has been the case since Angular 9.

https://github.com/angular/angular/issues/54438

SSR & Hydration

Matthieu Riegler was a guest on the Angular Air podcast and discussed hydration and server-side rendering (SSR).

He showed all the necessary things we must be aware of: how to opt-out specific components from hydration, what kind of code cannot be on the service, and issues with asynchronous functions and integration into the DevTools.

He also discussed the future plan.

For example, we might be able to run defer on the server in v18. That would be similar to Server Components in React, where the JavaScript for some components doesn't have to run on the client.

Another upcoming feature might be partial hydration, where the browser only downloads JavaScript chunks when they are required. Last but not least, SSR also has to be ready for zoneless applications.

Nx and "crystalizing" Angular

We have to accept a slight divergence when using Nx, an alternative to the Angular CLI. For example, the angular.json file is divided into multiple project.json files.

Version 18 of Nx brought Project Crystal, which allowed Nx to infer its task via the existing configuration files. Lars Nielsen started a discussion on GitHub about whether Nx wants to "crystalize" Angular. As a consequence, it would bring back the angular.json, improving Nx's compatibility with the Angular CLI.

https://github.com/nrwl/nx/discussions/21994

RxJs 8 and the future of the Observable

Also happening on GitHub: A discussion about the shape of RxJs 8. With Observable becoming a standard and natively supported by the browser the obvious question is on which Observable RxJs should be based on.

https://github.com/ReactiveX/rxjs/discussions/7447