Alex Rickabaugh has made it clear that skipping TestBed in tests is not the recommended path. Meanwhile, Matthieu Riegler covered SSR, hydration, and what lies ahead for both.
Is TestBed-free Testing a Good Idea?
In earlier episodes, we highlighted how the inject function improves upon constructor-based dependency injection. However, its main downside has been the difficulty of writing tests without relying on TestBed.
With constructor-based DI, mocking is straightforward: you simply call new and pass the mocks into the constructor. That approach breaks down with inject, forcing developers into TestBed.
Alex Rickabaugh, who leads the Angular framework team, has now given a definitive answer on testing strategy: stick with TestBed. Only through TestBed can the Angular team guarantee that test behavior matches what happens in the actual application.
If you find yourself needing to write tests without TestBed, the advice is to introduce an abstraction layer to isolate your code from Angular's DI. The old complaint about tests being too slow no longer holds water, as Ivy has been powering Angular since version 9.
https://github.com/angular/angular/issues/54438
Server-Side Rendering and Hydration
Matthieu Riegler joined the Angular Air podcast to talk about hydration and server-side rendering (SSR).
He walked through every important consideration: how to selectively exclude components from hydration, which code patterns are off-limits on the server, and the complications that arise with asynchronous functions and DevTools integration.
He also outlined what the team has planned next.
One possibility for v18 is running defer on the server. This would mirror the concept of Server Components in React, where certain components don't need to ship their JavaScript to the client.
Partial hydration is another feature on the horizon, where the browser fetches JavaScript chunks only on demand. On top of that, SSR will need to accommodate applications that don't rely on zones.
Nx and "Crystallizing" Angular
Choosing Nx over the Angular CLI means accepting a few differences. A notable one is that the single angular.json file gets split into separate project.json files.
Nx 18 introduced Project Crystal, which lets Nx infer its build tasks from existing configuration files. Lars Nielsen sparked a GitHub discussion asking whether Nx should "crystallize" Angular. The idea is that doing so would reintroduce angular.json and bring Nx's compatibility with the Angular CLI closer to parity.
https://github.com/nrwl/nx/discussions/21994
RxJs 8 and the Direction of the Observable
There's another discussion taking place on GitHub about the direction of RxJs 8. Given that Observable is becoming standard and natively supported in browsers, a key question has emerged: which Observable should form the foundation for RxJs?