Ok, let me explain, this might sound a bit weird, but bear with me.

We learned to use Big O to think about code. To understand how algorithms scale, where the limits are, what trade-offs we’re making.

Big O gave us a common language to talk about complexity without depending on hardware or implementation details.

But what popped into my head wasn’t code — it was the limit of interactions with LLMs:

when does delegation stop being reliable?

or

how complex can a prompt actually be?

The problem: Polymarket Bot #3… This Time It’ll Work…

For me, Polymarket is a modern playground for game theory.

Algorithms reacting to algorithms, under uncertainty, incomplete information, and a bunch of other variables.

An almost perfect environment to test ideas, fail fast, adjust hypotheses, and discover where human intuition breaks… of course, all of this in paper trading mode (got 5 euros to lend me? 😉).

All of that to say: this has been my favorite place for vibe coding lately… and where my questioning started.

An incremental flow, and a small mistake

Basically, I have my LLM of choice, which I use to discuss possible solutions for my bot’s problems. I bring ideas, we debate what works and what doesn’t. After deciding what we should implement, I generate a prompt with the full step-by-step of that implementation (no code) for my other agent, which reviews and implements the whole solution.

In one of those interactions, a task was implemented correctly, as usual.

The code ran. Nothing broke.

But during implementation, an environment variable was duplicated. Both represented the same thing. Only one was actually used.

The other one existed, wasn’t read by anyone, and caused no errors.

The problem wasn’t functional.
It was consistency.

This kind of issue easily slips through a superficial review, because everything “works” — notice the quotes.

And I know: “But Zuin, this error changes nothing.”
Yes, my dear reader, it changes nothing.

But in that massive vibe-coded feature, written at 9am at your kitchen counter, sipping a mocha made with a famous chocolate brand that rhymes with cat, did you really review all the code?

If that variable wasn’t used, what else there wasn’t actually implemented?

And that leads to an unavoidable question:

How do I evaluate how far I can delegate this problem?

And more importantly:

How do I reduce the probability of these errors showing up?

Benchmarks…

Benchmarks exist, including some very interesting ones about context length.

But let’s be honest: do you really know what each benchmark measures? How it’s built?

Today, you can ask an AI to:

• write code
• structure ideas
• explain concepts
• support decisions

So the real question becomes:

How much understanding of a given problem can it sustain, amplified by other implicit problems stacked on top of it?

Benchmarks isolate skills. Real problems stack decisions across different domains, in this case, for example: finance, machine learning, and software engineering.

The limit is not static

In many areas, an LLM can already provide information — often high quality.

But that limit is not fixed.

It changes across models and versions.
Sometimes it gets better.
Sometimes it gets worse.

It’s not a monotonic curve.

A prompt is a probability question

Given the same request, you can get different answers — some better, some worse.

The goal isn’t to eliminate variability. That’s not realistic.

The real question is:

How do I reduce the probability of failure, given a specific request?

Delegating to an AI is, inevitably, a probabilistic game (like everything in life?).

Maybe the right question isn’t:
“How much context fits in a single prompt?”

But rather:

How many decisions am I asking to be made at the same time? And how good is this model at each one of them?

A request rarely involves a single decision.

And those decisions don’t have the same difficulty.

Ok, but… where does Big O fit in?

Big O is an inspiration: a way of thinking about limits without focusing only on implementation.

Maybe we need something similar — not for code, but for the effective size of a problem, given a model, a version, and a context.

⚠️ WARNING: AI-generated, JUST AS AN EXAMPLE
This does not measure what the AI can do.
It measures the risk of delegating everything at once.

• O(1) — Atomic task
  A clear instruction, no implicit context.
  Example: “Refactor this function to remove duplication.”
  👉 AI executes directly, near-zero error.
• O(n) — Linear requirement complexity
  Each new requirement adds proportional effort.
  Example: “Refactor, add tests, follow the style guide, and document.”
  👉 Works well, as long as requirements are explicit.
• O(n²) — Interacting requirements
  Decisions in one requirement affect others.
  Example: performance × readability × backward compatibility
  👉 AI still helps, but starts needing checkpoints.
• O(2ⁿ) — Combinatorial Complexity
  Multiple domains with their own rules and subtle conflicts.
  Example: finance + ML + software engineering + compliance
  👉 Each wrong assumption creates a cascade of plausible errors.
• O(?) — Unknown complexity
  Poorly defined requirements, moving goals, or conflicting incentives.
  Example: “Do it the right way.”
  👉 Neither humans nor AI know where to start.

I know this is simplistic, but I wanted to leave it here as food for thought.

Continuing…

Vibe coding: here I make higher-level decisions, using an agent to implement a full ML algorithm — with logs, metrics, and everything else.

Professional life as a programmer: here, changes are more localized — specific functions, well-defined HTTP requests, isolated React components. Everything is much more controlled and reviewed. Even so, I feel the bar rising more and more, to the point where very little code is actually written by hand. (Seems like Dario was right.)

Vibe coding , which, in my view, could already be renamed, since the early days of the technology gave the term a bad reputation.

Wrapping up

Delegating to an LLM is not a binary decision (“I trust it” vs. “I don’t”).
It’s a granularity problem.

The more heterogeneous decisions I stack together, the higher the probability that something slips through.

The human role, then, is not to review everything line by line, but to decide where delegation should stop — or where the problem should be broken down until each part has an acceptable failure radius.

In the end, delegating to an AI is always a probabilistic game.
The question is: what takes more time, reviewing the prompt or reviewing the code it generates?

Even though I haven’t yet presented a rigorous mathematical formulation for this “Big-O-like” idea, I believe the core intuition is captured in this article; the next step is to investigate if and how this idea can be formalized.

By the way, my bot so far 😉

INFO - 📊 PAPER STATUS: Active: 0 | Balance: $54.80 | Tot PnL: $4.80 | W/L: 45/36 | Agent: Initializing

I don’t really need to explain how AI changed the world, right?

Developers and engineers now have a new way to ship fast, explore ideas, and rediscover the joy of coding. You know, before the AIs start deploying themselves 😉.

Now is the moment to build, that’s for fun, for learning, or for starting something serious.

The Landscape

Today, big companies are already reporting massive acceleration in their software development life cycles due to AI. For example, studies show that developers using AI code assistants complete tasks significantly faster — in some cases up to ~55% faster on average. Large organizations are restructuring entire workflows around AI pair-programming to reduce development time and time-to-market, and I’ve felt this shift myself in the way I work, how I prototype, and how fast I can move.

And beyond the organizational level, there’s the accessibility aspect: the time it takes to generate the first working version of something has dropped dramatically. Even if the quality isn’t perfect on the first try, it’s now easier to go from idea → prototype → iteration. The cost of simply trying has become much smaller. In my opinion, it’s even worth taking on some tech debt. This is where your software engineer instincts matter: knowing what is bearable and what is not.

