DEV Community: Tim

How I built a multi-country price comparator as a solo dev: static-first, Workers, D1 and a lot of feed matching

Tim — Wed, 11 Nov 2026 13:31:46 +0000

A price comparator looks like a simple product: show a product, show a list of prices, redirect to a shop. I built one alone, and the simple part turned out to be about ten percent of the work. This post walks through the architecture of Runometry, a comparator for running shoes, bikes and sports electronics, and what I would tell myself before starting.

The numbers, so you know the scale: more than 600 000 prices, more than 20 shops, 15 delivery countries, a site in 10 languages and more than 2 500 products in the catalog. It is small by marketplace standards, but big enough that every shortcut shows up as a bug.

The core idea: static-first

Most comparator pages do not change every minute. A shoe's spec sheet changes when a human edits it. Prices change hourly at best. So I split the problem in two:

Slow data (models, brands, specs, texts, taxonomy) lives in the repository as JSON and is compiled into pages at build time.
Fast data (prices, availability) lives in a database and is served through a small API that the page reads after it loads.

The front end is AnalogJS, which is Angular with Vite, file-based routing and SSR plus prerendering. Pages are prerendered to HTML, so a crawler or a slow phone gets real content immediately, and Angular hydrates on top. Anything that needs the browser (a price list that depends on the visitor's country, a size filter) runs after the first render, and the template for it is deferred.

The rule I enforce in code review, even though I am the only reviewer: nothing that touches the browser runs during server render, and nothing blocks a crawler. It sounds obvious. It is the rule I broke most often early on.

The platform: Workers, D1, R2, KV

Everything runs on Cloudflare, and I picked it mostly for the boring reasons: one bill, one deploy tool, and edge latency for free.

Workers serve the redirect that sends a visitor to a shop, the prices API, scheduled jobs and a small admin.
D1 (SQLite) stores prices and offers. The schema is plain tables with indexes shaped by the queries the pages actually run.
R2 stores images and pre-rendered pages.
KV holds small, read-heavy things that are annoying to query: configuration snapshots and caches.

D1 taught me the first real lesson. SQLite at the edge is fast for reads and unforgiving about heavy writes. Early on, an ingest run that wrote rows one by one overloaded the database and the API started returning errors for visitors. The fix was boring: batch the writes, skip rows that have not changed, and keep a clear separation between the tables that visitors read and the tables the ingest writes while it works.

The hourly ingest Worker

Prices come from retailer feeds, which are files published through affiliate networks. A scheduled Worker runs every hour. Per feed, it does roughly this:

// Illustrative pipeline, not the real code
const rows = await fetchFeed(account);
const offers = [];
for (const row of rows) {
  const match = matchToCatalog(row);      // model, colourway, size
  if (!match) { report.unmatched.push(row); continue; }
  offers.push(toOffer(match, row));       // price, stock, link
}
await upsertChanged(offers);              // only rows that differ
await retireMissing(account, offers);     // gone from the feed = gone from the site

Three details mattered more than the code shape:

Dry runs are the default. Running ingest on my machine never writes to production. Writing happens only at release, through the pipeline.
Unmatched rows are a first-class output. A report of what did not match is more useful than a match rate. It tells me which model is missing from the catalog, or which mapping is wrong.
Retire what disappears. A comparator that keeps showing a price the shop removed yesterday is worse than one with fewer prices.

The hard part: matching feed rows to catalog models

This is where the time went. A retailer feed row is a product title, a price, a stock flag, sometimes a size, sometimes an EAN, and a free-form description. My catalog has a canonical model, with colourways, and sizes beneath those.

The matching has to answer three questions:

Which model is this? Titles lie. The same shoe appears as "Brand Model 14", "Brand Model v14 Men's" and "Model 14 Running Shoe Black". Brands reuse names across versions, so "Model 14" and "Model 15" must never merge, while "Model" in a title alone matches too many things. I ended up with a layered approach: exact identifier (EAN) first when the feed has one, then a normalised brand plus model plus version match, then fuzzy rules that only ever produce a candidate for review, never an automatic match.

Which colourway? Feeds describe colour in marketing names, in codes, or not at all. I treat colour as a filter on a model page, not as a page of its own. That decision removed a whole class of duplicate-content problems and kept the number of URLs sane.

Which size? Sizes are the quiet killer. A pair of shoes is priced per size, and shops list sizes in EU, UK, US or centimetres, with half sizes written four different ways. If you compare the cheapest price without knowing the size is in stock, you are showing a price nobody can use. So the offer is per size, and the visitor filters by their size. Bikes added another version of the same problem: frame sizes are letters in one feed and numbers in another.

EAN looks like the clean answer, and it helps a lot, but it is not a silver bullet. Some feeds omit it, some share one EAN across sizes, and a few reuse them across colourways. I treat it as strong evidence, not as truth, and check it against the model it points to.

Offers follow the market, not the language

This is the design decision I am happiest about, and the one that is easiest to get wrong.

A site in German is not a site for Germany. A German-speaking visitor can be in Austria or Switzerland. A French site is read in Belgium, in Switzerland, and in overseas territories that belong to France. If a language decides which shops you see, someone in Zurich reading German gets prices from a shop that does not ship to Switzerland.

So I model two separate things:

Locale: the language of the interface.
Market: the country the goods are delivered to.

A locale lists the countries it can show, with a default. A page shows the offers delivered to the visitor's market when it is known and allowed by the locale, and falls back to the locale's default country otherwise. The language never filters offers. I also made one rule explicit and tested: a locale never silently falls back to another country's offers, because showing the wrong country's prices is worse than showing nothing.

The outbound link follows the language, though. If a shop has a site in the visitor's language, the click lands there; otherwise it lands on its storefront for that market.

Delivered price

A cheap shoe with expensive shipping is not cheap. Delivery rules live in data (per shop, per market: thresholds, flat fees, free delivery above a basket value), and the site can show a price with delivery included so you compare what you actually pay. By default prices are shown without delivery, and the delivered price is a toggle. Both are computed from the same data, so they never disagree.

The deal rule: a median, not a struck-through price

Every comparator is tempted by the same shortcut: take the shop's crossed-out "was" price and show a big discount. Those prices are often meaningless. A reference price can be set high and never actually charged.

I use a rule that depends only on my own observations. A price counts as a deal when it is at least 25 percent below the median of the daily lowest prices observed over the last 90 days. Two guards go with it:

A discount above 70 percent is discarded. It is almost always a data error or a clearance of something that is not really what it claims to be.
The shop's struck-through price is never used, in any form.

// Illustrative
const median = medianOf(dailyLowest.slice(-90));
const isDeal = current <= median * 0.75 && current >= median * 0.30;

The effect is that a "deal" on Runometry means cheaper than it has recently been across the market, not cheaper than a number a shop chose. It also means a brand-new model has no deal status until there is enough history, which is the correct behaviour.

A zod-validated catalog in git

All the slow data is JSON in the repository: shoes, bikes, electronics, brands, shops, delivery rules, translations, editorial text. Every file is validated with zod at build time, and a failing schema fails the build.

Why git instead of a CMS or a database?

Review. A spec change is a diff. I can see exactly what changed and why.
Provenance. Each sourced value carries a status (verified, reviewed, disputed) and a date. A verified value is never overwritten by an automatic pass.
Rollback. A bad import is a revert.
Speed. The build reads files. There is no query to run for a spec sheet.

The cost is that the repo grows, and tooling matters: scripts that normalise, validate and report are part of the product. I would not do it differently, but I would write the report tools earlier.

Lessons learned

Solve matching before you scale shops. Adding a shop is easy. Adding a shop whose rows match correctly is the work. Count unmatched rows, not shops.
Make the market a first-class concept on day one. Retrofitting "country" into a language-based design is painful.
Keep production writes out of local development. A dry-run-by-default ingest saved me more than once.
Static-first is a feature for SEO and for a solo dev. Fewer moving parts at request time means fewer pages at 3 a.m.
Be honest in the data model. The deal rule and the delivered price exist because I did not want to show numbers I could not defend.
Test the thing you changed, not everything. A full test run is slow. Targeted specs while working, the whole suite at release.

What is next

More product universes beyond shoes, bikes and electronics, more shops per country, and better matching for the long tail of models. If you have built something similar, I would like to hear how you handled sizes.

You can browse the full catalog to see the result of all this. Runometry is funded by partner links.

Angular, AnalogJS, Spartan and Claude Code: shipping a 6-language comparison site fast

Tim — Thu, 01 Oct 2026 12:35:41 +0000

I built Runometry, a running shoe database and price comparator (841 shoes, 16 brands, 6 locales), mostly with Claude Code and parallel agents. Notes on the stack and the workflow.

Stack

Angular + AnalogJS: static rendering and file-based routing, a good fit for catalog pages generated from data. Signals and standalone components make modern Angular a joy.
Spartan (spartan.ng): shadcn-style, accessible UI components for Angular. Consistent design system, fully customizable.
Tailwind for styling.
Cloudflare for static hosting, with images served as WebP from a CDN.
hreflang and localized routes from day one.

Page types generated from the catalog Shoe, brand and category pages, A vs B comparator pages restricted to comparable pairs (to avoid thin or nonsensical pages), guides and blog.

Workflow with Claude Code

Clear conventions up front (structure, naming, component patterns), so agents produce code that fits the project.
Parallel agents on independent areas: comparator logic, templates, translations, data validation.
Me reviewing diffs, running the build, and checking anything factual.
Small, frequent commits so every agent change is easy to review or revert.

What I'd do the same way Keep the stack I know best. Agents shine when you can judge their output quickly.

What's next Daily price collection as a time series: price history, a price drop radar, alerts. I'm weighing feeds vs APIs vs scraping and would love input.

Live: runometry.com

The uncomfortable part of building an AI product

Tim — Thu, 11 Jun 2026 09:36:01 +0000

One of the most uncomfortable moments as a founder is realizing that you may have spent weeks or months building something in a way that is not quite right.

Not because the vision is wrong.

But because the path you took to reach it may not be the right one.

That is the kind of realization I recently had while building Mozart.

The first path made sense

Mozart started as a local-first desktop app to run AI agents on files and projects.

The first version naturally spoke to developers:

Git
worktrees
branches
local repositories
coding agents
CLI-based providers

And honestly, it made sense.

Developers are early adopters. They understand the technical concepts. They already feel the value of AI agents. They know why local-first matters. They understand why giving agents access to files and project context can be powerful.

But the more I thought about it, the more I realized something important.

The real opportunity is probably not only about developers.

The bigger problem

Most people who work behind a computer already feel that AI can help them.

But they are still stuck in a copy-paste loop:

ChatGPT on one side
files on another
emails somewhere else
documents in a folder
business tools in different tabs
workflows living only in their head

They do not need raw AI power only.

They need a way to turn that power into actual work.

That is where the product needs to evolve.

AI is the fuel, not the vehicle

I keep coming back to this metaphor:

AI models are becoming the new fuel.
Tokens are the oil.

But fuel alone does not take you anywhere.

You still need a car.
You need a cockpit.
You need an itinerary.

And in software, that itinerary is business logic:

workflows
templates
skills
tools
context
company-specific processes

The value is not only in the model.

The value is in the way you connect models, files, tools, workflows, and context to help someone go from point A to point B.

What I want Mozart to become

That is the direction I’m exploring with Mozart: a local-first AI workspace designed to make agents usable on real files, workflows, and business context.

Not just another tool for developers.

Not just another chat interface.

Not just another wrapper around an AI model.

The goal is to build a cockpit where people can use agents on their own files, with their own workflows, without needing to understand all the complexity underneath.

Maybe the first path was too technical.

But I still believe the direction is right.

I wrote more about this realization here:

Read the full post

From Burnout to Building: One Indie Dev's Story Behind Mozart

Tim — Mon, 18 May 2026 19:52:22 +0000

"I'm sick of working for other people's dreams."

That's the sentence that started it all. Not a rational decision, not a business plan, not a flash of genius, just exhaustion turning into clarity. One evening, in Montpellier, after weeks of chasing freelance gigs and hitting walls.

A few days later, I started building Mozart. This blog tells what comes next.

But first, let me rewind a bit.

I'm a self-taught developer. I discovered code at 14, and I learned everything on my own, through documentation, failed projects, and YouTube tutorials until 5 in the morning. For the last two years, I've done a few freelance gigs for small companies while travelling: Vietnam, Turkey, Portugal, Morocco, Thailand. Between stopovers, I tried to launch my own apps. None of them took off. I ended up dropping code for a while, I have this annoying tendency to overdose on what I love. But the passion always comes back.

When I picked code back up after a few months without a computer, it hit me hard. LLMs had made a massive leap.

I realised that the way we code was changing at a deep level. The craft of code is mutating: developers aren't just the ones writing each line anymore, they're becoming the ones who orchestrate, direct, and arbitrate.

A code manager.

Arthur Mensch, co-founder of Mistral, made the point recently in front of the French National Assembly: the bottleneck is no longer code production. It has shifted toward design and coordination. The more agents you stack, the more productivity you gain, but that productivity plateaus quickly if you don't know how to pilot them.

That's exactly the problem I want to solve.

The dormant dream

Around 2014, I discovered Y Combinator. At the time, I wasn't a developer yet. I had a civil engineering technician degree and worked in a lab, mostly on the road inspecting sports facilities. In the car, I listened to podcasts by Oussama Ammar (co-founder of The Family). A controversial figure, you love him or you don't, but he infused YC culture into France and inspired my generation. In parallel, I was reading Paul Graham's essays. All of that shaped how I saw startups, but only as a spectator. Watching from the sidelines, not daring to get my hands dirty.

Later, when I got seriously into code, the urge to start my own company never left me. But I always had an excellent excuse to put it off: "I'm self-taught", "I lack experience", "I still need to earn my stripes", "It's not the right time".

In hindsight, I know what was happening. There's never a right time. The real blocker wasn't my level. It was that I hadn't yet found the idea. The one that makes you say: this is it, this is now, I'm not letting it pass.

Crossing the desert

Finding your path is a chaotic process. At least it was for me. I regularly cross deserts, long stretches where nothing sticks, where doubt sets in. And then, every so often, I stumble onto an oasis. That's enough to get me moving again.

Before Mozart, I launched several projects. Not all of them finished, not all of them I'd own up to:

A Chrome extension to automate social-media replies via LLM. Not a bad idea, mediocre execution, zero distribution.
A sports platform built around events in France. Around 200 visitors a day, but zero paying customers so far. Alive, but small.

The lesson fits in one word: distribution.

In The Hitchhiker's Guide to the Galaxy, Douglas Adams tells the story of a civilisation that has a brilliant idea: ship off everyone deemed "useless", salespeople, marketers, consultants, hairdressers… At first, everything's great. Fewer meetings. Less posturing. The planet feels better.

Then comes the boring detail: without those people, civilisation collapses. Moral of the story: never underestimate distribution… or hairdressers lol.

You can build without distributing for a while. But not forever.

The genesis: memory first

The first serious intuition wasn't actually about Mozart. It was a thought about memory.

I was sick of having to repeat the same context over and over.

From one prompt to the next, memory is very limited. From one LLM to another, it disappears entirely. You explain your project to ChatGPT, then you start over with Claude, then with a third tool.

Even when memory exists, it tends to stay opaque, frustrating, and hard to control.

The starting idea: build a universal memory layer, pluggable into any model. A space that belongs to you, that stores your notes, your code, your projects, and exposes itself to the LLMs of your choice.

I quickly realised the topic was far more complex than it looked: embeddings, entity graphs, retrieval… every path opened up new problems. And if people much more advanced than me are already working on it without a clear solution emerging, it's probably because it isn't that simple.

The idea didn't disappear: it became the first pillar of Mozart.

Then one evening, the second click. If multiple LLMs can share a common context, why stick to a single agent?

Every AI giant is pushing its own closed interface. ChatGPT has one, Claude has one. But none of them is designed to make several agents work together, from different models, on interconnected tasks, in parallel.

Mozart was born out of that void. A cockpit: you launch your agents, they each move forward on their own work, and you keep your hand on the whole thing.

First step: look at the competition. It exists, it's well-funded, further along. The first instinct is to get discouraged. But an empty market would be far more worrying.

Competitors prove one thing: the problem is real. Serious teams believe in it, investors too. But no one seems to have definitively cracked it yet.

The window is probably still open.

What is Mozart?

Here are the three founding pillars:

For developers (at first), Mozart is designed for technical profiles who work with files and code, and who like to configure their own tools.
Local-first & Markdown, your files live on your machine, readable by you, ideal for LLMs, easily synced via GitHub. Ultra-low latency and more privacy.
Multi-agent & extensible, orchestration will be the heart of the product. Coordinating agents, distributing tasks, aggregating results without depending on a single AI vendor. This logic will eventually extend beyond code (admin, ops, business).

Where things stand

Mozart isn't public yet. I'm building the MVP. Or rather an "MVP++", because I have this annoying tendency to over-polish, a real flaw when you know how important "talk to users" is. I'm working on it.

The next step is a beta with a few peers and early adopters, before opening up publicly ASAP.

I already know where my pain point will be: distribution. Knowing how to build, that's fine. Getting it known, that's another story.

Hello, world.

This is the English version of an article originally written in French. Originally published on mozart.build.

Turbocharge your Angular project: A config tutorial

Tim — Thu, 09 May 2024 17:56:45 +0000

Introduction

Welcome aboard, Angular aficionados! You've embarked on a journey to supercharge your Angular project with some configurations and tools I like to use.

In this tutorial, we'll guide you through setting up essential configurations, integrating handy tools, and optimizing your workflow for a smoother development experience. Get ready to elevate your Angular game to the next level!

Setting Up Your Angular Project

To kick things off, let's create a new Angular project using the Angular CLI.

Open your terminal and run the following command:

ng new your_project --minimal --standalone --package-manager=pnpm

This command initializes a new Angular project named 'your_project' with minimal setup (without tests) using standalone and 'pnpm' as the package manager (pnpm site). Ignore this flag if you prefer using npm or yarn.

Integrating Tailwind CSS

Tailwind CSS offers a utility-first approach to styling your applications. Let's integrate it into our project. Run the following commands in your terminal:

bashCopy code
pnpm install -D tailwindcss postcss autoprefixer
npx tailwindcss init

These commands install Tailwind CSS and its dependencies and initialize a Tailwind configuration file.

Add to your style.scss:

@tailwind base;
@tailwind components;
@tailwind utilities;

Don't forget to add to tailwind.config.js:

content: ['./src/**/*.{html,ts}']

Adding ESLint for Code Linting

Code quality matters! Let's add ESLint, a popular code linter, to our project. Execute the following command:

ng add @angular-eslint/schematics

This command integrates ESLint into your Angular project seamlessly.

Incorporating Prettier for Code Formatting

Next up, let's enhance code formatting using Prettier. Run the following command to install Prettier:

pnpm install -D prettier

Additionally, we need to prevent conflicts between Prettier and ESLint. Execute the following commands to install necessary plugins:

pnpm install -D prettier-eslint eslint-config-prettier eslint-plugin-prettier

Fine-tuning Tailwind CSS with Prettier

Tailwind CSS and Prettier can work harmoniously together. Let's ensure Tailwind classes are formatted correctly. Install the Tailwind Prettier plugin using the command:

pnpm install -D prettier-plugin-tailwindcss

Optimizing Configuration Files

Now, let's optimize our configuration files for a seamless development experience. Follow the steps below:

Add a .prettierignore file and copy-paste the contents of your .gitignore file into it.
Ignore node_modules in ESLint by echoing "node_modules" > .eslintignore into your terminal.
Verify and update your .eslintrc file with the provided JSON configuration.

{
  "root": true,
  "ignorePatterns": ["projects/**/*"],
  "overrides": [
    {
      "files": ["*.ts"],
      "extends": [
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended",
        "plugin:@angular-eslint/recommended",
        "plugin:@angular-eslint/template/process-inline-templates",
        "plugin:prettier/recommended"
      ],
      "rules": {
        "@angular-eslint/directive-selector": [
          "error",
          {
            "type": "attribute",
            "prefix": "app",
            "style": "camelCase"
          }
        ],
        "@angular-eslint/component-selector": [
          "error",
          {
            "type": "element",
            "prefix": "app",
            "style": "kebab-case"
          }
        ]
      }
    },
    {
      "files": ["*.html"],
      "extends": [
        "plugin:@angular-eslint/template/recommended",
        "plugin:@angular-eslint/template/accessibility",
        "plugin:@angular-eslint/template/recommended"
      ],
      "rules": {}
    }
  ]
}

Enhancing Visual Studio Code Setup

Visual Studio Code is our development playground. Let's configure it for optimal productivity. Update your .vscode/extensions.json and .vscode/settings.json files with the provided configurations.

Add to .vscode/extensions.json to recommend and install extensions:

{
  "recommendations": [
    "angular.ng-template",
    "dbaeumer.vscode-eslint",
    "esbenp.prettier-vscode",
    "bradlc.vscode-tailwindcss"
  ]
}

Add to .vscode/extensions.json:

{
  "editor.formatOnSave": true,
  "eslint.validate": ["json"],
  "files.autoSave": "onFocusChange",
  "[html, scss]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.defaultFormatter": "dbaeumer.vscode-eslint"
  },
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true},
  "files.exclude": {
    "node_modules/": true,
    "dist/": false,
    ".angular/": true}
}

