Davide Di Francesco

Vibecoding in Practice: Building SortDocs with AI

2026-03-26T00:00:00+01:00

A while ago, I started experimenting with vibecoding — building software by relying mostly on AI prompts instead of manually writing every part of the code.

My first experiment was playful: a small multiplayer 3D prototype. It was useful mostly because it showed me both sides of the workflow: AI could get me surprisingly far, but it could also break things just as quickly.

This time, I wanted to try the same mindset on something more practical.

Not a demo.
Not a toy.
A tool I could actually use.

That’s how sortdocs was born.

👉 https://github.com/davdifr/sortdocs

The Idea

Like many people, I have folders that slowly turn into chaos.

Downloads, PDFs, markdown notes, screenshots, scanned documents, text files — everything accumulates in the same place until finding anything becomes annoying.

So the idea was simple:

Could I build a tool that organizes local documents safely, using AI to understand what the files actually are?

That last part mattered a lot.

I did not want a sorter that only looks at file extensions. I wanted something that could make better decisions by using a mix of:

file content
metadata
AI-powered classification

That requirement shaped the whole project.

What SortDocs Actually Does

At a high level, the workflow is intentionally simple:

Move into the folder you want to organize
Run sortdocs .
Let the tool scan recursively and build a plan
Review the plan
Confirm the changes only if they make sense

That “plan first, apply second” approach was one of the most important parts of the project.

I didn’t want an AI tool making filesystem changes without showing its reasoning through actual proposed actions.

First Look at the CLI

Here’s what the CLI experience looks like when running a scan and reviewing the plan:

Why This Was a Better Vibecoding Test

Compared to my earlier vibecoding experiments, this project felt more realistic from the start.

A game prototype is fun, but a document organizer forces you to deal with more practical concerns:

safe file operations
ambiguity
naming collisions
bad input data
project folder protection
repeat runs

That made it a much better test of whether AI could help build something I would genuinely trust on my machine.

And trust was the key word here.

Starting with the CLI

I started from the smallest useful version: a terminal command that could analyze a target folder and propose actions.

Very early on, the shape of the product became a CLI instead of a full UI-first app. That choice made iteration faster and kept the project focused on the core pipeline:

scan → extract → classify → plan → execute

A CLI removes distractions. If the core logic works there, everything else can come later.

The Core Challenge: Understanding Files, Not Just Extensions

One of the most interesting parts of sortdocs is that it is not meant to be a dumb file sorter.

A .pdf could be:

an invoice
a manual
a contract
a scanned document
or something with almost no readable content

So the problem was never just “where should .pdf files go?”

The real question was:

How can the tool infer a reasonable destination from incomplete evidence?

That led to a more layered approach:

extract what can be extracted
use metadata where useful
classify with AI
lower confidence when evidence is weak
fall back conservatively

If the tool is uncertain, it should become more careful, not more creative.

Building Guardrails Early

This was probably the most important lesson of the whole project.

When you let AI help build a tool that touches the filesystem, guardrails are not a polish step. They are the product.

SortDocs includes:

confirmation before applying changes
rename and extension safeguards
collision handling
project-folder protection
ignore rules
conservative fallback behavior

This is where the project stopped feeling like a prototype and started feeling like real software.

Project Folder Protection

One feature I particularly like is protecting software projects by default.

If the root folder looks like a project, the tool blocks execution. Nested project folders like Git repos, node_modules, .venv, dist, and build are skipped automatically.

If the user really wants to run it anyway, they must explicitly opt in.

This is a small detail, but it says a lot about the philosophy of the tool:

It prefers being safe over being clever.

Improving Repeat Runs

Another important aspect was handling repeated usage.

Many prototypes work once but break in real-world scenarios.

SortDocs adds:

local memory to improve consistency
incremental cache for unchanged files
automatic invalidation when configs change

This means unchanged files can skip processing entirely on later runs.

Less flashy than AI — but much more useful.

Onboarding Matters More Than Expected

One thing I’ve learned is that onboarding often matters more than the core logic.

If the OpenAI API key is missing, the tool:

shows a guided setup
allows pasting the key directly in the terminal
explains how to generate it
optionally saves it locally

Without this, it feels like a repo.
With it, it feels like a product.

The Optional GUI

Originally, the project was CLI-first.

Later, it evolved into an optional macOS GUI using PySide6.

Here’s a preview of the GUI showing the planned actions before applying changes:

The GUI includes:

folder selection
API key setup
live analysis progress
preview of planned actions
detailed decision view
confirmation before applying changes

The CLI is still the core, but the GUI makes it more approachable.

Where Vibecoding Helped the Most

AI was especially helpful for:

scaffolding the CLI
iterating on logic
handling edge cases
improving UX flows
speeding up repetitive work

The biggest gains came from using it on small, well-defined problems, not from asking it to build everything at once.

Where It Still Needed Direction

AI still needed strong guidance on:

how conservative the tool should be
how to handle uncertainty
acceptable risk levels
product decisions

These are not coding problems. They are product decisions.

AI accelerates implementation — but it doesn’t replace judgment.

Final Thoughts

SortDocs ended up being a much better vibecoding experiment than I expected.

Not because it’s complex.
But because it’s useful.

It forced me to focus on something more important than generation:

reliability.

At this point, I don’t see vibecoding as “letting AI build everything.”

I see it as collaboration:

I define constraints
AI accelerates implementation
I guide the decisions
safety defines the quality

SortDocs is probably the clearest example I have so far of that balance.

It started as an experiment.
It became a real tool.

And more than anything else, it showed me this:

AI is most useful when paired with strong guardrails — not blind trust.

Vibecoding, One Year Later: Trying the Same Multiplayer Prototype Again

2026-03-16T00:00:00+01:00

A year ago, I tried a simple experiment: build a small real-time 3D multiplayer app by relying almost entirely on AI prompts instead of writing the code myself. Back then, the best setup I had for that kind of workflow was GitHub Copilot with Claude 3.7, and while the result was honestly impressive, the whole process was still pretty rough around the edges.

It worked, but it also broke in annoying ways. New features often meant new bugs, and a lot of the progress came from prompting the model again and again until things stopped falling apart.

This time, I wanted to try the same idea again with gpt 5.3-codex.

More than the final result, I was curious about the overall experience. Is it actually better now? Does it need less hand-holding? Can it make decent decisions on its own, or does it still need to be dragged through every step?

Starting from the same prompt

To keep the comparison fair, I started with almost the same prompt I used last year:

I want to create a real-time interactive 3D web application. The project should feature a simple multiplayer environment where multiple users can connect, move a 3D object in real-time, and see updates from others instantly.

The only real difference is that this time I left out the stack. Last year, I explicitly mentioned Three.js and Socket.IO in the prompt; this time I wanted to see what the model would do without that hint.

The first interesting difference

Right away, the model did something I thought was worth noting: instead of immediately generating code, it proposed two implementation paths.

One was a simple Node.js + Express + Socket.IO + Three.js setup, which it also recommended. The other was a slightly more structured option with Vite on the frontend and a separate WebSocket server.

I went with the first one, mostly because it matched the setup I had used last year anyway, when I explicitly asked for Three.js and Socket.IO. So even without me naming the tools this time, it still landed in roughly the same place.

That may sound like a small detail, but to me it already felt different. Last year, I had to define the direction. This time, the model got there on its own.

First result

The first result was also very familiar.

Just like in the original experiment, it quickly produced a minimal 3D multiplayer scene with simple player objects moving around in a shared space. If you put the two versions side by side, the overall idea is basically the same.

Still, this one felt a little more put together from the start. Not dramatically different, just cleaner.

What really stood out, though, was what happened next. Instead of stopping after the first working prototype, the model suggested a few logical next steps on its own: nicknames above players, room/lobby support, simple collisions, and even one-click deploy options.

That caught my attention because some of those were exactly the kind of things that only came later in last year’s experiment, after several additional prompts.

Letting it keep going

At that point, I decided not to over-direct it.

Instead of rewriting its plan in my own words, I just replied:

Sounds good, please go ahead with the suggested implementations.

That was intentional. I wanted to see what happened if I stopped acting like a prompt micromanager and just approved the direction.

Faster than last year

This is where the comparison started to get interesting.

After the initial prompt and that one short confirmation, the project already had player nicknames, a simple lobby flow, basic room support, lightweight collisions, deploy config for Render and Railway, and updated documentation.

That is a lot of ground to cover in basically two interactions.

In the original experiment, getting to a similar level took more back-and-forth. I had to add features one by one, deal with breakages, and keep nudging the model back into shape as new problems appeared.

This time, the prototype started to feel usable much earlier.

Adding chat

To keep the comparison going, I reused one of the same prompts from the original article:

Implement a real-time chat system with global and private messaging. The UI should feature a tabbed chat system at the bottom of the screen.

Last year, this was one of the points where things got messy. The feature itself worked, but it also came with several issues: the chat UI was not always in the foreground, the username input was awkward, typing could still move the player, and the generation even hit a time limit before I had to resend the prompt.

This time, the chat was added immediately and it worked much better right away.

The interface was already there, the basic behavior was correct, and, maybe most importantly, none of the prompts up to this point had produced actual code errors.

That changes the feel of the whole workflow more than I expected. A year ago, every new feature felt like a mix of progress and recovery. This time, it mostly just felt like progress.

What feels different

So far, the biggest improvement is not that the model is doing something completely different.

It is more that the whole loop feels less fragile.

Last year, I spent a lot of time fixing weird side effects, recovering from regressions, and re-prompting around things that had almost worked but not quite. This time, the defaults have been better, the proposed next steps have made more sense, and the implementation has been much smoother overall.

That does not mean the model can just be left alone. I am still reviewing every step, and I am still working within a fairly controlled scope. But the role feels different now. I am spending less time rescuing the process and more time deciding where to take it next.

Conclusions

Repeating the same experiment after a year has been useful for one simple reason: it removes a lot of the novelty.

Because the project is so similar, the differences are easier to notice.

The biggest one so far is reliability. In the first experiment, I could already see why vibecoding was exciting, but I also had to wrestle with it constantly to keep things moving. In this version, the model has been better at choosing a reasonable stack, suggesting sensible next steps, and implementing features without immediately creating new problems.

I would not call this autonomous software development, and I still would not trust it blindly. The project is small, the scope is controlled, and I am still the one judging every result.

But compared to where this felt a year ago, the workflow is clearly more usable.

Last year, it felt like an interesting experiment. This time, it feels a lot closer to something I could actually use on purpose.

Vibecoding: Letting AI Code for Me

2025-03-10T00:00:00+01:00

A friend recently introduced me to vibecoding—a concept where AI handles all the coding, relying solely on prompts.

Despite the obvious limitations, my curiosity as a tech enthusiast got the best of me. With social media buzzing about it, I saw an opportunity to connect with other developers and challenge myself in a new way. The idea of pushing AI to its limits without writing a single line of code was too intriguing to ignore.

Setting the Stage

Before diving in, I needed to decide on a project—something practical yet simple enough for AI to handle. I also set a few ground rules:

No manual coding—only AI-generated code.
Minimal editing—syntax fixes allowed, no major rewrites.
If AI got stuck, I had to prompt my way out.
The entire process should take no more than a couple of hours.

With that, I opened my AI coding assistant and got to work.

The Experiment

Choosing the Right Tools

I first tried Cursor, an AI-powered editor, but it felt too much like a modded VS Code. Instead, I opted for GitHub Copilot paired with Claude 3.7.

Picking a Project