From my perspective, that’s actually exciting. It’s incredible what a single developer can ship today with an AI pair.

But when is your product “good enough” to launch?

We can spin up new things faster than ever, but the question now is when to actually ship. And here’s the plot twist: the same AI tools that helped you get your MVP out in a weekend are helping everyone else ship their MVP just as fast. Speed is no longer the differentiator.

Shipping fast isn’t just about speed — it’s about deciding when something is “ready enough” to get real and compete with the wild new world.

I’ve been cooking something for a while now, and every time I’m in the shower, it starts with a simple “What if…”. Five minutes later I’m imagining a new interaction, a slick loading animation, or some small experience detail that I’m convinced would make it stand out.

But the more I’ve built, the more I’ve learned: shipping is about being practical.

In the age of AI, scoping your MVP has become even more important. The question is no longer “What else could I add?” — because the answer is always a lot. Instead, the real question becomes:

At what point does this start generating real value for someone?

Once you reach that point where the core loop works and someone can actually benefit from it, that’s the moment to ship. The differentiators, the animations, the personality… still important, and I believe you need to keep improving it, but… much of it can come later , guided by real users and real feedback 😉

So yes, I’m still learning, still improving, still fighting that voice that says “add just one more feature.”

And honestly, I think a lot of us are.

TL;DR: Momentum > perfection

Start a new NodeJS project with Typescript natively out-of-the-box, in minutes.

If you’re like me — a young software engineer (okay, maybe not that young!) who always doing some side project for fun — you’re going to love this!

Remember how setting up a compiler to convert TypeScript into JavaScript for NodeJS was such a pain (yea, maybe some minutes more, ok)? Well, not anymore! With native TypeScript support, things just got a whole lot easier.

Prerequisites

You’ll need Node.js version 22.7.0 or higher (we want enums, right?). To manage Node.js versions efficiently, use NVM:

• Download and install it from nvm GitHub.

Install and Use Node.js

nvm install 23.5.0
nvm use 23.5.0
## Now using node v23.5.0

Setting up your project

npm init
## Fill some stuff
## Let's install some package and their types
npm install express ## adds it to create a quick HTTP server
npm i --save-dev @types/express ## Add types

Add tsconfig.json

In the project root, create a tsconfig.json file:

{
    "compilerOptions": {
      "target": "ESNext",
      "allowImportingTsExtensions": true,
      "moduleResolution": "nodenext",
      "module": "NodeNext",
      "strict": true,
      "esModuleInterop": true,
      "skipLibCheck": true,
      "forceConsistentCasingInFileNames": true,
      "types": ["node"],
      "noEmit": true 
    }
  }

Why NodeNext and ESNext?
These configurations enable the latest features of Node.js and ES6. For example, the toSpliced function: MDN Documentation.

You can find more details in the TypeScript configuration references:

• Target
• Module Resolution.

Update Package.json

Update the type attribute to "module" and add the dev property to the scripts section:

{
  "name": "test",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "dev": "node --experimental-strip-types --experimental-transform-types --watch index.ts",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "type": "module",
  "license": "ISC",
  "description": "",
  "dependencies": {
    "express": "^4.21.2"
  },
  "devDependencies": {
    "@types/express": "^5.0.0"
  }
}

• --experimental-strip-types: Strips TypeScript annotations before execution.
• --experimental-transform-types: Supports TypeScript-specific syntax like enums and namespaces.

Add index.ts

Create an index.ts (or app.ts) file in the root directory:

import express from "express";

class TypescriptService {
  testVariable: string;

  constructor() {
    this.testVariable = "I'm definitely a string, since my birth";
  }

  getTestVariable() {
    return this.testVariable;
  }
}

const app = express();
const typescriptService = new TypescriptService();

app.get("/", async (req: express.Request, res: express.Response) => {
  res.send(typescriptService.getTestVariable());
});

app.listen(3001, () => {
  console.log("Server is running on port 3001");
});

Run the Project

npm run dev

Check to localhost:3001/ and BOOM 💥💥💥💥💥

Conclusion

What a journey it’s been from the beginning of NodeJs to where we are today! I truly see the power of starting projects with native TypeScript, and to be honest, I’ve been working with this setup, and it’s been running smoothly so far. I hope this setup works well for you too. That’s it for now, peace out!

While I was working on refactoring an application I came across the following scenario, a normal one in the life of Junior/Middle/Senior web developer.

Initially, it was an MVP intended for showcasing the refactor and certain architectural choices, I began with the desktop version. However, later on, we made the decision to also showcase the mobile version.

Well, as a Software Engineer, I typically rely on the Mobile First approach, and I think its important to mention here, that this should be the approach in normal situations.

Code reusability

Initially, my instinct was to introduce some breakpoints and incorporate additional TypeScript to enhance the functionality to the existing component. However, upon a reflection at the coffee break — one of the many joys of software development — I recognized that these are distinct components, and adding more code might unnecessarily complicate the component while breaking the rule of SoD (Separation of Duties).

The Solution

Create two components, each with its own implementation. It seemed straightforward enough. Using Tailwind breakpoints, I could easily dictate when each component should be displayed.

import { Outlet } from "react-router-dom";
import "./App.css";
import SideBar from "./components/SideBar/SideBar";
import TopNavigation from "./components/TopNavigation/TopNavigation";

function App() {

  return (
    <div className="flex flex-col md:flex-row ">
      <div className="md:fixed">
            <TopNavigation />
            <SideBar />
      </div>
      <div className="md:ml-[250px] w-full">
        <Outlet />
      </div>
    </div>
  );
}

export default App;

import { memo } from "react";
import { MenuIcon } from "../Icons/Menu";
import { UserIcon } from "../Icons/User";

interface TopNavigationProps {
  title?: string;
}

const TopNavigation = memo(({ title = "" }: TopNavigationProps) => {
  return (
    <div className="md:hidden flex w-full h-14 rounded-md border border-gray-700 items-center p-5">
      <MenuIcon className="w-8" />
      <div className="flex-1 text-center font-inter text-[22px] font-normal text-gray-100">
        {title}
      </div>
      <UserIcon className="w-8" />
    </div>
  );
});

export default TopNavigation;

Pretty Simple, right?

But there’s a catch with this approach. Consider this scenario: What if the user is currently using a mobile browser? Why would we want to download the desktop code?

Lazy loading to the rescue

Since react 16.6, we have the option to implement lazy loading for components, loading them only when necessary. It’s quite simple. In our case, we can download the components dynamically based in the the user viewport size.

Let’s create a custom hook called useIsMobile, a straightforward hook that returns a boolean indicating whether the viewport has changed below 768, which is the default MD breakpoint in Tailwind.