The files.exclude true option helps to save memory during builds.

Optimizing Angular Schematics

Customize Angular schematics to generate elements in the format that interests us. Update your angular.json file with the provided schematics configurations.

"schematics": {
  "@schematics/angular:component": {
    "inlineTemplate": false,
    "inlineStyle": false,
    "style": "scss",
    "skipTests": true,
    "standalone": true,
    "changeDetection": "OnPush"
  },
  "@schematics/angular:class": {
    "skipTests": true},
  "@schematics/angular:directive": {
    "skipTests": true,
    "standalone": true},
  "@schematics/angular:guard": {
    "skipTests": true,
    "functional": true},
  "@schematics/angular:interceptor": {
    "skipTests": true},
  "@schematics/angular:pipe": {
    "skipTests": true,
    "standalone": true},
  "@schematics/angular:resolver": {
    "skipTests": true,
    "functional": true},
  "@schematics/angular:service": {
    "skipTests": true}
}

Adding Pre-commit Hooks and lint-staged

Ensure code quality before each commit using pre-commit hooks. Install Husky and lint-staged with the commands:

pnpm i -D husky lint-staged
npx husky init

Add at the end of your package.json:

"lint-staged": {
  "*.(ts|js|html|css|scss|json|md)": [
    "prettier --write"
  ],
  "*.(ts|js)": [
    "eslint --fix"
  ]
}