Scrolling through X, I noticed many vibecoding projects focused on game development, particularly with Three.js for 3D models. That seemed like a great challenge! So, I decided to build a 3D multiplayer game with real-time interactions via Socket.IO.

First Steps

I started with this prompt:

I want to create a real-time interactive 3D web application using Three.js and Socket.IO. The project should feature a simple multiplayer environment where multiple users can connect, move a 3D object in real-time, and see updates from others instantly.

The AI generated a basic 3D cube on a plane, movable with WASD keys, and even included a user counter.

Adding a Chat System

Next, I prompted the AI to implement a real-time chat system:

Implement a real-time chat system with global and private messaging. The UI should feature a tabbed chat system at the bottom of the screen.

I worried about AI struggling with the tabbed UI, and sure enough, it hit a time limit error. I simply resubmitted the same prompt, and it picked up where it left off.

The chat worked, but had a few quirks:

The chat UI didn’t always stay in the foreground.
A misplaced username input field.
Typing in chat also moved the player (WASD issue).

Refining the Chat System

I refined my prompt to address these issues:

The chat system is functional, but I need the following fixes:

Remove any button that toggles chat visibility.

Prompt users for a username at startup instead of placing an input field in the chat.

Prevent movement while typing in chat.

Re-enable movement when clicking outside the input.

After applying fixes, I noticed a critical issue—players disappeared upon joining. So I prompted:

Fix the issue where players are not visible after entering the game.

This restored proper rendering.

Refactoring the Code Structure

The project was running from just three files—index.html, server.js, and game.js—which made maintenance difficult. I prompted AI to split the code into multiple files following best practices.

Expanding the Game Area

The playable area was too small. I asked AI to:

Expand the game area and add a boundary to prevent players from going beyond it.

It responded by:

Increasing world size from 20 to 40 units.
Adding semi-transparent boundary walls.
Restricting movement beyond limits.
Displaying a warning message near edges.
Implementing server-side validation.

Fixing Multiplayer Visibility Bug

New players weren’t visible to those already connected. I prompted:

Ensure that all connected users see new players upon joining.

This restored proper synchronization.

Implementing Player Collision

I wanted to prevent players from passing through each other:

Add a collision system so players cannot pass through each other. Ensure consistency across all clients.

This worked, but introduced a weird bug—player colors changed on collision. Additionally, colors appeared differently for each client. I fixed this with:

Keep player colors static. Ensure color consistency across all clients.

Debugging AI Mistakes

AI sometimes introduced syntax errors. At one point, I encountered this:

Uncaught ReferenceError: handleCurrentPlayers is not defined

I asked AI to review and fix it, and it successfully debugged itself.

Improving Camera Behavior

By default, the camera didn’t follow the player, making navigation frustrating. I prompted:

Ensure the camera stays centered on the player.

This small tweak greatly improved the experience.

Jump Mechanic & UI Improvements

To enhance movement, I added jumping:

Implement a jump mechanic using the space bar. Prevent infinite jumping.

Jumping worked flawlessly.

The UI also felt cluttered, so I requested:

Organize the UI:

Move the player count to the top-right.

Hide control hints behind a toggle button.

Conclusion

This experiment was surprisingly effective. While AI-generated code isn’t perfect, its ability to iterate and self-correct was impressive.

The final product could be a great base for a .IO-style multiplayer game, with mechanics like player growth and competitive elements.

The most fascinating part? This was all built in two hours. Manual coding would have taken far longer. Instead of focusing on syntax, I focused on iterating through AI-generated results.

While vibecoding has clear limitations, it’s a powerful tool for rapid prototyping. Who knows? With more improvements, it could become an even stronger development method.

Universal Middleware for Any Function

2024-10-22T20:13:00+02:00

Middleware functions are no longer limited to backend systems; they bring tremendous value to front-end applications like Angular as well. From logging and input validation to managing global states, middleware functions can significantly improve code reuse, maintainability, and readability.

In this article, we’ll dive into how you can use higher-order functions (HOFs) to create universal middleware that can be applied to any function. We’ll focus on logging as a practical example, but this pattern can be extended to countless other scenarios.

Why Middleware?

In Angular, middleware functions can be incredibly useful for:

Logging
Input validation
Handling global loading states
Automatic data saving (local/session storage)
Sanitizing inputs
Feature flags and A/B testing
Caching
Batching function calls

These are just a few examples where middleware can enhance your application’s logic without cluttering the core functionality of your code.

The Challenge: Consistent Logging

Consistent logging is essential for debugging and understanding how data flows through your application. However, maintaining logging logic across various functions can result in repetitive and hard-to-manage code.

Wouldn’t it be great if we could add logging universally, without touching every function individually? That’s where higher-order functions and middleware come to the rescue.

The Solution: Higher-Order Functions for Middleware

A higher-order function (HOF) is a function that either takes other functions as arguments or returns a function. By using HOFs, we can apply middleware (such as logging) to any function in a reusable way.

Here’s how it works:

Middleware is simply a function that wraps another function, adding extra logic before and after the original function’s execution.
applyMiddleware is a higher-order function that can apply multiple middleware functions to any given function.

Code Implementation

Let’s start with a logging middleware example:

function withLogging<T extends (...args: any[]) => any>(fn: T): T {
  return ((...args: Parameters<T>): ReturnType<T> => {
    console.log('Arguments:', args);
    const result = fn(...args);

    if (result instanceof Promise) {
      return result.then((res) => {
        console.log('Result:', res);
        return res;
      }) as ReturnType<T>;
    } else if (isObservable(result)) {
      return result.pipe(
        tap((res) => console.log('Result:', res))
      ) as ReturnType<T>;
    } else {
      console.log('Result:', result);
      return result;
    }
  }) as T;
}

Explaining `withLogging`

The withLogging function wraps any function (fn) and logs both its arguments and return value.
It handles various types of results: synchronous values, Promises, and Observables.
If the result is an Observable, we use RxJS’s tap operator to log values as they are emitted.

Now, we need a function to apply multiple middleware layers:

function applyMiddleware<T extends (...args: any[]) => any>(
  fn: T,
  ...middlewares: ((fn: T) => T)[]
): T {
  return middlewares.reduce((acc, middleware) => middleware(acc), fn);
}

Explaining `applyMiddleware`

This function takes a target function (fn) and an array of middleware functions.
It sequentially applies each middleware, effectively wrapping the original function with additional logic.

Middleware in Action

Now that we’ve set up the middleware, let’s apply it to a simple function:

function add(a: number, b: number): number {
  return a + b;
}

const addWithLogging = applyMiddleware(add, withLogging);

addWithLogging(2, 3);
// Console output:
// Arguments: [2, 3]
// Result: 5

With just a couple of lines, we’ve added logging to our add function without modifying its core logic. This is the magic of higher-order functions!

Why Use Middleware in Angular?

By introducing middleware to your Angular app, you’ll gain multiple advantages:

No More Redundant Code: Stop copying the same logging logic into every function.
Cleaner Code: Middleware allows functions to focus solely on their core purpose.
Consistent Debugging: Centralized logging ensures that you have a uniform view of data flow across your application.
DRY Principle: Centralizing logic like logging, validation, and caching reduces code duplication and simplifies maintenance.

Beyond Logging

While we’ve demonstrated logging, the possibilities for middleware in Angular are endless. You could use this pattern for:

Caching: Cache results of expensive operations.
Debouncing API calls: Delay and batch multiple calls to prevent unnecessary requests.
Error Handling: Apply global error handling without modifying each function.
Persistence: Automatically save results to local or session storage.

The key takeaway is that middleware makes your code more flexible and modular. You can enhance your functions without polluting their core logic.

Final Thoughts

Middleware is a pattern worth exploring for front-end development. By combining Angular with higher-order functions, you can implement reusable logic that will make your code cleaner, more maintainable, and scalable.

Acknowledgments

A big thank you to Roberto Heckers for his inspiration and reference code for the middleware implementation used in this article. His insights into higher-order functions have been a valuable resource for improving the way we write Angular code.

Conditional Routing in Angular with canMatch Guards

2024-10-02T20:06:00+02:00

Introduction

Routing in Angular is essential for building feature-rich, user-friendly applications. Often, we need to conditionally load different components based on user-specific data, such as access levels, subscriptions, or even preferences. Angular’s canMatch guard provides a powerful way to control which routes are accessible by dynamically matching the route based on custom logic.

In this article, we’ll explore how to use the canMatch guard in Angular, with a practical example of showing different components based on user subscription status.

What is `canMatch`?

The canMatch guard in Angular allows you to dynamically control which route should be matched based on a function’s logic. Unlike canActivate, which decides whether a route can be activated, canMatch allows you to decide whether the route itself can be matched, before it’s even considered for activation.

A Real-World Example: Premium Content Access

Let’s say we are building a video streaming platform, where some content is available only to users with a premium subscription. We want to ensure that premium users access a special component showing premium content, while regular users access a different component.

Step 1: Defining the Guard

We’ll create a guard function that checks the user’s subscription status using a SubscriptionService.

export const isPremiumUserGuard = (): canMatchFn => {
  return (route, segments) => {
    const subscriptionService = inject(SubscriptionService);
    return subscriptionService.hasPremiumAccess();
  };
};

Here, we use Angular’s inject() function to access the SubscriptionService, which checks if the user has premium access.

Step 2: Configuring the Routes

Now we set up our routes, ensuring that premium users access a PremiumContentComponent and regular users access a RegularContentComponent.

[
  {
    path: 'content',
    canMatch: [isPremiumUserGuard()],
    loadComponent: () => import('./premium-content').then(m => m.PremiumContentComponent),
  },
  {
    path: 'content',
    loadComponent: () => import('./regular-content').then(m => m.RegularContentComponent),
  }
]

In this setup:

The first route will be matched if the user is a premium subscriber.
If the user doesn’t have premium access, the router falls back to the second route, loading the regular content.

Why Use `canMatch` Instead of `canActivate`?

You might wonder why we use canMatch rather than canActivate. The key difference is that canMatch prevents the router from even considering a route if the guard returns false, while canActivate still loads the route but decides whether or not to activate it. This makes canMatch more efficient for routes that should not even be matched in certain conditions.

Conclusion

Using the canMatch guard in Angular allows you to create dynamic and flexible routing based on user-specific data. Whether you’re managing subscription access, roles, or custom preferences, canMatch gives you the power to control which components your users see, creating a smoother and more personalized experience.

Simplifying Angular Templates with combineLatest in NgRx

2024-08-16T15:00:00+02:00

When working with Angular and NgRx, a common challenge is effectively managing and combining state selectors in a clean and readable way. The combineLatest function offers a powerful solution to this problem, especially when paired with Angular’s async pipe and ng-container. This approach allows you to create more streamlined and maintainable templates, improving both readability and performance.

Understanding `combineLatest`

The combineLatest function in RxJS, which NgRx relies on, is used to combine multiple observables into one. When using it with NgRx selectors, it allows you to combine multiple pieces of state into a single observable stream, which you can then subscribe to in your components.

Here’s a basic example:

data$ = combineLatest([
  sample1: this.#store.select(sampleSelector1)),
  sample2: this.#store.select(sampleSelector2))
])

In this example, data$ is an observable that emits an object containing sample1 and sample2 whenever either selector emits a new value. This combined observable can then be used directly in your Angular template.

Leveraging `ng-conteiner` and the `async` Pipe

One of the most effective ways to use combineLatest in your Angular template is by starting with ng-container and the async pipe. This approach not only simplifies your template but also improves performance by reducing the number of async subscriptions.