import { useState, useEffect } from "react";

export const useIsMobile = () => {
  const TAILWIND_MD_BREAKPONT = 768;
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handleWindowResize = () => setWidth(window.innerWidth);
    window.addEventListener("resize", handleWindowResize);
    return () => window.removeEventListener("resize", handleWindowResize);
  }, []);

  const isMobile = width < TAILWIND_MD_BREAKPONT;

  return isMobile;
};

An important note is that we are listening to the window resize event. So, every time this event occurs, we trigger the useEffect, which updates the value and triggers a re-render, and of course remove the event listener on the cleanup.

Now we should do a slight change to our App.tsx and voilà.

import { Outlet } from "react-router-dom";
import "./App.css";
import { Suspense, lazy, useEffect } from "react";
import { useIsMobile } from "./hooks/use-is-mobile";

const SideBar = lazy(() => import("./components/SideBar/SideBar"));

const TopNavigation = lazy(
  () => import("./components/TopNavigation/TopNavigation")
);

//For example let's create a loader component for the fallback of the suspense
//This should be a separeted component with your respective loader
const Loader = () => <>Loading...</>;

function App() {
  const isMobile = useIsMobile();
  
  return (
    <div className="flex flex-col md:flex-row ">
      <div className="md:fixed">
        {isMobile ? (
          <Suspense fallback={<Loader />}>
            <TopNavigation />
          </Suspense>
        ) : (
          <Suspense fallback={<Loader />}>
            <SideBar />
          </Suspense>
        )}
      </div>
      <div className="md:ml-[250px] w-full">
        <Outlet />
      </div>
    </div>
  );
}

export default App;

With the power of <Suspense/>, we can display a fallback while the children are loading. It's highly recommended to always implement this for providing a better UX. Additionally, you can choose to display any component you like as the fallback.

Conclusion

Adopting lazy loading and Suspense in React applications can greatly enhance user experience, improve code maintainability, and optimize performance. By strategically implementing these features, we can ensure faster load times, and better scalability.

While lazy loading and Suspense aren’t new concepts, their adoption can significantly impact the quality and efficiency of your applications. So, don’t hesitate to rethink your app’s architecture and incorporate these powerful tools into your development workflow.

Sometimes is better to separate some code then just adding complex logic to an exist component.

Thank you for joining me on this journey.

Until next time, happy coding! #Peace

Angular, Docker & Nginx: Build once, Deploy anywhere.

Github code: https://github.com/fbzz/angular-build-once-deploy-anywhere

In software development is quite common to have multiple environments, each with different configurations. Angular offers a built-in system for managing environment variables, allowing for the replacement of files during build time. However, this approach often requires creating separate builds for each environment, which can be time-consuming but to avoid this we have a pretty common pattern in the industry.

Build once, deploy anywhere…

So, let’s have an example where we have two environments, DEV and PROD, and for that, we want to have ONE build. For that, we use:

1. Angular — a front-end framework for building SPA applications.
2. Nginx — is a web server and reverse proxy server.
3. Docker — is a platform for developing, shipping, and running applications in containers, which are lightweight, portable, and self-sufficient environments.

1 - Angular

Let’s create three files, those files will handle different configurations based on the environment:

src\config

• app-config.dev.json — For Dev.
• app-config.prod.json — For Prod.

src\

• app-config.json — For local development, and to be replaced in the future.

//Example of an App config, it's a simple JSON.
{
  "API_URL": "LOCAL DEVELOPMENT",
}

Now, let’s include it in our bundle. In your angular.json file, within the build section, add our config folder to the assets.:

  "build": {
          "builder": "@angular-devkit/build-angular:browser-esbuild",
            ...
            "assets": [
              "src/favicon.ico",
              "src/assets",
              "src/app-config.json",
              "src/config", // HERE
            ],
            ...
}

Runningnpm run build we have our config folder at our dist

1.2 - In Angular, we can create services that are singletons, capable of retaining data throughout the application, making them reusable across the entire application.

import { Injectable } from '@angular/core';
import { firstValueFrom } from 'rxjs';
import { HttpClient, HttpBackend } from '@angular/common/http';

//Move this type to a shared folder
export interface AppConfig {
  API_URL: string;
}

@Injectable({
  providedIn: 'root',
})


export class ConfigService {
  //We create the configuration with default values in case anything fails
  private configuration: AppConfig = {
    API_URL: '/api',
  };

  private http: HttpClient;
  constructor(private readonly httpHandler: HttpBackend) {
    this.http = new HttpClient(this.httpHandler);
  }

  //This function will get the current config for the environment
  setConfig(): Promise<void | AppConfig> {
    return firstValueFrom(this.http.get<AppConfig>('./app-config.json'))
      .then((config: AppConfig) => (this.configuration = config))
      .catch(error => {
        console.error(error);
      });
  }

  //We're going to use this function to read the config.
  readConfig(): AppConfig {
    return this.configuration;
  }
}

1.3 - Angular provides us APP_INITIALIZER,a DI token, that you can use to provide one or more initialization functions, the function is executed during the application bootstrap process, and the needed data is available on startup.

NgModules:

//Here we have the function to receive the Config Service and use it for retrieving
//The config files.
export function initConfig(appConfig: ConfigService) {
  return () => appConfig.setConfig();
}

@NgModule({
  imports: [BrowserModule],
  declarations: [AppComponent],
  bootstrap: [AppComponent],
  providers: [
  {
      provide: APP_INITIALIZER,
      useFactory: initConfig,
      deps: [ConfigService], //We say to angular that this initializer depends of ConfigService
      //So config service will be available for the init config
      multi: true,
    },
  ],
})

export class AppModule {}

Standalone:

import { provideHttpClient } from "@angular/common/http";
import { APP_INITIALIZER } from "@angular/core";
import { bootstrapApplication } from "@angular/platform-browser";
import { ConfigService } from "./core/services/config.service";

  export function initConfig(appConfig: ConfigService) {
    return () => appConfig.setConfig();
  }

bootstrapApplication(App, {
  providers: [
    provideHttpClient(),
    {
      provide: APP_INITIALIZER,
      useFactory: initConfig,
      multi: true,
      deps: [ConfigService],
    },
  ],
});

1.4 - Now, consuming it in your component is a piece of cake!

import { Component, inject } from '@angular/core';
import { CommonModule } from '@angular/common';
import { RouterOutlet } from '@angular/router';
import { ConfigService } from '../util/config.service';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [CommonModule, RouterOutlet],
  templateUrl: './app.component.html',
  //Note: We don't need to provide it at providers, because we already
  //provided on our application
  styleUrl: './app.component.scss',
})
export class AppComponent {
  //Note: this component is using standalone, for ngModules just import on module providers
  configService = inject(ConfigService);