Then, update your .husky/pre-commit file with the provided script:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx lint-staged

Implementing Commit Linting

Maintain a consistent commit message format with commitlint.

pnpm i D @commitlint/cli @commitlint/config-conventional

Create a commitlint.config.js file with the provided configuration.

touch commitlint.config.js

And add it:

module.exports = {
  extends: ['@commitlint/config-conventional']
};

Additionally, update your .husky/commit-msg file with the provided script:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx --no -- commitlint --edit ${1}

Conclusion

Congratulations! You've successfully configured your Angular project with essential tools and optimizations. With Tailwind CSS for styling, ESLint and Prettier for code quality, and seamless integration of pre-commit hooks and commit linting, your development workflow is now smoother and more efficient than ever.

Let us know in the comments if there are any tools or configurations you like to use in your projects?

Happy coding!

🚀 Follow me on X.com or GitHub for more tips and updates on Angular development!

Un opérateur RXJS pour debugger avec élégance ?

Tim — Wed, 27 Sep 2023 17:26:29 +0000

Tous les développeurs utilisant RXJS qui ont voulu déboguer ont déjà fait :

obs$.pipe(tap((v) => console.log("data", v)))
// ou pour les plus malins.
obs$.pipe(tap(console.log))

C'est pas très fun. Pour y remédier, on va créer un opérateur personnalisé qui nous permettra d'avoir :

