Minko Gechev provided a preview of what lies ahead for Angular. Signals are now stable and prepared for version 17. Jeremy Elbourn touched on functional components, and Brandon Roberts subsequently shared a working prototype.
Minko Gechev (Angular Product Lead) on Angular's Direction
ng-Poland's organizer, Dariusz Kalbarczyk, sat down with Minko Gechev, the product lead for Angular, to discuss the roadmap for upcoming releases. Minko indicated that version 17 is set to deliver major improvements in Server-Side Rendering.
A new ApplicationBuilder will be introduced, leveraging esbuild and Vite to construct both the server and client bundles. Hydration is also slated for enhancement, with the team aiming for resumability beyond what version 17 will offer.
When it comes to hydration, Angular is working to align itself with the capabilities seen in leading frameworks such as Qwik.
Signals are expected to take center stage in the coming year. The rollout for the Signal-based component, initially targeted for version 17, has been postponed to allow the team more time for research and refinement.
Signals Reach Stability
The Signals primitive that first appeared in v16 is now on track to be declared stable in the 17 release. A notable change is the removal of the mutate method, which means that state updates will now be strictly immutable.
The reasoning behind these adjustments was spelled out in the official commit.
Jeremy Elbourn (Angular Tech Lead) Discusses Functional Components
The monthly Q&A session featured a significant closing segment. Jeremy Elbourn, the tech lead for Angular, shared his perspective on functional components.
The underlying issue is the current friction of importing a component in two separate places: once as a TypeScript import and again through the imports array of a Standalone Component or NgModule. Elbourn noted this is just a single example among several friction points that exist today.
The Angular team is studying how other frameworks handle this challenge. A functional component is a potential remedy, though it remains one of several proposals on the table. No definitive choice has been made, except that the dual-import problem must be addressed.
Brandon Roberts Presents a Functional Component Prototype
Shortly afterward, Brandon Roberts showcased a functional component prototype on X. The post drew roughly 90,000 views and sparked lively debate. The prototype itself certainly merits a closer look.
For easy reference, here's the source code in full:
// Copyright Brandon Roberts:
// https://x.com/brandontroberts/status/1710773567565050310
export const PostComponent = Component(() => {
const posts = signal<Post[]>([]);
const postsService = inject(PostsService);
onInit(() => {
postsService.getPosts().then((postList) => posts.set(postList));
});
afterNextRender(() => console.log('after next render'));
afterRender(() => console.log('after render'));
effect(() => console.log('posts', posts()));
return {
template: `
<div class="text-2xl">
@for (post of posts; track post.attributes.slug) {
<div class="py-4">
<a use:routerLink="[
'/blog', 'posts', post.attributes.slug]"
class="text-gray-600">
{{ post.attributes.title }}
</a>
</div>
<p class="text-sm">
{{ date(post.attributes.publishedDate,
'MMMM dd, yyyy') }}
</p>
}
</div>
`,
};
});
In Roberts' design, a factory function is used to generate the component. The functional component is split into two segments. The first is the setup phase, where dependencies are injected and event listeners are registered, among other tasks. The second segment is the template, which is returned as part of an object created by the wrapping function.