  apiUrl = this.configService.readConfig().API_URL;

  constructor() {
    console.log(this.configService.readConfig().API_URL);
  }
}

2 - Nginx config file

At the project’s root, we create a simple configuration file for serving the assets. Note: Feel free to include your configurations.

server {
  listen 80;

  gzip on;
  gzip_http_version 1.1;
  gzip_disable      "MSIE [1-6]\.";
  gzip_min_length   256;
  gzip_vary         on;
  gzip_proxied      expired no-cache no-store private auth;
  gzip_types        text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;
  gzip_comp_level   9;
  client_max_body_size 5M;
  proxy_read_timeout 200s;

  location / {
    include /etc/nginx/mime.types;
    root /usr/share/nginx/html;
    add_header Cache-Control "public, max-age=1M";
    try_files $uri $uri/ /index.html =404;
  }

  location /healthcheck {
        access_log off;
        add_header 'Content-Type' 'text/plain';
        return 200 "Healthy\n";
    
  }
}

3 - Docker

Let’s containerize our application by creating the Dockerfile at the root of our project, inside of it we have all the steps for building our application.

# Use official node image as the base image
FROM node:lts as build

ADD ./package.json /tmp/package.json
RUN cd /tmp && npm install
RUN mkdir -p /usr/local/app && cp -a /tmp/node_modules /usr/local/app/

WORKDIR /usr/local/app

# Add the source code from the app to the container
COPY ./ /usr/local/app/

# Generate the build of the application
RUN npm run build

# Stage 2: Serve app with nginx server
# Use official nginx image as the base image
FROM nginx:latest

# Copy the build output to replace the default nginx contents.
COPY --from=build /usr/local/app/dist/build/browser /usr/share/nginx/html

# This line is IMPORTANT, we will breakdown it on a minute.
COPY ./entrypoint.sh /usr/local/app/entrypoint.sh

# Copy the nginx conf that we created to the container
COPY ./nginx.conf  /etc/nginx/conf.d/default.conf

# Expose ports
EXPOSE 80 443 6006 4200

RUN chmod +x /usr/local/app/entrypoint.sh
ENTRYPOINT [ "/usr/local/app/entrypoint.sh" ]

In essence, our application is currently encapsulated within a container. However, we need to guide it in using a designated app-config. Let’s presume that the machines where you are running have environment variables that convey the current environment information. To facilitate this, at the project root, we can create the entrypoint.sh This script will determine a file replacement based on the specific environment in which our application is operating.

The “Entrypoint” serves as the initial command executed when your container starts, essentially initializing the container.

Note: The specifics might vary for your company, but the underlying concept remains applicable and can be adapted accordingly to project requirements.

#!/bin/bash -e

#Check for the ENVIRONMENT variable and replace the file based on that
if [[ $ENVIRONMENT = "Dev" ]]; then
   cp /usr/share/nginx/html/config/app-config.dev.json /usr/share/nginx/html/app-config.json
fi

if [[ $ENVIRONMENT = "Production" ]]; then
   cp /usr/share/nginx/html/config/app-config.prod.json /usr/share/nginx/html/app-config.json
fi



nginx -g 'daemon off;' 

4 - Running your container

# Build the image and assign a tag to it, run it at the root folder
docker build . -t angular-boda

# After the build finish, we can start our application and use the port 8080
# just for testing we set the environment as production to see our BODA working
# for testing with other value just change to ENVIRONMENT=Dev
docker run -p 8080:80 -e ENVIRONMENT=Production -t angular-boda

You should be able to see the application at localhost:8080:

5. Wrapping Up

Thank you all for reading. In this article, we harnessed the power of Angular, Docker, and Nginx to craft a versatile container capable of seamless deployment across diverse environments. This not only streamlines the development process but also optimizes the efficiency of CI/CD pipelines.

Feel free to explore the complete example on GitHub.

Wishing you a prosperous New Year ahead! 🎆🎆

Angular evolves, and so do the approaches to creating components. Join me on a journey through a guide to component development

It has been a lengthy journey to Angular 17. While maintaining backward compatibility, the Angular team is continuously evolving the framework. Like many others, I find myself constantly contemplating what to use and when to use it. In this article, I will express my thoughts on what you should use when creating your new component.

Signals

Signals have been available since version 16, and they are a must-have managing state on your application. If you’re not already using Signals, it’s time to start doing so. Initially, there might be a learning curve, but it’s quite simple, and it becomes natural over time. Combined with OnPush change detection, it provides finely-tuned reactivity, performance gain, and a delightful developer experience.

Observables

If we have Signals, why do we need observables? Keep in mind that signals handle synchronous reactivity and observables handle asynchronous reactivity, for example, HTTP requests, while providing us tools for interacting with those values (map, switchMap).

ChangeDetection.OnPush

First, a brief explanation of each one:
Default: Angular triggers change detection on browser events, timers, XHRs, and promises. The system then examines each component in the component tree sequentially from top to bottom. In large systems, this can lead to performance issues.

OnPush: It disables the default change detection. In brief, the component only re-renders in a few specific situations:

• Async pipe new values
• The input reference has been altered (reference, not the value, immutability).
• An event originating from the component or one of it children.
• Manual Trigger

So, just by reading the above, do you already know? Right?

Always use ChangeDetection.OnPush, and when combined with Signals, you can elevate your component performance to another level. Furthermore, when Angular completes the implementation for full zoneless, your application will be one step closer to achieving it.

Control Flow

@if (a > b) {
  {{a}} is greater than {{b}}
}

Since V17, we have the new control flow for Angular. Yes, it’s in developer preview, but it feels so natural and powerful because is exactly like js syntax. Therefore, you should be using it. However, I find myself still using the good old *ngIf directive quite often. Sometimes you just want to hide a <span>, and I think that’s still easier than writing three lines. The available blocks are @If, @for, @switch.

Inject() VS constructor()

This decision can be challenging. I currently utilize inject(), understanding the merits and demerits of both approaches, though a detailed exploration is beyond the scope of this discussion.

In my specific situation, the preference for inject() is largely due to syntax sugar. It aligns more seamlessly with conventions in other frameworks. Despite encountering resistance from some developers (myself included initially), the transition pays off in terms of code readability. However, it's important to note that we are not entirely liberated from using constructor(). I heavily rely on it, especially for Signal effect() because they need to run in the injection context. I find it to be the most straightforward method in such scenarios.

Component for Reference:

import {
  ChangeDetectionStrategy,
  Component,
  inject,
  signal,
} from '@angular/core';
import { MsalService } from '@azure/msal-angular';
import { UsersService } from 'src/app/api/users-services';
import { Observable } from 'rxjs';
import { AsyncPipe, DatePipe } from '@angular/common';