Plus sympa comme logs non ?
Pour l'utiliser, il suffit de le passer dans le pipe :

import { debug } from './custom.operators.ts'

obs$.pipe(debug("data"));

Côté implémentation, c’est simple :

export function debug<T>(tag = 'Untitled') {
  if (environment.production) {
    return tap<T>();
  }

  const t = tag[0].toUpperCase() + tag.slice(1);

  return tap<T>({
    next(value: T) {
      console.log(
        `%c[${t}: Next]`,
        'background: #84cc16; color: #fff; padding: 3px; font-size: 9px; font-weight: 500;',
        value
      );
    },
    error(error) {
      console.log(
        `%[${t}: Error]`,
        'background: #ef4444; color: #fff; padding: 3px; font-size: 9px; font-weight: 500;',
        error
      );
    },
    complete() {
      console.log(
        `%c[${t}]: Complete`,
        'background: #6b7280; color: #fff; padding: 3px; font-size: 9px; font-weight: 500;'
      );
    },
  });
}

En bonus, j'ai ajouté une petite ligne en haut pour ne pas logger en production.

Voilà :) Happy coding !

Unsubscribe, un jeu d’enfant avec takeUntilDestroyed

Tim — Wed, 26 Jul 2023 07:50:00 +0000

Avoir un moyen d'unsubscribe à une observable facilement ça vous dis ?