Here’s how you can do it:

<ng-container *ngIf="data$ | async as data">
  <div>{{ data.sample1 }}</div>
  <div>{{ data.sample2 }}</div>
</ng-container>

The Advantage

Using combineLatest together with ng-container and the async pipe offers several benefits:

Single Subscription: By using combineLatest, you only need one async pipe in your template, which reduces the number of subscriptions and simplifies your template logic.

Clean Template: The ng-container directive allows you to directly access all the combined state selectors within a single data object, keeping your template concise and easy to read.

Improved Performance: Fewer subscriptions mean less overhead, leading to better performance, especially in complex components.

Reduced Boilerplate: Instead of managing multiple *ngIf="observable$ | async as value" directives, you only manage one, which reduces the amount of boilerplate code in your templates.

Putting It All Together

Consider a component that displays user details and preferences from two different selectors. Without combineLatest, your template might look something like this:

<div *ngIf="user$ | async as user">
  <div>{{ user.name }}</div>
</div>
<div *ngIf="preferences$ | async as preferences">
  <div>{{ preferences.theme }}</div>
</div>
By using combineLatest, you can simplify this to:
<ng-container *ngIf="data$ | async as data">
  <div>{{ data.user.name }}</div>
  <div>{{ data.preferences.theme }}</div>
</ng-container>

This approach not only looks cleaner but also scales better as your component grows in complexity.

Conclusion

Using combineLatest in combination with ng-container and the async pipe in Angular templates provides a more efficient, cleaner, and maintainable way to manage state selectors from NgRx. By adopting this pattern, you can reduce the complexity of your templates, leading to code that’s easier to read, write, and maintain. Give this approach a try in your next Angular project and experience the difference it can make in your codebase!

Stop Using console.log and Start Using This Service!

2024-06-25T13:45:00+02:00

Logging is an essential part of any software development process. It helps developers debug applications, understand workflows, and track down issues. However, relying solely on console.log for logging in an Angular application can quickly become problematic, especially when moving from development to production environments.

In this article, I will introduce a logging service that can be easily integrated into your Angular application. This service allows you to control the log level based on the environment configuration, ensuring that verbose logging is available during development but minimized or disabled in production.

Why You Should Stop Using console.log

Using console.log statements scattered throughout your codebase can lead to several issues:

Performance Issues: Excessive logging in production can degrade performance.
Security Risks: Sensitive information might be logged and exposed.
Clutter: Logs can quickly become cluttered, making it difficult to find relevant information.

By using a structured logging service, you can mitigate these issues and have more control over what gets logged and when.

Introducing the Log Service

Here’s a simple but effective logging service for your Angular application. It uses an enumerated log level to control what messages are logged based on the current environment configuration.

Log Levels Enum

First, we define an enumeration for the different log levels:

export enum LogLevel {
  info,
  error,
  warn,
  debug,
  all,
}

Log Service

Next, we create the LogService that utilizes this enum to conditionally log messages:

import { Injectable } from "@angular/core";
import { environment } from "../../environments/environment";
import { LogLevel } from "../models/log.interface";

@Injectable({
  providedIn: "root",
})
export class LogService {
  constructor() {}

  log(message?: any, ...optionalParams: any[]) {
    if (environment.logLevel >= LogLevel.debug) {
      console.log(...[message, ...optionalParams]);
    }
  }

  table(message?: any, ...optionalParams: any[]) {
    if (environment.logLevel >= LogLevel.debug) {
      console.table(...[message, ...optionalParams]);
    }
  }

  trace(message?: any, ...optionalParams: any[]) {
    if (environment.logLevel >= LogLevel.debug) {
      console.trace(...[message, ...optionalParams]);
    }
  }

  error(message?: any, ...optionalParams: any[]) {
    if (environment.logLevel >= LogLevel.error) {
      console.error(...[message, ...optionalParams]);
    }
  }

  debug(message?: any, ...optionalParams: any[]) {
    if (environment.logLevel >= LogLevel.debug) {
      console.debug(...[message, ...optionalParams]);
    }
  }

  info(message?: any, ...optionalParams: any[]) {
    if (environment.logLevel >= LogLevel.info) {
      console.info(...[message, ...optionalParams]);
    }
  }

  warn(message?: any, ...optionalParams: any[]) {
    if (environment.logLevel >= LogLevel.warn) {
      console.warn(...[message, ...optionalParams]);
    }
  }
}

Environment Configuration

Finally, we configure the environments to use different log levels:

// environment.ts (Development)
export const environment = {
  production: false,
  logLevel: LogLevel.debug
};

// environment.prod.ts (Production)
export const environment = {
  production: true,
  logLevel: LogLevel.info
};

How to Use the Log Service

To start using the LogService, inject it into your components or services:

import { Component, OnInit } from '@angular/core';
import { LogService } from './services/log.service';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent implements OnInit {
  constructor(private logService: LogService) {}

  ngOnInit() {
    this.logService.info('Application initialized');
    this.logService.debug('Debugging information');
  }
}

Conclusion

By using this LogService, you can gain better control over your logging output, ensuring that you have detailed logs in development while keeping your production environment clean and efficient. This approach not only enhances the maintainability of your application but also helps in adhering to best practices for logging in software development.

Stop scattering console.log statements in your code today and start using a structured logging service for a more robust and manageable application!

How to Create Dynamic Forms in Angular Using a Dictionary Interface

2024-06-14T18:15:00+02:00

Creating dynamic forms in Angular can be a powerful way to handle flexible data structures, especially when working with APIs that return complex or nested JSON objects. In this article, I will show you how to create dynamic forms in Angular using a Dictionary interface and a dynamic form generator service.

Defining the Dictionary Interface

First, let’s define the Dictionary interface. This interface allows us to have a recursive type that can contain either strings or nested dictionaries:

export interface Dictionary {
  [key: string]: string | Dictionary;
}

Creating the Dynamic Form Generator Service

Next, we need a service that can create form controls based on the structure of the dictionary. This service will recursively create form groups for nested dictionaries and form controls for string values.

Here is the DynamicFormGeneratorService:

@Injectable({
  providedIn: 'root',
})
export class DynamicFormGeneratorService {
  #fb = inject(FormBuilder);

  createForm(data: Dictionary): FormGroup {
    const formControls = this.createControls(data);
    return this.#fb.group(formControls);
  }

  private createControls(data: Dictionary): { [key: string]: AbstractControl } {
    return Object.keys(data).reduce((controls, key) => {
      if (typeof data[key] === 'object' && data[key] !== null) {
        controls[key] = this.#fb.group(this.createControls(data[key] as Dictionary));
      } else {
        controls[key] = new FormControl(data[key] as string, Validators.required);
      }
      return controls;
    }, {} as { [key: string]: AbstractControl });
  }
}

Creating the Dynamic Form Group Component

Now, let’s create a component that will use this service to generate a form based on the dictionary data. This component will be responsible for rendering the form and handling form submissions.

Here’s the TypeScript for the DynamicFormGroupComponent:

@Component({
  selector: 'app-dynamic-form-group',
  standalone: true,
  imports: [ReactiveFormsModule],
  templateUrl: './dynamic-form-group.component.html',
})
export class DynamicFormGroupComponent implements OnInit {
  @Output() formValues = new EventEmitter<Dictionary>();
  @Input() initialData?: Dictionary;
  @Input() formGroup: FormGroup = new FormGroup({});

  #dynamicFormService = inject(DynamicFormGeneratorService);
  objectKeys = Object.keys;

  ngOnInit(): void {
    if (this.initialData) {
      this.formGroup = this.#dynamicFormService.createForm(this.initialData);
    }
  }

  onSubmit(): void {
    if (!this.initialData || this.formGroup.invalid) return;
    this.formValues.emit(this.formGroup.value);
  }

  isGroup(control: AbstractControl | null): control is FormGroup {
    return control instanceof FormGroup;
  }

  getFormGroup(control: AbstractControl | null): FormGroup {
    return control as FormGroup;
  }
}

And the corresponding HTML template:

<form
  [formGroup]="formGroup"
  class="p-6 bg-indigo-50 border border-red-200 rounded-lg shadow-sm space-y-4"
>
  <!-- This loop iterates over the keys of the formGroup.controls object. -->
  <!-- Each key represents a form control or a nested form group. -->
  <ng-container *ngFor="let key of objectKeys(formGroup.controls)">
    <!-- This condition checks if the current form control is a FormGroup. -->
    <ng-container *ngIf="isGroup(formGroup.get(key)); else singleControl">
      <!-- If it is a FormGroup, a fieldset is created for it. -->
      <fieldset
        [formGroupName]="key"
        class="border border-gray-300 rounded-lg p-4 bg-white"
      >
        <legend class="text-lg font-semibold text-gray-700 mb-2">{{ key }}</legend>

        <!-- The nested FormGroup is passed to the component using the formGroup input property. -->
        <app-dynamic-form-group
          [formGroup]="getFormGroup(formGroup.get(key))"
        ></app-dynamic-form-group>
      </fieldset>
    </ng-container>
    <ng-template #singleControl>
      <!-- If the current form control is not a FormGroup, an input field is created for it. -->
      <!-- The formControlName directive associates this input field with the form control. -->
      <div class="flex flex-col space-y-2">
        <label [for]="key" class="text-sm font-medium text-gray-600">{{ key }}</label>
        <input
          [formControlName]="key"
          id="{{ key }}"
          class="p-2 border border-gray-300 rounded-md focus:outline-none focus:ring-2 focus:ring-indigo-500"
        />
      </div>
    </ng-template>
  </ng-container>

  <!-- This condition checks if initialData is available and adds a submit button if it is. -->
  <button
    *ngIf="initialData"
    (click)="onSubmit()"
    [disabled]="formGroup.invalid"
    class="bg-indigo-500 text-white px-4 py-2 rounded-lg hover:bg-indigo-600 disabled:opacity-50 disabled:cursor-not-allowed"
  >
    Submit
  </button>
</form>

Putting It All Together

To use this dynamic form in your application, you would typically have a parent component that provides the dictionary data and handles the form submission:

export class AppComponent {
  title = 'dynamic-forms';

  onFormValues(values: Dictionary) {
    console.table(values);
  }

  contract: Dictionary = {
    contractId: 'C12345',
    contractType: 'Employment',
    startDate: '2024-01-01',
    endDate: '2025-01-01',
    employer: {
      name: 'Tech Corp Inc.',
      address: '456 Technology Drive, Silicon Valley, USA',
      contact: {
        phone: '555-1234',
        email: 'hr@techcorp.com',
      },
    },

    jobDetails: {
      jobTitle: 'Senior Developer',
      jobDescription:
        'Responsible for developing and maintaining web applications.',
      salary: '75000',
      benefits: 'Health, Dental, Vision',
    },
  };
}

Preview

Conclusion

In this article, we have demonstrated how to create a dynamic form in Angular using a dictionary interface. By leveraging Angular’s reactive forms and a recursive approach, you can generate complex forms that adapt to any data structure. This method is particularly useful for handling dynamic data from APIs and creating flexible form components.

Streamlining Angular Route Configuration with APP_ROUTES

2024-06-09T14:50:00+02:00

Handling routes in an Angular application can get pretty tricky, especially as your project grows larger. One way to keep things simple and organized is by putting all your routes in one place using constants. This approach not only makes your code easier to read but also saves you from the headache of having to update routes scattered all over your codebase. In this article, I’ll show you how to set up this system step by step.