export interface UserDetail {
  id: string;
  key: string;
  timestamp: string;
}

@Component({
  selector: 'app-users-widget',
  template: `<div>
    @if ((detailsList$ | async); as userData){
    <div>
      @for(data of userData; track data.id){
      <div (click)="setDetails(data)">
        {{ data.id }}
      </div>
      }
    </div>
    } @if (openDetail(); as openDetail){
    <h2>User Details</h2>
    <p>{{ openDetail.id }}</p>
    <p>{{ openDetail.key }}</p>
    <p>{{ openDetail.timestamp | date : 'long' }}</p>
    }
  </div> `,
  standalone: true,
  imports: [DatePipe, AsyncPipe],
  changeDetection: ChangeDetectionStrategy.OnPush,
})

export class UsersWidgetComponent {
  usersService = inject(UsersService);
  //# for private modifier
  #authService = inject(MsalService);

  openDetail = signal<UserDetail | null>(null);
  detailsList$: Observable<Array<UserDetail>> = new Observable();
  
  //Using the constructor instead of the ng lifecycle
  constructor() {
    this.retrieveFlowHistoryData();
  }
  
  retrieveFlowHistoryData() {
    const { username } = this.#authService.instance.getAllAccounts()[0];
    this.detailsList$ = this.usersService.apiFlowsHistoryGet$Json({
      UserName: username,
    });
  }

  setDetails(detail: UserDetail) {
    this.openDetail.set(detail);
  }
}

Wrapping Up

Navigating the ever-evolving landscape of libraries and frameworks can be a challenging task. I trust that this article has provided you with insights into some of the latest Angular conventions. Until next time!

TL;DR
✅ Standalone
✅ Inject
✅ Control Flow
✅ Observables
✅ ChangeDetection.OnPush
✅ Typescript private # modifier
✅✅ Signals
✅ ‘as’ for store conditional in the variable

In this article, we’re going to see the role of bundlers and bundle analyzers in modern web development.

Developers have always faced a common problem since the beginning of programming— the size of their applications. This applies to mobile, web, and desktop development. A single npm install followed by an import statement and boom… you have a new code in your application.

In the realm of JavaScript, things are a bit distinct, as we’re frequently fetching and executing new code. Just one second of download and execution can alter the entire scenario for the future of our application.

Slow page load times also affect how users see and interact with your website. Over 70% of customers say that page speed impacts their likelihood to purchase. Consequently, close to half of them are less likely to buy and return to the slow website in the future.

As the years passed the javascript world saw an emerging solution to ship less code: bundlers.

A bundler combines and packages multiple files and dependencies into a single, optimized file for efficient web deployment. It helps manage and organize code, improving performance by reducing the number of HTTP requests and optimizing resources. Popular bundlers include Webpack and Parcel.

But it’s not magic…

Despite the awesome capabilities of bundlers, poor development decisions can lead to the delivery of unnecessary code to the client. Additionally, using outdated dependencies that lack optimization can contribute to performance issues.

So how can we open this Pandora's box?

Bundle analyzers

They provide the capability to visualize the composition of our bundles and identify which modules contribute significantly to the overall size. Here is how to use it in some of the most famous bundlers:

Esbuild

1. Add the metafile option to your build.

esbuild app.js --bundle --metafile=meta.json --outfile=out.js

2. Enter https://esbuild.github.io/analyze and import the generated meta.json

3. It is an interactive graph.

Webpack

1. First of all, we should install it on the project

npm install --save-dev webpack-bundle-analyzer

2. In this case we’re going to use it as a plugin, but you can check other ways 👉 https://www.npmjs.com/package/webpack-bundle-analyzer

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  plugins: [
    new BundleAnalyzerPlugin()
  ]
}

3. It will generate an HTML output on your folder.

Vite

1. Just npx https://www.npmjs.com/package/vite-bundle-visualizer

npx vite-bundle-visualizer 
## or
npx vite-bundle-visualizer -t sunburst

2. It will automatically open your default browser for visualizing it.

Strategies for Improvement

With the ability to visualize your bundles, you can apply a few strategies to enhance your application.

1. Upgrade to Newer Packages: Consider replacing older packages with newer versions to benefit from performance enhancements, bug fixes, and additional features.
2. Reevaluate Necessity: Rethink whether the application truly requires a specific package. Eliminating unnecessary dependencies can contribute to a more streamlined and efficient codebase.
3. Optimize Initial Bundle Size: Always strive to minimize the size of the initial bundle. Reducing unnecessary components and optimizing code can enhance the application’s loading speed and overall performance.

Wrapping up

In this article, we delved into the pivotal role of bundlers and bundle analyzers:

• Continuous Monitoring: Vigilantly observing bundle sizes ensures an optimal user experience.
• Strategies for Improvement: Upgrading packages, reassessing dependencies, and minimizing the initial bundle size are crucial for enhanced performance.
• Empowered Decision-Making: Visualizing and optimizing bundles empower informed decisions, leading to a faster and more efficient web application.

I hope this article provides valuable insights! If your bundler isn’t mentioned, there’s likely a bundle analyzer available for it. See you all. #peace…

What are the most common angular interview questions?

As time passes, the IT sector becomes increasingly competitive. It is now common to see junior-level job openings with numerous applications. I have noticed that companies are increasingly hiring medium and senior-level engineers.

Therefore, it is important to be well-prepared for any opportunity that comes your way.

If a company is hiring for a specific framework, there is a high likelihood that part of the interview will focus on that particular aspect.

With all that said…

Angular is a well-known framework with a steep learning curve. However, once mastered, its countless benefits can significantly increase productivity. In the past, when conducting interviews, I would use three different levels of questions: beginner, intermediate, and advanced.

I often prefer home assignments, followed by an interview to understand the developer’s true skill level.

In the examples below, you will find concise explanations along with sources/references for further study!

1. Beginner

1.1. What is a directive?

Answer: Directive is a way of attaching custom behavior for existing DOM elements.

Angular

1.2. What is the difference between a component and a directive?

Answer: A directive is utilized to add supplementary behavior to an existing DOM element. In addition, Angular components are a subset of directives. They are always associated with a template and are specifically designed to create reusable UI blocks.

• Angular
• angular/packages/core/src/metadata/directives.ts at 3cf18bb6f2798020cbe8633fae79f920cf98816b · angular/angular

1.3. What is an Angular pipe? Can you give me an example of one?

Answer: Pipes are optimized functions used in templates to transform data. The AsyncPipe is employed to subscribe and unsubscribe from an asynchronous source, while the CurrencyPipe is used to transform a given value into currency.

Angular

1.4. How to create a component using the Angular-cli?

Answer:

# shortHand
ng g c example
# complete
ng generate component example 

Angular

1.5. Angular is an SPA framework? If yes, what is a SPA?