En effet, tout développeur Angular c’est un jour trouvé confronté à répéter du code pour unsubscribe à des observables qui ont été subscribes manuellement (c’est-à-dire sans utiliser le pipe async fourni par Angular qui s’occupe d’unsubscribe automatiquement à notre place).

Et oui, qui dit observable dit subscribe et qui dit subscribe dit unsubscribe ! Tout oubli d'unsubscribe implique une fuite de mémoire et les pertes de performance qui vont avec.

Unsubscribe peut vite devenir un processus répétitif qui va réduire la lisibilité de notre code. Mais ça c’était avant !

Depuis Angular v16 l'opérateur takeUntilDestroyed va nous permettre de nous simplifier la vie.

Pour l’utiliser, c’est simple, tu l’importes depuis @angular/core/rxjs-interop et tu le chaines à une observable. Par exemple :

import { takeUntilDestroyed } from '@angular/core/rxjs-interop';

@Component({ ... })
export class ExempleComponent {

  constructor() {
    interval(1000).pipe(takeUntilDestroyed()).subscribe(console.log);
  }
}

L'opérateur takeUntilDestroyed est conçu pour être utilisé à l'intérieur d'un contexte d'injection. C’est pourquoi il est utilisé dans le constructeur de ExempleComponent

Si tu souhaites utiliser l'opérateur en dehors d’un contexte d’injection, tu dois lui passer explicitement le fournisseur DestroyRef. Voici un exemple :