The Basic Approach

The simplest way to define your routes is by using a constant object where each route is a string. Here’s an example:

export const APP_ROUTES = {
  HOME: "home",
  ABOUT: "about",
  CONTACT: "contact"
};

This approach allows you to reference your routes throughout your application using APP_ROUTES.HOME, APP_ROUTES.ABOUT, etc. This is a significant improvement over hardcoding strings everywhere.

Enhancing Flexibility with Functions

While the basic approach is helpful, we can make it more powerful by using functions. This allows for more dynamic route construction, particularly useful for nested routes. Here’s how you can do it:

export const APP_ROUTES = {
  HOME: (relative = false) => `${relative ? "" : "/"}home`,
  ABOUT: (relative = false) => `${relative ? "" : "/"}about`,
  CONTACT: (relative = false) => `${relative ? "" : "/"}contact`,
};

Example Use Case: Nested Routes

Consider a scenario where you have nested routes. For example, a sample child route under the home route. Using the function-based approach, you can easily manage this:

export const APP_ROUTES = {
  HOME: (relative = false) => `${relative ? "" : "/"}home`,
  SAMPLE_CHILD: (relative = false) => `${APP_ROUTES.HOME(relative)}/sample_child`
};

With this setup, you can get the full path of SAMPLE_CHILD by calling APP_ROUTES.SAMPLE_CHILD(), and the relative path by calling APP_ROUTES.SAMPLE_CHILD(true).

Creating a Central Route Definition File

To keep your route definitions organized, create a dedicated file, app.routes.definition.ts. This file will contain all your route constants and functions.

// app.routes.definition.ts
export const APP_ROUTES = {
  HOME: (relative = false) => `${relative ? "" : "/"}home`,
  ABOUT: (relative = false) => `${relative ? "" : "/"}about`,
  CONTACT: (relative = false) => `${relative ? "" : "/"}contact`,
  SAMPLE_CHILD: (relative = false) => `${APP_ROUTES.HOME(relative)}/sample_child`
};

Benefits of This Approach

Simplified Route Management

By centralizing your route definitions, you reduce the risk of inconsistencies and errors. If a route changes, you only need to update it in one place.

Cleaner Code

When you use routes in your components or services, your code is cleaner and more readable. For example:

navigateToHome() {
  this.router.navigate([APP_ROUTES.HOME()]);
}

Easier Refactoring

If you need to change a route, such as renaming home to dashboard, you can simply update the APP_ROUTES object. The change will propagate throughout your application, minimizing the need for extensive search-and-replace operations.

Conclusion

Configuring routes in Angular doesn’t have to be a daunting task. By centralizing your route definitions in one file and using constants and functions, you can keep your application organized and your code easy to maintain. This method simplifies updates and reduces the risk of errors, ensuring your app runs smoothly even as it grows.

Give this approach a try in your next Angular project. You’ll find that managing your routes becomes a lot less stressful and a lot more efficient.

Structuring Your Angular Project for Scalability and Maintainability

2024-02-19T13:50:00+01:00

In the world of Angular development, structuring your project can significantly influence the scalability and maintainability of your application. A well-thought-out folder structure ensures that your code is organized, clean, and intuitive, making it easier for you and your team to navigate and extend the project. In this article, we will explore an effective way to structure an Angular project, focusing on a folder setup that caters to projects of varying sizes and complexities.

Overview

Before we dive into the specifics, it’s crucial to understand the importance of segregating your project into logical units. This not only helps in isolating functionalities but also in adhering to Angular’s modular architecture. The proposed structure is as follows:

components/

dumb-components/

containers/

pages/

shared/

interceptors/

store/

Let’s break down each of these directories to understand their purpose and contents.

`components/`

This directory houses the reusable components of your application. These are the building blocks that you’ll use across different parts of your application. Keeping them in a dedicated components/ folder makes it easy to locate and reuse them.

`dumb-components/`

Dumb components, or presentational components, are those that do not depend on external services or direct data manipulations. They receive data through inputs and communicate through outputs. Segregating them into a dumb-components/ folder emphasizes their role in your application’s UI without cluttering the logic-heavy components.

`containers/`

Containers are components that are aware of the application state and handle data fetching, state management, and interaction with services. They serve as the glue between your presentation components and services. Organizing them in a containers/ directory helps in distinguishing them from dumb components and streamlines state management.

`pages/`

The pages/ directory contains components that are tied to your routing. Each component here represents a different page within your application, making it straightforward to understand your application’s structure at a glance.

`shared/`

Shared resources such as services, decorators, and directives that are used across different parts of your application are kept in the shared/ directory. This directory often includes sub-folders like services/, decorators/, and directives/ to further organize these shared resources.

`interceptors/`

Interceptors are a powerful feature in Angular that allow you to intercept incoming or outgoing HTTP requests and responses. Keeping them in an interceptors/ directory centralizes your interceptors, making them easy to manage.

`store/`

For state management, especially when using libraries like NgRx, the store/ directory contains your actions, reducers, effects, and selectors. A typical structure inside this directory might look like:

store/
  sample/
    sample.actions.ts
    sample.effects.ts  
    sample.reducer.ts  
    sample.selectors.ts

This setup provides a clear overview of your state management strategies and how they relate to different components in your application.

Conclusion

Structuring your Angular project using the outlined folder structure provides a solid foundation for building scalable and maintainable applications. By organizing your codebase logically, you make it easier for developers to navigate, understand, and contribute to the project. As you grow your application, this structure can adapt to accommodate new features and modules, ensuring that your project remains well-organized and efficient.

Enhancing Angular Navigation with GlobalKeydown: A Guide to Keyboard-Driven Routes

2024-01-18T10:20:00+01:00

Introduction to GlobalKeydownService

Angular’s flexibility allows us to extend our application’s functionality with custom services. In this case, we’ll create GlobalKeydownService. This service listens to global keydown events and filters out those triggered within input elements - ensuring that typing in a text field does not inadvertently trigger navigation.

The Service Code

import { Injectable } from '@angular/core';
import { fromEvent, Observable } from 'rxjs';
import { filter, map } from 'rxjs/operators';

@Injectable({
    providedIn: 'root',
})
export class GlobalKeydownService {
    keydownEvents$: Observable<string>;

    constructor() {
        this.keydownEvents$ = fromEvent<KeyboardEvent>(window, 'keydown').pipe(
            filter((event) => !(event.target instanceof HTMLInputElement)),
            map((event) => event.key)
        );
    }
}

This service uses RxJS’s fromEvent to listen for keydown events on the window object, and then processes these events to output only the relevant key values.

Integrating GlobalKeydownService with NavbarComponent

With GlobalKeydownService in place, we can now modify NavbarComponent to listen to keydown events and navigate accordingly.

import { Component, inject, OnInit } from '@angular/core';
import { Route, RouterModule } from '@angular/router';
import { NavigationService } from '../../shared/services/navigation.service';
import { GlobalKeydownService } from '../../shared/services/global-keydown.service';
import { Subject, takeUntil } from 'rxjs';

// ... Component Code ...

export class NavbarComponent implements OnInit {
    // ... Existing properties ...
    #keydown = inject(GlobalKeydownService);
    #destroy$ = new Subject();