Answer: Yes, in a Single Page Application (SPA), all functions of your application are contained within a single HTML page. As users navigate through your application, the browser only needs to render the relevant sections, avoiding the need to load an entirely new page.

Angular

1.6. What is a NgModule?

Answer: NgModules organizes components, directives, and pipes into functional blocks, addressing specific features or business domains. They also integrate services, which can be internally developed or sourced externally, like the Angular router and HTTP client. We can also import other modules, and we can even set which components/directives/pipes this module will export.

Angular

1.7. What is a standalone component?

Answer: Standalone components directly import other components, directives, and pipes used in their templates, basically a standalone component is a self-contained module and can be used in other components or modules.

Angular

1.8. Can we use standalone components inside NgModule?

Answer: Yes, just add them to the import array.

Angular

1.9. What is a typescript decorator? Can you give an example of an Angular decorator?

Answer: A TypeScript decorator is a way to add extra features or modify a class, method, or property with a special label like @Component an Angular decorator.

Documentation - Decorators

1.10. What is an Rxjs Observable? What is the main difference between a Promise and an Observable?

Answer: Observables are functions utilized to encapsulate data streams. The values of this observable are consumed only when there is a subscriber. It’s closely related to the Observer pattern in design patterns.

Both are used to handle asynchronous events. The most significant difference is that promises deal with one async event at a time, while observables can handle a sequence of async events over a period of time.

• Note: There are a bunch of differences between them, take some time to read about them.

• Angular Promises Versus Observables
• What is the Difference Between Promises and Observables?

1.11. What is the difference between a Subject and a BehaviourSubject?

Answer: Essentially, when we subscribe to a subject, we receive the values emitted after the subscription. In contrast, with a BehaviorSubject, when we subscribe to it, we receive the latest value of the source right at the moment of subscription.

BehaviorSubject

1.12. What is the component lifecycle? Can you give 3 examples?

Answer: A component’s lifecycle is the sequence of steps that happen between the component’s creation and its destruction.

ngOnInit(), ngOnChanges() & ngOnDestroy()

Lifecycle * Angular

1.13. What are the available types of compilations in Angular? And what is the difference between them?

Answer: JIT (Just-in-Time) and AOT (Ahead-of-Time)

JIT: Compile your application in the browser at runtime.

AOT: Compile your application at build time.

Angular

1.14. What are the available change detections in Angular? And what are the differences between them?

Answer: Default and OnPush

Default: The default strategy initiates change detection for various events such as DOM events, timers, promises, XHR, and observables. As a result, whenever there is a change in our application, change detection runs on all components to ensure the view is updated.

OnPush: Utilizing the OnPush strategy, Angular initiates a change detection cycle for a component and its children solely upon changes in the component’s input properties or triggered events. This approach enhances performance, albeit at the cost of introducing some additional complexity to the component code.

Angular

1.15. The developer can trigger the change detection manually? If so, how?

Answer: Injecting the ChangeDetectionRef, and calling markForCheck() or detectChanges()

1.16. What is lazy loading? And how can we achieve it?

Answer: By default, all NgModules are eagerly loaded. Lazy loading, on the other hand, is a design pattern that loads modules or components as needed. It helps to keep the initial bundle as small as possible, and we can take advantage of it with NgModules and standalone components, just by using:
loadChildren()on routes for NgModules

loadComponent() on routes for standalone components

• Angular
• Angular

BONUS: What are Signals?

Answer: A signal serves as an encapsulation for a value, signaling interested consumers when the underlying value undergoes changes. Signals can encompass a wide range of values, from basic primitives to intricate data structures. This enables something called fine-grained update/reactivity, which enables us to optimize the render/Dev experience.

Angular

2. Intermediary

2.1. Are you familiar with content projection? Can you describe it?

Answer: Yes, content projection is employed often using <ng-container> to create a component that acts as a container for content. When using a component with <ng-content>, any children of the component’s host element are rendered or projected to the specified location.

<!--Component1-->
<div id="component1"><ng-content></ng-content></div>

<!--Component2-->
<app-component1>
<span id="component2">HELLO</span>
</app-component1>

<!--Rendered-->
<div id="component1">
<span id="component2">Hello</span>
</div>

Angular

2.2. How can we change easily the currency of the CurrencyPipe

Answer: The first parameter of the pipe should be the currency you want to display, at the template.

<div>{{money | currency:’EUR’}}</div>

Angular

2.3. I want to create my own pipe extending some of the Built-in pipes, how?

Answer: Use Typescript extends with the class of the Pipe that you want, for example, DatePipe, and implement the PipeTransform interface.

export class DaylightDatePipe extends DatePipe implements PipeTransform

Angular

2.4. What is a polyfill?

Answer: A polyfill is a code snippet, typically written in JavaScript for web applications, that serves to enable modern functionality on older browsers lacking native support. For instance, a few years ago, Internet Explorer lacked certain native APIs, so we used polyfills to replicate that functionality.

Polyfill - MDN Web Docs Glossary: Definitions of Web-related terms | MDN

2.5. Why should you unsubscribe from Observables?

Answer: Not unsubscribing can lead to data leaks, which, in turn, can result in performance issues.

Angular

2.6. How to unsubscribe from Observables?

Answer: There are several ways to unsubscribe. We can do it manually by calling the unsubscribe() method. Alternatively, we can use the async pipe, which automatically unsubscribes from the observable. Another option is to use the takeUntil() RxJS operator, which completes the output Observable when a specified Observable emits a value. This is often combined with a subjecttriggering for example, in the ngOnDestroy()

Angular

2.7. What is a Hot and a Cold Observable?

Answer: A hot observable can begin even if no observers are currently subscribed and can persist after the last observer has unsubscribed. In contrast, a cold observable typically initiates only upon subscription and concludes when the subscription terminates. It can execute a process separately for each subscribed observer.

Reactive Programming: Hot Vs. Cold Observables

2.8. Difference between template-driven and Reactive Forms?

Answer: Reactive forms offer developers greater control over form elements, facilitating customization of form behavior and validations. They are also more convenient for unit testing, thanks to their reactive programming model, which allows more precise control over form data.

On the other hand, template-driven forms are a quick and efficient option for creating simple forms with minimal code. They are well-suited for straightforward use cases that do not demand extensive customization or complexity.

Angular

2.9. Are you familiar with Strictly typed Forms? What is the advantage of using it?

Answer: Yes, enabling the developer to build more complex forms, better autocomplete in IDEs, and more predictability.

Angular

2.10. How can we generate Observables from Event sources?

Answer: Using the fromEvent()function from Rxjs.

fromEvent

3. Advanced

3.1. How can we use the *ngTemplateOutlet directive?

Answer: *ngTemplateOutlet directive in Angular allows us to have a more complex content projection. While it can be applied to any HTML element, it is often paired with <ng-container> for optimal use.