import { takeUntilDestroyed } from '@angular/core/rxjs-interop';

@Component({
  ...
})
export class ExempleComponent implements OnInit {
  private destroyRef = inject(DestroyRef);

  ngOnInit() {
    interval(1000).pipe(
      takeUntilDestroyed(this.destroyRef)
    ).subscribe(console.log);
  }
}

En conclusions, on a vu que l’opérateur takeUntilDestroyed nous permet de complete automatiquement et simplement un observable lorsque le contexte d'appel est détruit. Cela contribue donc à éviter les fuites de mémoire et améliore l’expérience de dev en apportant un code plus lisible.

Merci d'être ici 😇 n'oublier pas de liker, commenter ou partager ça m'aide à continuer de poster du contenu 👨🏻‍💻

L’option transform des inputs Angular 🪄

Tim — Sun, 23 Jul 2023 11:56:00 +0000

Depuis Angular v16.1.0, il existe une alternative facile à l’utilisation de setter et getter pour transformer les inputs.

Le décorateur @Input inclut désormais une option de transformation qui accepte une fonction permettant de transformer l'input avant de l'affecter à l'instance du composant (ou directive).

A quoi ça sert me direz-vous ?

Voici un premier exemple pour comprendre :

Imaginons que nous ayons un composant TowerComponent qui représente une tour (une simple div avec un gris en background 😅) le composant prend en input une hauteur.