    ngOnInit(): void {
        // ... Existing initialization code ...

        this.#keydown.keydownEvents$
            .pipe(takeUntil(this.#destroy$))
            .subscribe((key) => {
                this.navigateByKey(key);
            });
    }

    private navigateByKey(key: string): void {
        const index = parseInt(key, 10) - 1;
        if (index >= 0 && index < this.routes.length) {
            this.#navigation.navigateTo(this.routes[index].path as string);
        }
    }

    // ... Remaining component code ...
    ngOnDestroy(): void {
        this.#destroy$.next(true);
        this.#destroy$.complete();
    }

}

In this updated component, we are subscribing to the keydownEvents$ observable from GlobalKeydownService. When a key is pressed, navigateByKey method is called, which checks if the pressed key corresponds to a valid route index and, if so, triggers navigation to that route.

Conclusion

By integrating GlobalKeydownService with our navbar component, we’ve added a layer of keyboard-driven navigation to our Angular application. This approach not only enhances user experience by providing a quicker navigation method but also contributes to the accessibility of the application.

A Fresh Take on Angular Session Management: Introducing SessionManagementService

2024-01-12T13:00:00+01:00

Introduction

This service focuses on maintaining a single active session in a multi-tab environment, enhancing the user experience and application efficiency. It started as an experiment, a simple concept to improve session management. To my surprise, the outcome was quite intriguing. This has motivated me to share it with the community. It’s possible that it could be useful to others, or at the very least, it might spark new use cases or ideas among fellow developers.

Service Overview

SessionManagementService utilizes Angular’s dependency injection and the power of RxJS for reactive programming. Its main goal is to identify and manage multiple instances of the same application in different browser tabs, ensuring a coherent and focused user interaction.

Key Features:

Multi-Tab Session Detection: Detects when the same application is opened in multiple tabs.

Session State Management: Keeps only the most recent session active.

Reactive Event Handling: Responds to browser events, maintaining up-to-date session states.

Service in ActionTechnical Insights

The service’s functionality revolves around event listeners for browser activities. These listeners help in coordinating session states across tabs, essential for maintaining a consistent user experience.

Code Functionality

Unique Session IDs: Each tab generates a unique session ID. The service tracks these IDs to identify the active sessions.

private createNewSessionId(): string {
    return Date.now().toString();
}

Browser Event Listeners: The service listens to storage and beforeunload events to manage session updates and cleanup.

private setupStorageEventListener(): void {
    window.addEventListener('storage', (event: StorageEvent) => {
        this.storageEventSubject.next(event);
    });
}

Determining the Active Session: The service checks if the current tab is the active session, differentiating the user experience based on session activity.

isCurrentSessionActive(): boolean {
    const sessions = this.getSessionsFromStorage();
    return sessions[sessions.length - 1] === this.#currentSessionId;
}

Complete Code Listing

import { Injectable } from '@angular/core';
import { BehaviorSubject, fromEvent } from 'rxjs';

@Injectable({
  providedIn: 'root',
})
export class SessionManagementService {
  storageEventSubject = new BehaviorSubject<StorageEvent | null>(null);

  #currentSessionId: string = '';
  #sessionIds: string[] = [];

  constructor() {
    this.setupStorageEventListener();
    this.#currentSessionId = this.createNewSessionId();
    this.#sessionIds = this.getSessionsFromStorage();

    if (this.#sessionIds.length) {
      this.#sessionIds.push(this.#currentSessionId);
      this.setSessionsToStorage(this.#sessionIds);
    } else {
      this.initializeFirstSession();
    }

    fromEvent(window, 'beforeunload').subscribe(() => {
      const sessions = this.getSessionsFromStorage().filter(
        (session) => session !== this.#currentSessionId
      );
      this.setSessionsToStorage(sessions);
    });
  }

  private setupStorageEventListener(): void {
    window.addEventListener('storage', (event: StorageEvent) => {
      this.storageEventSubject.next(event);
    });
  }

  private createNewSessionId(): string {
    return Date.now().toString();
  }

  private initializeFirstSession(): void {
    this.#sessionIds.push(this.#currentSessionId);
    this.setSessionsToStorage(this.#sessionIds);
  }

  isCurrentSessionActive(): boolean {
    const sessions = this.getSessionsFromStorage();
    return sessions[sessions.length - 1] === this.#currentSessionId;
  }

  private getSessionsFromStorage(): string[] {
    const sessionsInStorage = localStorage.getItem('sessions');
    return sessionsInStorage ? JSON.parse(sessionsInStorage) : [];
  }

  private setSessionsToStorage(sessions: string[]): void {
    localStorage.setItem('sessions', JSON.stringify(sessions));
  }
}

Potential Use Cases

The service is ideal for applications where efficient session management and a focused user experience across multiple tabs are important.

Concluding Thoughts

SessionManagementService is an experimental concept, aiming to offer a new approach to session management in web applications. It’s a starting point to experiment and adapt in various contexts.

Theme Switcher in Angular: From Dark to Light and Back Again

2024-01-09T15:30:00+01:00

Introduction

Offering a choice between light and dark modes in web applications enhances user experience and accessibility. In this article, we’ll explore how to create a dynamic theme switcher in Angular, using a service and a component. Let’s dive into the code!

Understanding the ThemeService

At the core of our theme-switching feature is the ThemeService. This service manages the theme state and applies the appropriate styles.

import { Injectable, WritableSignal, effect, signal } from "@angular/core";

export const storageKey = "theme";

@Injectable({
  providedIn: "root",
})
export class ThemeService {
  #path: string = "/assets/themes";
  #stylesheet: HTMLLinkElement | null = document.getElementById(
    "theme"
  ) as HTMLLinkElement;

  themeSignal: WritableSignal<string> = signal<string>("light");

  constructor() {
    this.initializeThemeFromPreferences();

    effect(() => {
      this.updateRenderedTheme();
    });
  }

  toggleTheme(): void {
    this.themeSignal.update((prev) =>
      this.isDarkThemeActive() ? "light" : "dark"
    );
  }

  private initializeThemeFromPreferences(): void {
    if (!this.#stylesheet) {
      this.initializeStylesheet();
    }

    const storedTheme = localStorage.getItem(storageKey);

    if (storedTheme) {
      this.themeSignal.update(() => storedTheme);
    }
  }

  private initializeStylesheet(): void {
    this.#stylesheet = document.createElement("link");
    this.#stylesheet.id = "theme";
    this.#stylesheet.rel = "stylesheet";

    document.head.appendChild(this.#stylesheet);
  }

  getToggleLabel(): string {
    return `Switch to ${this.isDarkThemeActive() ? "light" : "dark"} mode`;
  }

  isDarkThemeActive(): boolean {
    return this.themeSignal() === "dark" ? true : false;
  }

  private updateRenderedTheme(): void {
    if (this.#stylesheet) {
      this.#stylesheet.href = `${this.#path}/${this.themeSignal()}.css`;
    }

    localStorage.setItem(storageKey, this.themeSignal());
  }
}

This service initializes the theme based on user preferences, manages theme toggling, and dynamically updates the stylesheet link.

Building the ThemeToggleComponent

The user interacts with the ThemeToggleComponent to change the theme. It’s a standalone Angular component with a simple yet effective UI.

import { Component, inject } from "@angular/core";
import { ThemeService } from "../../shared/services/theme.service";

@Component({
  selector: "app-theme-toggle",
  standalone: true,
  imports: [],
  template: `
    <input
      id="theme-toggle"
      type="checkbox"
      [checked]="isDarkThemeActive()"
      (change)="switchTheme()"
      [attr.aria-label]="getThemeToggleLabel()"
    />
  `,
})
export class ThemeToggleComponent {
  #theme: ThemeService = inject(ThemeService);

  switchTheme(): void {
    this.#theme.toggleTheme();
  }

  isDarkThemeActive(): boolean {
    return this.#theme.isDarkThemeActive();
  }

  getThemeToggleLabel(): string {
    return this.#theme.getToggleLabel();
  }
}

This HTML template includes a checkbox that toggles the theme when clicked.

How They Work Together

The synergy between ThemeService and ThemeToggleComponent is what makes the theme switching smooth and effective:

User Action: When a user clicks the theme toggle checkbox, ThemeToggleComponent calls toggleTheme from ThemeService.
State Update: ThemeService updates the themeSignal, which triggers a change in the theme.
Dynamic CSS Update: ThemeService then changes the href of the stylesheet link, loading the appropriate theme CSS.
Persistence: The new theme preference is stored in local storage for future sessions.

Switcher in actionConclusion

Implementing a theme switcher in Angular is not just about aesthetics; it’s about enhancing user experience and accessibility. With ThemeService and ThemeToggleComponent, you can offer a dynamic and responsive theme-switching feature in your Angular applications.

Dynamic Navigation in Angular: Building a Navbar Using Route Configurations

2024-01-04T18:00:00+01:00

Introduction

In modern web applications, navigation plays a critical role in guiding users through the interface. Angular, a popular front-end framework, offers robust tools for managing routes and navigation. This article delves into how Angular can dynamically build a navigation bar (navbar) based on route configurations. We’ll explore an implementation that uses Angular’s routing mechanism to populate a navbar component with links to different pages in the application.

Understanding the Core Files

Our implementation involves three key files: nav.service.ts, navbar.component.ts, and app.routes.ts. Let’s break down each file to understand their roles.

nav.service.ts:

@Injectable({ providedIn: "root" })
export class NavigationService {
  private router = inject(Router);
  
  getNavigationRoutes(): Route[] {
    return this.router.config
    .flatMap((route) => [route, …(route.children || [])])
    .filter((route) => route.data?.["showInNavbar"]);
  }
}

Purpose: This service file is responsible for retrieving the routes that should be displayed in the navbar.

Implementation: It uses Angular’s Router service to access the application’s route configurations. The function getNavigationRoutes() filters these routes, selecting only those marked with a data["showInNavbar"] property. This approach allows us to specify which routes appear in the navbar directly within the route configuration.

navbar.component.ts:

@Component({
  selector: "app-navbar",
  template: `
    <nav aria-label="Main navigation">
      <ul>
        @for (route of routes; track $index) {
          <li>
            <a routerLink="{{ route.path }}">{{ route.data?.['title'] }}</a>
          </li>
        }
      </ul>
    </nav>`
})
export class NavbarComponent {
  private navigation = inject(NavigationService);

  routes: Route[] = [];

  ngOnInit(): void {
    this.routes = this.getRoutes();
  }

  private getRoutes(): Route[] {
    return this.navigation.getNavigationRoutes();
  }
}

Purpose: This component file represents the visual element of the navbar in the application.

Implementation: It imports NavigationService to access the filtered routes. The component’s template uses Angular’s structural directives to iterate over these routes and dynamically create navigation links. This setup ensures that the navbar reflects the current route configuration of the application.

app.routes.ts:

export const routes: Routes = [
  {
    path: "first-page",
    data: { title: "First Page", showInNavbar: true }
    // other properties...
  },
  // other routes...
];

Purpose: This file defines the routes of the application.

Implementation: Each route object includes the path, component, and any child routes. Notably, routes meant for the navbar have a data property with showInNavbar: true. This design simplifies route management and makes the navbar’s content easily adjustable by modifying the route configurations.

Bringing It All Together

The interaction between these files creates a cohesive navigation system. When the application initializes, NavbarComponent fetches the routes from NavigationService, which in turn retrieves and filters them from the Angular Router. As a result, the navbar dynamically adjusts to changes in the route configuration, making the application more modular and easier to maintain.

Conclusion

Angular’s routing system provides a powerful way to manage navigation in web applications. By integrating services, components, and route configurations, developers can create dynamic, responsive navigation structures like the navbar we’ve explored. This approach enhances the scalability and maintainability of Angular applications, allowing for more efficient development workflows.

Creating an NFT Credential

2023-02-09T11:38:26+01:00

The NFTs created in the proposed solution are compliant with the ERC721 standard and can be created directly through Etherscan (the official Ethereum blockchain explorer). Additionally, like any other NFT of this standard, they can be viewed and read on any platform that interacts with these smart contracts. The creation of a new digital credential through Etherscan appears as follows:

At this point, it is not necessary to have any coding experience to proceed. All you need to do is connect the contract owner’s wallet and fill out the form to create and send the recipient their digital credential.

Once the token is released, the recipient can share their wallet address, allowing it to be easily found using various blockchain exploration tools, including Etherscan, where information about the token can be viewed.

Sharing the transaction details can also be sufficient to view the attributes of the issued NFT.

Of course, this is not a practical way to share the credential. It is recommended to use the OpenSea platform instead, which in addition to providing an address for viewing on their site, also provides an embed code.

Moreover, it is possible to build various web applications using the web3js library, which allows interaction with smart contracts.

A possible example, which will be demonstrated in the form of a demo, is the potential use of these credentials as a form of login to a platform.

1. Checking User Address

var web3 = new Web3(
  "https://goerli.infura.io/v3/22a66e24f1fb47599e326320feb4b424"
);

const tokenContractAddress = "0x6c3C2C3ad1D11B518e132Ea794c6c796D51af2Ee";

Creating an instance of the Web3 class and connecting to an Infura node and we are defining a constant variable for the smart contract address that we will be interacting with.

let userAddress = "";
async function checkUserAddress() {
  if (ethereum) {
    try {
      userAddress = (await ethereum.enable())[0];
    } catch (error) {
      console.error(error);
    }
  }
}

Create a variable called userAddress and initialize it as an empty string.

Next, we have an asynchronous function called checkUserAddress. This function first checks if the ethereum object is available, and if it is, it enables access to wallet information using the ethereum.enable() method.

The first account in the resulting array is then assigned to the userAddress variable. If an error occurs, it will be logged in the console.

Upon opening the page, the user will be prompted to connect their wallet first, thanks to this code.

2. Logging into the platform via contract interaction

We manage a login interface that handles two scenarios: the wallet owner doesn’t have any tokens issued by our contract, and the owner has one or multiple tokens, the details of which are also displayed.

When the button is clicked, it performs the following actions:

btn.addEventListener('click', async () => {
	const tokenContract = new web3.eth.Contract(abi, tokenContractAddress);
	const balance = await tokenContract.methods.balanceOf(userAddress).call();
	if (balance > 0) {
		...
    msg.textContent = 'There is at least one NFT in your wallet from this contract';
		...
	} else {
		...
		msg.textContent = 'There are no NFTs in your wallet created by this contract';
	}
  ...

Creates a new instance of a smart contract using the Ethereum JavaScript library web3.js and its Contract object.
Calls the balanceOf method on the smart contract instance and checks if the returned balance is greater than 0.

If the balance is equal to or less than 0, the “msg” element is set to “There are no NFTs in your wallet created by this contract”.

If the balance is greater than 0, the “msg” element is set to “There is at least one NFT in your wallet from this contract”.

Additionally:

const tokens = await tokenContract.methods.walletOfOwner(userAddress).call();
const tokenMetadataPromises = tokens.map(tokenId => {
	return tokenContract.methods.metadata(tokenId).call();
});

const tokenMetadatas = await Promise.all(tokenMetadataPromises);
tokenMetadatas.forEach(metadata => {
	...
});

Calls the walletOfOwner method on the smart contract instance to get an array of tokens owned by a specific user address.
Maps over the array of tokens and calls the metadata method on the smart contract instance for each token to retrieve its metadata.
Waits for all metadata requests to complete and stores the results in an array.
Iterates over the array of metadata, creating HTML elements for the owner name, title, and description of each token and appending them to the “details” element.

Creating a Graphic Appearance

NFTs commonly come with an image that serves as a visual representation. However, the current on-chain metadata structure doesn’t support the inclusion of images. Fortunately, we can utilize an off-chain solution through IPFS to resolve this limitation.

IPFS (InterPlanetary File System) is a decentralized and distributed file storage system that is designed to enhance the speed, safety, and openness of the web. Unlike traditional server-based file storage, IPFS leverages a peer-to-peer network of computers to store and access files, leading to faster and more resilient file sharing. This technology is often integrated with blockchain technology to build decentralized applications and to store and transfer digital assets such as NFTs.

Two files will need to be stored using an IPFS service: the image we want to assign to the token, and the JSON file containing the desired metadata.

{
  "name": "Digital Credential",
  "description": "On-chain Digital Credentials through NFTs.",
  "image": "ipfs://QmNgdypgjW79BNj1aADctMakZGJqbjiTbKDyWC97smcXg8"
}

The JSON file will in turn have the IPFS link that has been assigned to the image inside it.

The final step is to call the setBaseURI function of the contract, providing the IPFS address of the JSON file as input. From this moment on, the graphical representation of the token will be visible on any platform. Here is an example on OpenSea:

On-chain Digital Credentials through NFTs

2023-01-11T11:57:26+01:00

The proposed contract is built on the ERC721 standard, which allows for the creation of unique, non-fungible tokens (NFTs) on the Ethereum blockchain.

The goal of this implementation is to create NFTs that represent digital credentials, with all aspects of these credentials being implemented on the blockchain. To achieve this, a custom data structure called NFTMetadata was implemented.

struct NFTMetadata {
  string name;
  string title;
  string description;
  address wallet;
}

The NFTMetadata structure contains important information about the digital credential, such as the name, title, and description of the credential. Additionally, it also stores the wallet address of the original recipient of the credential. This allows for easy identification of whether or not the NFT has been transferred to a different wallet and thus, whether or not the current holder is the true and original recipient of the credential.

It is also possible to add a referenceId field that can be used to store the id of the certificate/credential already issued on a private storage system.

...
string referenceId,
...

In this way, on-chain storage of the NFTMetadata ensures the authenticity and integrity of the digital credentials represented by the NFTs.

Mapping token ID to metadata

In addition to the NFTMetadata structure, the contract also uses a mapping to associate each individual NFT with its corresponding metadata. The mapping is declared as follows:

mapping(uint256 => NFTMetadata) public metadata;

This creates a mapping from token ID to NFTMetadata.

Each NFT is identified by a unique token ID, which is of the type uint256. This ID is used as the key in the mapping to access the metadata associated with that particular NFT.

When a new NFT is created and minted, an entry is added to the mapping with the token ID as the key and an instance of the NFTMetadata structure as the value. This allows the contract to easily look up the metadata associated with a given NFT, simply by using its token ID as the key in the mapping.

This is how the contract links the data stored on the NFT with the metadata that allow the verification and understanding of the NFT.

For example if someone want to access the metadata of the NFT, with id equals to 100, it can just access the metadata[100].

The mint function

The mint function is a crucial part of our NFT contract, and it allows the creation of new non-fungible tokens and their assignment to a specific recipient.

function mint(
	string memory _name,
	string memory _title,
	string memory _description,
	address _recipient
) public onlyOwner {
	uint256 supply = totalSupply();
	uint256 tokenId = supply + 1;
	require(!paused);
	metadata[tokenId] = NFTMetadata(_name, _title, _description, _recipient);
	_safeMint(_recipient, tokenId);
}

First, only the contract owner has the permission to execute this function, this is achieved by using the keyword onlyOwner. This measure guarantees that only authorized parties can create new NFTs, providing a higher level of security.

The function receives four parameters: _name, _title, _description and _recipient, these parameters are used to create an instance of the NFTMetadata struct, which stores the metadata associated with the NFT, including information such as name, title and description, and the address of the recipient.

The metadata is then associated with the tokenId generated, which is calculated as the totalSupply + 1. This provides a unique and incremental tokenId for each NFT minted.

Additionally, the function contains a require(!paused) statement, which ensures that the creation of new NFTs can only take place when the contract is not paused, this is an important security measure.

Finally, the function uses the _safeMint function, which is a helper function that guarantees that the NFT is minted and assigned to the correct recipient, avoiding security vulnerabilities.

Overall, the mint function is a robust and secure mechanism for creating new NFTs and assigning them to specific recipients, by using this function, we have ensured that the NFTs minted by our contract are unique, incremental, and properly assigned to their intended recipients, providing a high degree of trust and transparency.

Hands-on Foo contract

2022-11-14T18:50:26+01:00

This article aims to give a complete overview of how to compile, deploy and test a smart contract. All the required tools are presented step by step to illustrate the necessary development environment setup.

Prerequisites

sc-boilerplate (https://github.com/davdifr/sc-boilerplate)
Node.js (https://nodejs.org/en/)

Creating a Test Wallet

MetaMask is a software wallet for cryptocurrencies used to interact with the Ethereum blockchain. It allows users to access their Ethereum wallet via a browser extension or mobile app, which can then be used to interact with decentralized applications.

*Note: If you already have your own MetaMask wallet, you should create a new one for security reasons.

Using Google Chrome as a browser, Metamask is avaiable in the chrome web store. Follow the instructions to create your wallet and write down the 12 words that make up the secret recovery phrase, because they will be needed later for the deploy part.

As a test, it shouldn’t be on the Ethereum mainnet, but on a testnet, specifically the Goerli testnet. The following part shows how to change the selected network:

On the top right of the MetaMark interface click on Ethreum Mainnet;
Click on Show/hide test networks;

Enable “Show test networks”;

Go back and select “Goerli test network”.

Now the wallet is ready to interact with the Goerli test network. Since funds are required for each transaction, you can receive GoerliETH tokens through these links:

Copy and paste the wallet address from MetaMask on one or both the previous website to get 0.2 or 0.1 GoerliETH.

Installing the required packages

Thanks to Node.js the boilerplate can work properly with the required packages.

"@truffle/hdwallet-provider": "^1.5.1",
"ganache-cli": "^6.12.2",
"mocha": "^9.1.2",
"solc": "^0.8.9",
"web3": "^1.6.0"

🚨 All packages can be installed automatically with npm install in the project folder, because they are already specified in the package.json.

Required packages are listed below with a brief description:

@truffle/hdwallet-provider - HD Wallet-enabled Web3 provider. It is necessary to use the wallet in the deploy.js file. The first "" must be filled with the 12 words that form the secret recovery phrase of the MetaMask wallet, the second with the Infura endpoints, which will be explained later.
```
provider = new HDWalletProvider(
  "", // Wallet secret recovery phrase
  "" // Infura endpoints
);
```
The hdwallet-provider also allows you to select which wallet account should be used to perform the action.
```
...
const accounts = await web3.eth.getAccounts(); // Get all the accounts in the wallet
...
    .send({ gas: "1000000", from: accounts[0] }); // Send the transaction from the first account
...
```
ganache-cli - Ganache CLI uses ethereumjs to simulate full client behavior and make Ethereum application development faster, easier, and more secure. Ganache CLI is needed to test the smart contract without deploying it on a real blockchain (test or mainnet). Required in test/Foo.test.js .
```
const assert = require("assert");
const ganache = require("ganache-cli");
const Web3 = require("web3");
const web3 = new Web3(ganache.provider());
```

mocha - Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple. Mocha provide the following functions (used in test/Foo.test.js):

Function	Purpose
it	Run a test and make an assertion.
describe	Groups togheter ‘it’ functions.
beforeEach	Execute some general setup code before each test.

solc - JavaScript bindings for the Solidity compiler.
web3 - Web3.js is a collection of libraries which allow you to interact with a local or remote ethereum node, using a HTTP or IPC connection.

Foo Smart Contract

The boilerplate contains a simple smart contract named Foo.sol with the following code:

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.9;

contract Foo {
    string public message;

    constructor(string memory defaultMessage) {
        message = defaultMessage;
    }

    function setMessage(string memory newMessage) public {
        message = newMessage;
    }
}

As we can see, this smart contract is really simple and clear, it contains a string that we set with the constructor function when we deploy the contract, and a function that allows us to change the string. A basic smart contract like this is clearly good for understanding the process of deploying and testing.

Local deployment

The Foo.test.js first simulates the deployment in a local Ethereum chain (thanks to Ganache) with the string value "This is a real foo contract, not smart at all." passed in the constructor:

beforeEach(async () => {
  accounts = await web3.eth.getAccounts();
  foo = await new web3.eth.Contract(abi)
    .deploy({
      data: evm.bytecode.object,
      arguments: ["This is a real foo contract, not smart at all."],
    })
    .send({ from: accounts[0], gas: "1000000" });
});

deploy details…

And then (using Mocha) tests if the contract is successfully deployed, the default message is present as expected, and also tests the setMessage function by passing another string to check if it changes correctly.

describe("Foo", () => {
  it("Contract deployed successfully.", () => {
    assert.ok(foo.options.address);
  });
  it("Default message correctly setted.", async () => {
    const message = await foo.methods.message().call();
    assert.equal(message, "This is a real foo contract, not smart at all.");
  });
  it("setMessage function works properly.", async () => {
    await foo.methods
      .setMessage("The foo has been changed.")
      .send({ from: accounts[0] });
    const message = await foo.methods.message().call();
    assert.equal(message, "The foo has been changed.");
  });
});

In the project folder, a test can be run with npm run test and the output will look like the following:

If the three tests are passed, the smart contract works as expected and can be deployed in a real blockchain (test or mainnet).

Deployment on the Goerli testnet

After testing, the contract is ready to be deployed on the Goerli test network. To accomplish this task, we need a provider instead of Ganache that will allow us to communicate and interact with the real blockchain. After an account is created on https://www.infura.io/, a new key can be generated.

Next, Goerli testnet can be selected and finally a url endpoint can be received for deployment.

The endpoint must be inserted in the deploy.js file, as previously described:

provider = new HDWalletProvider(
  "birth hour hundred tuna confirm stove busy laugh initial spy sock start", // Wallet secret recovery phrase
  "https://goerli.infura.io/v3/ca6a6e33f51643fca72535c93625932a" // Infura endpoints
);

Finally, the Foo smart contract can be deployed by running node deploy.js, displaying the contract address as in the following image:

Once you have received the address of the smart contract, the process is complete and the contract is actually on the chain.

Contract verification with Etherscan

The Foo Smart Contract is located in the Goerli test network and is visible to everyone via the blockchain explorer https://goerli.etherscan.io.

The source code can be viewed by clicking on the “Contract” section;

The “Read Contract” section contains the message that was set in the deployment phase;

And the “Write Contract” section allows (through connection with MetaMask) the use of the setMessage function.

Deploy details

The deploy function also requires the bytecode (evm.bytecode.object) of the smart contract generated by solc (the Solidity compiler) to be interpreted by the Ethereum Virtual Machine. Obviously the bytecode isn’t human readable, for clarity and better understanding of the compilation process a console.log(module.exports); can be added to the end of the compile.js file. After running node compile, the ABI (which defines the methods and structures for interacting with the binary contract) and the bytecode can be viewed and look like this:

After the deploy() function, there is a send() function.

...
	.send({ from: accounts[0], gas: "1000000" });
...

Since each Ethereum transaction requires computational resources to be executed, there is a fee. Gas refers to the fee required to successfully complete a transaction on Ethereum and is expressed in Gwei. The gas parameter sets a limit of Gwei that the sender allows to process the transaction.

Wei is the smallest denomination of ether in Etheruem. One ether is one quintillion or 10^18 weis. The following table is a list of the named denominations and their value in wei:

Unit	Wei Value	Wei
wei	1 wei	1
Kwei (babbage)	10^3 wei	1,000
Mwei (lovelace)	10^6 wei	1,000,000
Gwei (shannon)	10^9 wei	1,000,000,000
microether (szabo)	10^12 wei	1,000,000,000,000
milliether (finney)	10^15 wei	1,000,000,000,000,000
ether	10^18 wei	1,000,000,000,000,000,000

References

Ethereum and Solidity: The Complete Developer’s Guide - Created by Stephen Grider

Blockchain introduction

2022-10-24T18:36:00+02:00

On October 31, 2008, Satoshi Nakamoto published a white paper entitled “Bitcoin: A peer-to-peer electronic cash system”, in which he described a system that would enable P2P payments without a financial intermediary.

The blockchain is a P2P transaction model that enables two parties to transact in a temper-resistant and cryptographically proven way. Essentially, it relies on three pillars: peer-to-peer networks, cryptography, and a consensus mechanism.

Each computer participating in this P2P network is called a node. Each node stores records of transactions in multiple consecutive blocks. Once all nodes in the network have stored and verified a transaction, it is impossible to change the transaction without changing all subsequent and previous blocks. For this reason, blockchain transactions are irreversible, as blockchain transactions and their data are only appended.

Blocks are connected by a link (also called a chain). The link between two blocks (Figure 1) is implemented by recording the previous block’s cryptographic hash so that it can be visited in reverse chronological order.

The following table shows the data structure for a block header (in Bitcoin):

Field	Purpose	Updated when…	Size (Bytes)
Version	Block version number	You upgrade the software	4
hashPrevBlock	256-bit hash of the previous block header	A new block comes in	32
hashMerkleRoot	256-bit hash based on all of the transactions in the block	A transaction is accepted	32
Time	Current timestamp as seconds	Every few seconds	4
Bits	Current target in compact format	The difficulty is adjusted	4
Nonce	32-bit number (starts at 0)	A hash is tried (increments)	4

In particular, hashPrevBlock refers to the 256-bit hash value of the previous block, and hashMerkleRoot is the hash Merkle root of all transactions in the block, including coinable transactions. And the nonce is the magic number that miners must find so that the SHA-256 hash value of the block header is smaller than or equal to the blockchain-defined specific target.

Transaction process overview

Assuming user A wants to buy something from user B (Figure 2) and agrees to pay B 10 Bitcoins (BTC), the transaction proceeds as follows:

Create blockchain transactions: A transaction is a transfer of value between two parties. When A sends 10 BTC to B, a transaction is created with one or more inputs and outputs, where the inputs reflect A’s account and the outputs reflect the accounts A wants to transfer. The transaction is digitally signed with A’s private key and broadcasted to the P2P network. The recipient uses the digital signature to verify ownership of A’s funds.
Validate the transactions and add them to the transaction pool: Once the transaction is submitted to the blockchain network, the bookkeeper node (a node that receives the transactions) validates it according to the business and technical rules set by the blockchain network. If the transaction is valid, the bookkeeper adds it to the transaction pool and forwards the transaction to peers on the network.
Create the candidate blocks: Transactions in the transaction pool are collected into a block at regular intervals. In a Bitcoin network, every 10 minutes a subset of network nodes called mining nodes (or miners) collect all valid transactions from the transaction pool and create the candidate blocks.
Mining the new block: Once the block candidate is created, the race begins for the chance to add new blocks and win the rewards. The process of such a race is called mining. The winner of the race is determined by the consensus mechanism (in this case the PoW mechanism, which will be described in the next part). The miners keep trying to find a random number, the nonce in the block header structure, until the hash meets certain demanding conditions. For example, one of these conditions is that the resulting block hash is less than a target number, or in some cases, the hash has a few leading zeros. In practice, any random number has an equal chance of winning the race, so you can practically just start a loop from 1 to 2^32 until you find such a nonce. It takes a tremendous CPU hashing effort to find such a nonce. The challenging condition, called difficulty, can be adjusted based on the target count or bits in the block header structure. The difficulty of winning the race grows exponentially with the smaller target number or fewer bits in the block header structure.
Add a new block to the blockchain: The first winning node will announce the new block to the rest of the network for verification. Once the block is verified and approved by the majority of the network’s miners, it will be accepted and form the new top of the chain. Since all blocks are chained together by linking the hash value to the previous block, any change to the ledger becomes impossible as it requires PoW for all previous transitions.

Consensus mechanism

Consensus in a blockchain is the process by which a network of mutually distrustful nodes reaches an agreement on the global state of the blockchain. In a blockchain, transactions or data are shared and distributed across the network and each node has the same copy of the blockchain data. Consensus allows all network nodes to follow the same rules when validating transactions and adding new blocks to the chain, ensuring uniformity across all copies of a blockchain. A consensus algorithm is a formal procedure or computer program for solving a consensus problem based on performing a series of specific actions. It is designed to be feasible on a network with multiple nodes. Consensus algorithms ensure that the next block in a blockchain is fully validated and secured. Currently, there are several types of consensus algorithms, each with different basic procedures. The two most popular algorithms are as follows:

Proof of Work (PoW): This consensus algorithm was introduced by Satoshi and has been widely adopted by many other blockchain systems. The PoW is the mining process aimed at finding an answer to a cryptographic hashing problem. To do this, the miner must follow the block selection rules to find the previous block and use the hash of the previous block header along with the Merkle root of the current transactions in the new block to solve the hashing problem. This requires significant computation and hashing power. Any number between 0 and 2^32 has an equal chance of solving the puzzle. The loop solution to satisfy the criteria is shown in the diagram below:

After notification, the other nodes of the network automatically check if the results are valid. If the results are valid, they add the block to their copies of the blockchain, stop the ongoing mining, and proceed to the next block.
Proof of Stake (PoS): This consensus algorithm aims to select miners based on various combinations of random choices based on miners’ wealth or age (stake). Rather than miners competing with each other to solve energy-consuming cryptographic hash functions, the network will instead use a pool of validators. Validators are nodes (which can run on a regular laptop) that are willing to stake their cryptocurrency on the transaction blocks they claim should be added to the public blockchain. Staking makes it easier for individuals to participate in securing the network and promotes decentralization.

Forks

A fork in the blockchain occurs when there are two different ways to proceed, and can be intentional or accidental. An intentional fork occurs when the blockchain software or rules are to be updated/changed, and an accidental fork occurs when two or more miners find a block almost simultaneously. Each time a fork occurs, miners must “choose” which direction to take, meaning each miner votes on what is the right decision for the entire chain. A fork is resolved when more blocks are added and one of the chains becomes longer than the other(s) (Figure 4).

The network abandons the blocks that are not in the longest chain (they are called orphan blocks) and continues. The blockchain works with a democratic policy, which means that it is always the majority that decides which way to go. The only way a breach can occur is if there is an attack, called a 51% attack, where the majority of nodes are compromised or choose to act maliciously.

Ethereum

Proposed by Vitalik Buterin in “Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform“.

Ethereum is an implementation of the blockchain and is an open source, public, and decentralized computing platform. Public means that anyone can view the account balance and transaction history of any wallet at any time by simply accessing the public Ethereum blockchain through a block explorer. Ethereum became popular thanks to the implementation of smart contracts.

Smart contracts are small programs (written in the Solidity language) in which developers can define the rules of the trust they intend to code. One of the most amazing features of smart contracts is their immutability. Once implemented on the blockchain, their code cannot be changed. This immutable property makes it very difficult to program smart contracts and detect errors in advance, and that is the reason why testnets exist.

Testnets are the replica of the mainnet Ethereum blockchain where developers can deploy their contracts. If the contracts work properly on testnets then they will work perfectly on the mainnet.

Ethereum also introduced the concept of world state and account. The world state includes a mapping of all accounts and their public addresses. To facilitate both state transactions and decentralized computing, Ethereum introduces two types of accounts: Externally Owned Accounts (EOAs), which are controlled by private keys, and Contract Accounts (CA), which are controlled by their contract code. Without CAs, Ethereum would be limited to the mere transfer of value between parties, as with Bitcoin.

References

Bitcoin: A peer-to-peer electronic cash system
https://en.bitcoin.it/wiki/Block
Ethereum Whitepaper
Mastering Blockchain Programming with Solidity - Jitendra Chittoda
Learn Ethereum - Xun Wu, Zhihong Zou and Dongying Song

Non-Fungible Tokens explained

2022-10-10T18:01:00+02:00

A non-fungible token (NFT) refers to a class of blockchain-based tokens that are intended to be unique, as opposed to cryptocurrencies where all tokens are exchangeable. NFTs are typically used to prove ownership and can represent virtually any asset, whether physical or digital. However, the most common NFT assets are digital art, digital collectibles, content such as video or audio, and event tickets.

“NFT Art gives anyone a stake in something that they feel is significant and culturally relevant. Valuable Art is something the 1% has had a monopoly on. NFT art allows the 99% to become involved.” — Kevin Godfrey, Fabriik CTO

Nowadays the market for NFTs is growing rapidly especially in the collector sector with the trend of profile pictures (PFPs), which are attracting a lot of interest. Even major platforms like Instagram and Twitter are introducing them, which is undoubtedly remarkable. Mainstream interest in non-fungible tokens reached a fever pitch in late 2021, when the market grew 21,000% to $17.6 billion, according to nonfungible.com and L’Atelier. The most widely used store for buying NFTs (OpenSea) saw record sales of $2 billion in January 2022 alone. The huge USD volume traded in 2022 is shown in the following pie chart by interest category:

Some collections, such as the Bored Ape Yacht Club (BAYC), have become nothing less than status symbols. Although they were originally intended as a joke, to this day they are no longer normal NFTs, and owning one of them is no less than owning a Ferrari. Steph Curry (a famous basketball player) bought the Bored Ape #7990 NFT in 2021 for $180,000. Other celebrities like Eminem, Snoop Dogg, Serena Williams, and Neymar own some of the most expensive PFPs out there, and they use them on their social networks.

The following table provides some information on 5 of the most profitable NFTs sold in Q2 2022:

Project	Days since purchase	Purchase Price (USD)	Resale Price (USD)	Profit (USD)	Profit (%)
CryptoPunks	583	$9,337	$3,261,857	3,252,519	34,833%
Otherdeed for Otherside	7	$5,905	$1,647,788	1,641,883	27,806%
Bored Ape Yacht Club	377	$107,000	$1,083,512	$976,512	913%
Bored Ape Yacht Club	85	$298,001	$1,222,922	$924,921	310%
Moonbirds	7	$7,554	$902,498	$894,944	11,847%

This kind of value enhancement is possible thanks to the great interest that NFTs experience on the Internet. Every day, more and more companies are trying to incorporate NFTs into their marketing strategies, and this has also happened in the fashion industry. Luxury brands such as Dolce & Gabbana, Gucci, Louis Vuitton and Burberry have actively ventured into the digital space, looking for ways to incorporate NFTs into their product range and marketing efforts.

Please note that this article isn’t intended as financial advice. The previous part was intended to show and appreciate the worldwide interest in this technology, and there’s no intention to suggest a financial investment.

Technical details

For a better understanding of the following explanations, some key terms are defined here in a simplified way:

Smart contract - A smart contract is an application that runs on the blockchain. Every smart contract has some functions, some state and an address.
ERCs - ERCs (Ethereum Request for Comments) are technical documents used by smart contract developers at Ethereum. They define a set of rules required to implement tokens for the Ethereum ecosystem.
Wallet Address - A wallet address is a string of letters and numbers (0x04600C3E...ff49628) from which cryptocurrencies or NFTs can be sent to and from.

Ethereum was the first blockchain to support NFTs with its inheritable standard ERC-721. This means that developers can create new ERC-721-compliant contracts by copying a reference implementation that provides core methods for tracking the owner of a unique identifier and a way for the owner to transfer the asset to others.

There are many standards in Ethereum; ERC20, for example, is the most popular token standard used to create fungible tokens like coins that have economic value.

Here are some differences between the ERC20 and the ERC721 standard:

Property	ERC20 token standard	ERC721 NFT standard
Fungibility	Tokens are fungible up to the decimal places specified in the contract.	Tokens are not fungible. Each token itself represents 1 asset that cannot be subdivided.
Ownership	Token ownership is not directly linked to an account, and only the token balances are tracked.	Ownership of each token is tied to an individual account address.
Uniqueness	There is no difference in each token.	Each token is different from every other token included in the same contract.

The main feature of ERC-721 is that each token is unique. When an ERC-721 token is created, there is only one copy. These tokens, as NFTs, have spread the idea and application of unique assets on Ethereum.

The following figure (Figure 1) helps to better understand what it means that ERC20 maps addresses to amounts and ERC721 maps unique IDs to owners.

The descriptive information of a particular ERC721 token is provided by its metadata and might look something like this:

{
  "name": "Token #1",
  "image": "https://example.org/1.png",
  "description": "This is the token n.1"
}

There are two options for representing metadata: On-chain and off-chain. In the on-chain approach, metadata is stored permanently with the token and persists beyond the lifecycle of a particular application. Moreover, they can change according to the on-chain logic. Despite these benefits, most projects store their metadata off-chain (Figure 2) simply due to the current storage limitations of the Ethereum blockchain.

The ERC721 standard includes (in an optional interface called ERC721Metadata) a function called tokenURI that developers can implement to tell applications where to find the metadata for a given item.

function tokenURI(uint256 _tokenId) public view returns (string)

The function tokenURI returns the Uniform Resource Identifier (URI) as data type string. This in turn returns a JSON file that conforms to the ERC721 metadata schema.

An in-depth insight into ERC-721

Each ERC721 token must implement nine mandatory functions and is defined as follows:

interface ERC721 {
    event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
    event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);
    event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

    function balanceOf(address _owner) external view returns (uint256);
    function ownerOf(uint256 _tokenId) external view returns (address);
    function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
    function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
    function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
    function approve(address _approved, uint256 _tokenId) external payable;
    function setApprovalForAll(address _operator, bool _approved) external;
    function getApproved(uint256 _tokenId) external view returns (address);
    function isApprovedForAll(address _owner, address _operator) external view returns (bool);
}

The balanceOf() function in the following code returns the total number of tokens for the specified address:
```
function balanceOf(address _owner) public view returns (uint256) {
	require(owner != address(0));
	return _ownedTokensCount[owner];
}
```
Anyone is allowed to call this function, as it is a public and view function, to read the value for off-chain calculation as well.
The ownerOf() function finds the provided tokenId in the _tokenOwner map and returns the address of its owner:
```
function ownerOf(uint256 tokenId) public view returns (address) {
	address owner = _tokenOwner[tokenId];
	require(owner != address(0));
	return owner;
}
```
If the specified tokenId does not exist in the mapping, address(0) is assigned to the local variable owner and the function call fails.
The approve() function approves permission from another entity to transfer a token on behalf of the owner. The function requires that the sender of the message is the owner of tokenId. The approved token is stored in the mapping shop of tokenApprovals:
```
function approve(address to, uint256 tokenId) public {
	address owner = ownerOf(tokenId);
	require(to != owner);
	require(msg.sender == owner || isApproveForAll(owner, msg.sender));

	_tokenApprovals[tokenId] = to;
	emit Approval(owner, to, tokenId);
}
```
The approve() function can also be called by the operator (who has rights to the owner’s tokens). The operator can also grant approvals to another account. There are two require checks, the one require(to != owner) ensures that the operator cannot grant any other approvals to the token owner. The second require ensures that the sender is either the owner or has operator rights. After these checks are made, the token approval is issued to the address to for the specified tokenId. Finally, an Approval event is issued along with the approval data.
The getApproved() function verifies and makes sure that the transaction senders are the owners of the token and that the token transfer gets approved:
```
function getApproved(uint256 tokenId) public view returns (address) {
	require(_exists(tokenId));
	return _tokenApprovals[tokenId];
}
```
The function calls an internal _exists() function to ensure that the given tokenId exists and that it has been assigned to a non-address(0) owner, otherwise, the function call fails.
The setApprovalForAll function enables or disables the approval of a third party (operator) to manage all of the assets for msg.sender:
```
function setApprovalForAll(address to, bool approved) public {
	require(to != msg.sender);
	_operatorApprovals[msg.sender][to] = approved;
	emit ApprovalForAll(msg.sender, to, approved);
}
```
The argument approved is a boolean value that specifies whether the approval should be granted or revoked.
The isApprovedForAll() function checks that the given operator has operator rights on the given owner’s tokens:
```
function isApprovedForAll(address owner, address operator) public view returns (bool) {
	return _operatorApprovals[owner][operator];
}
```
It fetches the read-only data from the _operatorApprovals mapping.
The transferFrom() function transfers ownership of an NFT:
```
function transferFrom(address from, address to, uint256 tokenId) public {
	require(_isApprovedOrOwner(msg.sender, tokenId));
	_transferFrom(from, to, tokenId);
}
```
The function first validates that the msg.sender (function caller) has the necessary permissions to transfer the given tokenId. Once it is verified, the internal call to the _transferFrom() function transfers the token from the owner’s account to the recipient’s account.
The safeTransferFrom() function is used to safely transfer the NFT from the owner’s account to the recipient’s account:
```
function safeTransferFroom(address from, address to, uint256 tokenId, bytes memory _data) public {
	transferFrom(from, to, tokenId);
	require(_checkOnERC721Received(from, to, tokenId, _data));
}
```
Safely transfer here means that if the recipient is a contract, you must ensure that the “recipient contract” has registered callbacks so that the “receiver contract” gets a notification when the ERC721 token transfer is successful.
There is another function safeTransferFrom() which is used when the recipient of the NFT is an Externally Owned Account (EOA) and not a contract account:
```
function safeTransferFrom(address from, address to, uint256 tokenId) public {
	safeTransferFrom(from, to, tokenId, "");
}
```

The standard interface discussed is taken from the EIP standard document at https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md.

References

Non-fungible token
Ethereum Improvement Proposals
nonfungible.com - 2022 NFT Market report Q2
Report: $17.6 billion in NFT trades during 2021 - L’Atelier
The Non-Fungible Token Bible: Everything you need to know about NFTs - Devin Finzer
Mastering Blockchain Programming with Solidity - Jitendra Chittoda
Learn Ethereum - Xun Wu, Zhihong Zou and Dongying Song

NFTs as credentials (?)

2022-10-07T19:00:00+02:00

As we saw in the previous article, there are different implementations and standards in the world of digital credentials. The idea of certifying one’s identity and competence with the digital signature of the issuer is undoubtedly very effective, especially when accompanied by a graphic aspect in the form of a recognition medal.

However, the use of a verification tool (which cannot be universal given the different implementations) is essential and preservation also requires the use of third-party applications.

So we might ask: What if we used NFTs as credentials?

Something belonging to an entity can be identified by either an NFT or a VC. The records of both are immutable (therefore secure), but there are significant differences. VCs use public-key infrastructure and digital signatures to prove a claim; they are not publicly viewable but are selectively shared with verifying parties as needed.

In a post titled “Where to use a blockchain in non-financial applications” Vitalik Buterin (Ethereum co-founder) said:

With off-chain claims, you can do *positive* reputation, because it’s in the interest of the recipient of a claim to show it to appear more reputable (or make a ZK-proof about it), but you can’t do *negative* reputation, because someone can always choose to only show the claims that make them look good and leave out all the others.

Some situations may benefit from this kind of transparency, and NFTs provide these specifics due to the fact that they are blockchain-based and time-stamped. The digital ownership and the origin of a token can be easily verified, and if you know the wallet address, you can see all the NFTs that someone owns and has ever owned.

Currently, VCs are the most practical technology to digitize our credentials and allow people to establish their identity on the Internet. While privacy and the lack of financial speculation are two major benefits of using VCs for digital identity, both factors have limited the social reach and adoption of the concept. As we can see, the search volume for NFTs is several orders of magnitude higher than for VCs.

Keywords	Monthly search volume
nft	1.830.000
non fungible tokens	60.500
verifiable credentials	8.100
w3c verifiable credentials	90

The great interest in this technology could prepare the ground for a real spread of digital credentials.

References

Where to use a blockchain in non-financial applications - Vitalik Buterin
WordStream used for keywords results

Davide Di Francesco

Vibecoding in Practice: Building SortDocs with AI

The Idea

What SortDocs Actually Does

First Look at the CLI

Why This Was a Better Vibecoding Test

Starting with the CLI

The Core Challenge: Understanding Files, Not Just Extensions

Building Guardrails Early

Project Folder Protection

Improving Repeat Runs

Onboarding Matters More Than Expected

The Optional GUI

Where Vibecoding Helped the Most

Where It Still Needed Direction

Final Thoughts

Vibecoding, One Year Later: Trying the Same Multiplayer Prototype Again

Starting from the same prompt

The first interesting difference

First result

Letting it keep going

Faster than last year

Adding chat

What feels different

Conclusions

Vibecoding: Letting AI Code for Me

Setting the Stage

The Experiment

Choosing the Right Tools

Picking a Project

First Steps

Adding a Chat System

Refining the Chat System

Refactoring the Code Structure

Expanding the Game Area

Fixing Multiplayer Visibility Bug

Implementing Player Collision

Debugging AI Mistakes

Improving Camera Behavior

Jump Mechanic & UI Improvements

Conclusion

Universal Middleware for Any Function

Why Middleware?

The Challenge: Consistent Logging

The Solution: Higher-Order Functions for Middleware

Code Implementation

Explaining withLogging

Explaining applyMiddleware

Middleware in Action

Why Use Middleware in Angular?

Beyond Logging

Final Thoughts

Acknowledgments

Conditional Routing in Angular with canMatch Guards

Introduction

What is canMatch?

A Real-World Example: Premium Content Access

Step 1: Defining the Guard

Step 2: Configuring the Routes

Why Use canMatch Instead of canActivate?

Conclusion

Simplifying Angular Templates with combineLatest in NgRx

Understanding combineLatest

Leveraging ng-conteiner and the async Pipe

The Advantage

Putting It All Together

Conclusion

Stop Using console.log and Start Using This Service!

Why You Should Stop Using console.log

Introducing the Log Service

Log Levels Enum

Log Service

Environment Configuration

How to Use the Log Service

Conclusion

How to Create Dynamic Forms in Angular Using a Dictionary Interface

Defining the Dictionary Interface

Creating the Dynamic Form Generator Service

Creating the Dynamic Form Group Component

Putting It All Together

Explaining `withLogging`

Explaining `applyMiddleware`

What is `canMatch`?

Why Use `canMatch` Instead of `canActivate`?

Understanding `combineLatest`

Leveraging `ng-conteiner` and the `async` Pipe

`components/`

`dumb-components/`

`containers/`

`pages/`

`shared/`

`interceptors/`

`store/`