With *ngTemplateOutlet, you can define reusable and customizable templates that leverage variables within their scope. For instance, consider the following example:

<!--HTML from Component1, the selector is app-component1 -->
<ng-container *ngTemplateOutlet="customTemplate; context: { data: myData }"></ng-container>

<!--HTML from Component2-->
<app-component1>
<ng-template #customTemplate let-data>
  <div>
    <p>{{ data.property1 }}</p>
    <p>{{ data.property2 }}</p>
  </div>
</ng-template>
</app-component1>

Angular

3.2 What are Angular elements? Can you give a user case for it?

Answer: Angular elements are essentially Angular components encapsulated as custom elements, also known as Web Components. These adhere to a web standard that defines the creation of new HTML elements in a manner independent of any specific framework. One practical use case for Angular elements is the creation of a library intended for clients who do not use Angular.

By packaging Angular components as custom elements, the resulting library becomes framework-agnostic. This means that clients utilizing different frontend frameworks or even plain HTML can seamlessly incorporate and benefit from the functionality provided by the Angular components. This approach enhances the reusability and interoperability of Angular components across diverse projects and technology stacks

Angular

3.3. How can we use SSR/SSG on Angular?

Answer: There are some steps to it, first of all, we should add SSR package to our project ng add @angular/ssr, we should make our application be served from the server.ts and migrate our component to be server-compatible because some of the browser’s APIs are not available on the server.

Note: of course, this is a big simplification of the process.

Angular

3.4. What is the difference between SSR and SSG?

Answer:

SSR: involves generating HTML on the server dynamically for each request, and is well-suited for applications with real-time or frequently changing data because the server generates content dynamically for each request.

SSG: involves pre-generating HTML during the build phase of the application which can be served statically to clients, it can offer faster initial page loads as the HTML is already available and doesn’t need to be generated on the server for each request. However, if content changes, the application needs to be rebuilt to reflect those changes, making SSG less suitable for real-time or frequently updated content.

Angular

3.5. What is the difference between @ViewChild and @ViewChildren?

Answer: @Viewchild()will retrieve the first element matching the selector while @ViewChildren() will return a query list of all elements matching the given selector.

Angular

Wrapping Up

The first version of Angular 2 was published back in 2016. Therefore, it is not possible to cover all the points about it in just one post, this open a possibility for a part 2, right?😉

I hope this article will help you guys to rock the interviews!

Let me know if you enjoyed it and please share some insight ❤… #peace

#angular #typescript #rxjs #interview #javascript

Thanks to Sai for the suggestion of the article!

Since the beginning of Angular, I have consistently enjoyed the process of creating routes. It is simple, straightforward, and well-structured. It’s quite easy to create your initial route and incorporate parameters, but the experience of retrieving those parameters in the component has always been the same, a bit unecessary let’s say.

import { Component, OnInit, inject } from '@angular/core';
import { ActivatedRoute } from '@angular/router';

@Component({
  selector: 'page-details',
  template: ` <div>
    <h1>{{ pageId }}</h1>
  </div>`,
  standalone: true 
})

export class DetailsComponent implements OnInit {
  pageId: number = 0;
  private route = inject(ActivatedRoute);
  ngOnInit(): void {
    this.pageId = Number(this.route.snapshot.paramMap.get('pageId'));
    // OR
    this.route.params.subscribe((params) => {
      this.pageId = Number(params['pageId']);
      //Do something with the other pageId
    });
  }
}

Cons of those approaches:

1. It is always necessary to implement the OnInit lifecycle.
2. Ensure the type of the parameter.
3. Inject the ActivatedRoute service.

Presenting… bindToComponentInputs

Since Angular 16, we have a new method for retrieving the parameters. First and foremost, you should be aware of the type of the bootstrapping that your application is using.

Standalone

main.ts

import { bootstrapApplication } from '@angular/platform-browser';
import { appConfig } from './app/app.config';
import { AppComponent } from './app/app.component';


bootstrapApplication(AppComponent, appConfig).catch((err) => console.error(err)); 

So in app.config.ts (Only generated when using the --standalone option of the ng new…)

import { ApplicationConfig } from '@angular/core';
import { provideRouter, withComponentInputBinding } from '@angular/router';

const routes: Routes = [
  { path: '/:pageId/:viewName', component: DetailComponent },
];

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withComponentInputBinding())
  ]
};

In the provideRouter we add the withComponentInputBinding()…

NgModule

main.ts

import { enableProdMode } from '@angular/core';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';

import { AppModule } from './app/app.module';
import { environment } from './environments/environment';

if (environment.production) {
  enableProdMode();
}

platformBrowserDynamic().bootstrapModule(AppModule)
  .catch(err => console.error(err));

In almost all projects the AppModule(that I’m not showing here)will be importing the app-routing.module.ts, that should look something like:

import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';
import { DetailComponent } from './feature/pages/detail/detail.component';;

const routes: Routes = [
  { path: ':pageId/:viewName', component: DetailComponent },
];

@NgModule({
  imports: [RouterModule.forRoot(routes, { bindToComponentInputs: true })],
  exports: [RouterModule],
})
export class AppRoutingModule {}

In the RouterModule.forRoot we add to the second parameter the object with the property bindToComponentInputs

And now… the grand finale…

import { Component, OnInit, inject } from '@angular/core';
import { ActivatedRoute } from '@angular/router';

@Component({
  selector: 'page-details',
  template: ` <div>
    <h1>{{ pageId }}</h1>
  </div>`,
  standalone: true //Depends on your bootstrap type...
})

export class DetailsComponent implements OnInit {
  @Input({transform: numberAttribute}) pageId = 0;
  @Input("viewName") pageName = "";

  ngOnInit(): void {
   console.log(this.pageId); //Logs a number
   console.log(this.pageName); //Logs a string
  }
}

So, in the final code, we achieve more with less:

• There’s no longer a need for the ActivatedRoute service.
• We can ensure the type of the input, and we can even transform it using the new transform function inside the @Input decorator. (It’s available in the 16.1.0 version)
• In cases where we don’t need an ngOnInit.

Wrapping Up

Now, after Angular 16, I recommend that almost all components relying on routing parameters retrieve them from input properties. It’s very clean to understand and ensures more safety with less code.

That’s all, folks! #peace.

#typescript #angular #javascript #rxjs

I have been working with Angular since the days of AngularJS, and I must say that when you work with other frameworks that use JSX, sometimes developing in Angular HTML and directives can be a quite “different experience”.

I’ve been keeping an eye on the RFC (Request for Comments) about the new control flow, but after watching the Angular keynote, I became really interested in trying it out. So today, I updated my project to Angular 17.0.0.