function toNumber(value: string | number) {
    return isNumber(value) ? value : parseInt(value);
}

@Component({
    standalone: true,
    selector: 'app-tower',
    template: `<div class="tower"[style.height.px]="height"></div>`,
  styles: [`
    .tower {
      background: #555;
      width: 10px;
    }
  `]
})
export class TowerComponent {
    @Input({ transform: toNumber }) height: number;
}

Alors qu'avec le pattern setter/getter on aurait eu :

export class ButtonComponent {
 @Input()
 get height() {
    return this._height;
  }
 set height(value: string | number) {
    this._height = toNumber(value)
 }
 private _height = false;
}

Plus lisible avec transform n'est-ce pas ?

La fonction de transformation toNumber se chargera de la conversion, transformant ainsi la valeur de string en nombre.

Dans le composant parent on aura :

<app-tower height="42" />

C'est pas tout, Angular fournit également des fonctions utilitaires dans @angular/core permettant de couvrir les cas d’utilisation courant :

numberAttribute
booleanAttribute

On peut donc supprimer la fonction toNumber et refactoriser notre TowerComponent en :

export class TowerComponent {
    @Input({ transform: numberAttribute }) height: number;
}

Un autre scénario où cette fonctionnalité est pratique est lors de la manipulation d'attributs HTML.

