Episode: 23/40: Angular's Future, Functional Components, Stable Signals

Minko Gechev gave an overview of the upcoming features in Angular. Signals are stable and ready for version 17. Jeremy Elbourn discussed functional components and Brandon Roberts came up with a prototype.

Minko Gechev (Angular Product Lead) on Angular's Future

Dariusz Kalbarczyk, the organiser of ng-Poland, interviewed Minko Gechev, Angular product lead, about the upcoming Angular versions. According to Minko, version 17 will be very strong for Server-Side Rendering.

There will be an ApplicationBuilder, which runs on esbuild and Vite and is responsible for building the server and client parts.
Hydration will also improve, and Angular is target resumability beyond version 17.

In the field of hydration, Angular will catch up to top-notch frameworks like Qwik.

Signals will play a crucial role next year. The Signal-based component, once planned for 17, has been delayed. The Angular team wants to put more time into the research and implementation of it.

youtube.com

Stable Signals

The Signals library or primitive, which Angular released in v16, will become stable in 17. The Angular team removed the mutate method, though. So only immutable changes will be possible.

The official commit message provided a detailed explanation of these changes.

Jeremy Elbourn (Angular Tech Lead) on Functional Components

The monthly Q&A session took place. The most important part happened at the end. Jeremy Elbourn, Angular tech lead, gave a statement on functional components.

First comes the problem. It is currently not a good experience when we import a component two times. One is the TypeScript import, and the other is via the imports property in a Standalone Component or NgModule. Jeremy mentioned that this is just one example of many friction points.

The Angular team also looks at how other frameworks deal with that problem. A functional component might fix it, but it is one of many possible options. Nothing has been decided yet, except that there has to be a solution to the double-import issue.

youtube.com

Functional Component Prototype by Brandon Roberts

The day after, Brandon Roberts posted a prototype of a functional component on X. The post got around 90,000 and triggered some emotional discussions. The prototype is definitely worth a look.
For your convenience, here's the complete source code:

// 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 Brandon's prototype, we would have to use a factory function to create the component. The functional component would consist of two parts. The setup phase makes up the first part. It fetches services via the dependency injections, sets up event listeners, etc.
The second part is the template which the functions wraps into an object and returns.