By fate, I’m currently working on creating a searchable select with options fetched from the server, that’s a great component for testing it.
Let’s take a look at the first version. In this initial version, I didn’t include a loader or empty feedback for the user, and I was using the built-in directives. Here’s the code snippet:

<div [formGroup]="form" class="configuration-select" #selectInput>
  <app-input
    [required]="required"
    [formControlName]="key"
    (focusEvent)="displayOptions = true"
  ></app-input>
  <div
    class="select-options"
    [style.width.px]="searchSize$.asObservable() | async"
    *ngIf="displayOptions"
    (clickOutside)="displayOptions = false"
  >
    <span
      *ngFor="let option of search$ | async"
      class="option"
      (click)="selectOptions(option)"
      [ngClass]="{ selected: option.text === form.controls[key].value }"
      >{{ option.text }}</span
    >
  </div>
</div>

So, what we can see here is that experienced Angular developers can easily understand what’s happening just by looking at the template directives. As I mentioned earlier, it works, but there’s room for improvement and the Angular team and community knew that.

For better clarification, here is the TypeScript code. Basically, the observable $search is responsible for the service response (in this case, it’s mocked as an array). By the way, I’m always trying to be more declarative and work with the RXJS, just by looking the ngOnInit we can understand what is happening.

import { AfterViewInit, Component, ElementRef, HostListener, Input, OnInit, ViewChild } from '@angular/core';
import { FormGroup } from '@angular/forms';
import {
  BehaviorSubject,
  Observable,
  delay,
  distinctUntilChanged,
  finalize,
  mergeMap,
  of,
  startWith,
  tap,
} from 'rxjs';
import { IConfigAction } from 'src/app/api/dynamic-config-models';

interface Option {
  text: string;
  value: string;
}

@Component({
  selector: 'app-configuration-select',
  templateUrl: './configuration-select.component.html',
  styleUrls: ['./configuration-select.component.scss'],
})

/**
 * This component will handle a state and a connection with a service, because makes much more sense to be responsible for the own call
 */
export class ConfigurationSelectComponent implements OnInit, AfterViewInit {
  @ViewChild('selectInput') selectInput!: ElementRef;

  @Input() key = '';
  @Input() form: FormGroup = new FormGroup({});
  @Input() style: 'DEFAULT' | 'LINE' = 'DEFAULT';
  @Input() required = false;
  @Input() label = '';
  @Input() action!: IConfigAction;
  displayOptions = false;

  constructor() {}

  search$: Observable<Option[]> = new Observable();
  searchSize$: BehaviorSubject<number> = new BehaviorSubject(0);
  loading = false;

  @HostListener('window:resize')
  onResize() {
    this.searchSize$.next(this.selectInput.nativeElement.offsetWidth);
  }

  ngAfterViewInit(): void {
    setTimeout(() => {
      this.searchSize$.next(this.selectInput.nativeElement.offsetWidth);
    }, 0);
  }

  /**
   * Basically our entire logic happens on the ngOnInit, remember try always to achive declarative code with rxjs
   * It's better to understand searching for imperative code
   */
  ngOnInit(): void {
   this.search$ = this.form.controls[this.key].valueChanges.pipe(
      distinctUntilChanged(),
      debounceTime(200),
      startWith((starterValue: string) => this.requestOptions(starterValue)),
      tap(() => (this.loading = true)),
      mergeMap((value: string) => this.requestOptions(value)),
      finalize(() => (this.loading = false))
    );
 }

  /**
   * Basically the endpoint call, but here we're simulating it with observables
   * @param searchString to send to the backend for a fuzzy search
   * @returns
   */
  requestOptions(searchString: string) {
    const options = [
      { text: 'Something', value: 'something' },
      { text: 'new', value: 'new' },
      { text: 'another one', value: 'another' },
    ];

    const filtered = options.filter((option) => {
      return option.text.includes(searchString);
    });

    return of(filtered.length > 0 ? filtered : options).pipe(
      delay(2000),
      tap(() => (this.loading = false))
    );
  }

  selectOptions(option: Option) {
    this.displayOptions = false;
    this.form.controls[this.key].setValue(option.text);
  }
}

Breakdown with the new Control Flow

<div [formGroup]="form" class="configuration-select" #selectInput>
  <app-input [required]="true" [formControlName]="key" (focusEvent)="displayOptions = true" />
  @if (displayOptions){
  <div class="select-options" [style.width.px]="searchSize$.asObservable() | async">
    @if (loading === false && (search$ | async); as searchResults){ 
     @for (option of searchResults; track option.value){
     <span
       class="option"
       (click)="selectOptions(option)"
       [ngClass]="{ selected: option.text === form.controls[key].value }"
       >{{ option.text }}</span>
     }@empty {
     <span class="option">No options found</span>
     } 
    }@else{
    <app-spinner />
    }
  </div>
  }
</div>

By the way, I’m using the new self-closing tag feature that helps keep the code cleaner. Why did we wait so long for this?

Highlights:

• You can do more with lesscode
• It feels very natural to work/view that.
• It’s get way easiear to have for example a empty treatment for your lists.
• It’s more optimized by default, angular maintaners says something around 30% on the @for statement

New Syntax

“@if” works like a normal “if” in any programming language, and we can even take advantage of the async pipe to work with observables, similar to the good old *ngIf. Another significant difference here is that we can now use the “@elseif” and even the “@else” block.

“@for” now replaces *ngFor and looks quite similar to TypeScript’s for loop. The difference now is that we need to use a “track” (similar to the old trackBy, but required), which improves the performance of rendered lists. Another valuable addition is the “@empty” block, which allows us to render something when the list is empty, eliminating the need for manual checks with *ngIf.

Beyond this example, we also have the “@switch” case, which behaves exactly like *ngSwitch. The main difference is that it does not require a container element to hold the condition expression or each conditional template. You can see the example below:

@switch (condition) {
  @case (caseA) {
    Case A.
  }
  @case (caseB) {
    Case B.
  }
  @default {
    Default case.
  }
}

Not everything that shine is gold…

Because it’s in developer preview, I still encounter some problems, such as formatting. Other issue that maybe it’s related to the new ESBuilder is: sometimes, when I save my HTML, it doesn’t recompile, and occasionally, I need to go to a TypeScript file and simply press CTRL + S to trigger the compiler.

But with that said…

I recommend installing the new Angular version and starting development with the control flow. It feels very comfortable, and the learning curve is not too steep. It comes naturally to Angular developers and even to other developers. With this new approach, we can think differently, reduce the boilerplate, and have much more structured code in the HTML.

The next step will be trying out ‘@defer’ which will enable us to defer some components that don’t need to be executed immediately.

And, of course, there are the new stable SIGNALS API.

Stay tuned for the next… #peace

#angular #typescript #rxjs #controlflow