Les attributs booléens sont considérés comme vrais s'ils sont présents sur un nœud DOM et comme faux s'ils sont omis.

Cependant, Angular interprète tous les attributs statiques comme des chaînes de caractères, ce qui entraîne souvent un problème. Par exemple, le code suivant disabled renverrait une chaîne vide :

@Component({
    standalone: true,
    selector: 'app-button',
    // ... 
})
export class ButtonComponent {
    @Input() disabled: boolean;
}

<app-button disabled />

L’utilisation de l’utilitaire booleanAttribute avec l’option de transformation permet de résoudre ce problème sans utiliser le pattern setter/getter.

@Component({
    standalone: true,
    selector: 'app-button',
    // ... 
})
export class ButtonComponent {
    @Input({ transform: booleanAttribute }) disabled: boolean = false;
}

La fonction de transformation booleanAttribute s’occupe de gérer la conversion en booléen. Grâce à ça, lorsque nous utilisons le composant ButtonComponent et que nous spécifions l'attribut disabled :

<app-button disabled />

La fonction de transformation interprétera correctement la présence de l'attribut comme vrai.

Pour conclure nous avons vu que l'option de transformation dans le décorateur @Input simplifie le processus de transformation d'Input, offrant une approche qui rend notre code plus lisible par rapport à l’approche traditionnelles. L'utilisation des fonctions numberAttribute et booleanAttribute nous permet de couvrir la majorité des cas d’utilisation.