The challenge of Angular state management at scale

Traditional Angular applications often struggle with state management as they grow. Components become tightly coupled, services proliferate without clear boundaries, and testing becomes increasingly difficult. The typical result is a codebase where changing one feature breaks another, and adding new functionality requires understanding the entire application. Nx addresses these issues through workspace architecture that enforces clear separation of concerns and prevents architectural drift through automated linting rules.

Library-Based architecture

The foundation of effective state management in Nx lies in its library structure. Rather than organizing code by file type (components, services, models), Nx encourages organization by domain and responsibility:

libs/todo-management/todo/
├── data-access/    # HTTP services and external data
├── store/          # NgRx Signal Store implementation / State implementation
├── feature/        # Smart components with business logic aka a feature
├── ui/             # Presentational components
└── util/           # Shared models and types

This structure creates natural boundaries that mirror how state actually flows through your application.

Dependency Direction and Boundaries

The real power of Nx state management architecture comes from its dependency rules. These aren't suggestions you can enforce them through ESLint configuration that prevents architectural violations : https://gillesferrand.com/nx-from-chaos-to-consistency-enforcing-boundaries

This creates isolated business domains that can be developed and tested independently. Store libraries, dedicated for a feature, handle state management and can depend on data-access for external data sources and other stores for composition, but remain isolated from features, and UI concerns. This hierarchy creates unidirectional data flow and prevents the circular dependencies that plague traditional Angular applications.

State Management Implementation

With NgRx Signal Store, state management becomes more declarative and reactive. The store library contains all state logic:

export const TodoStore = signalStore(
  withState(initialState),
  withComputed(({ todos }) => ({
    completedTodos: computed(() => todos().filter(t => t.completed)),
    activeTodos: computed(() => todos().filter(t => !t.completed))
  })),
  withMethods((store, todoService = inject(TodoService)) => ({
    loadTodos: () => {
      // State management logic
    },
    addTodo: (text: string) => {
      // Business logic for adding todos
    }
  }))
);

Full code here : https://github.com/Gillesf31/nx-ngrx-signal-store/blob/main/libs/todo-management/todo/store/src/lib/todo.store.ts

The feature library orchestrates this store with UI components, while data-access libraries handle HTTP communication. Each layer has a single, clear responsibility.

Benefits in Practice

This architecture delivers measurable benefits:

• Build Optimization: Nx's dependency graph allows incremental builds. When you change a UI component, only dependent libraries rebuild, not the entire application / repository.

• Testing Isolation: Each library can be tested independently. UI components can be tested without state management, stores can be tested without HTTP services, and business logic can be tested without UI concerns.

• Team Scalability: Different teams can work on different domains without stepping on each other's code. The dependency rules prevent accidental coupling between features.

• Code Reusability: UI components become truly reusable because they're isolated from business logic. Data access services can be shared across features without coupling.

Migration Strategy

For existing Angular applications, migration to this architecture can happen incrementally. Start by identifying natural domain boundaries in your application, then extract libraries one layer at a time. Begin with utility libraries (models, types), then data access, then stores, and finally features and UI. The ESLint rules can be introduced gradually, allowing you to enforce architecture as you refactor rather than requiring a complete rewrite.

Conclusion

Nx helps you to create and maintain this library architecture which transforms state management from a technical concern into an organizational tool. By enforcing clear boundaries between data access, state management, business logic, and presentation, you create applications that scale with your team and requirements rather than against them. The investment in architectural discipline pays dividends through faster builds, easier testing, and more maintainable code. Most importantly, it prevents the architectural drift that turns promising applications into maintenance nightmares.

Ressources

• https://github.com/Gillesf31/nx-ngrx-signal-store

• https://gillesferrand.com/series/nx

• https://nx.dev/getting-started/tutorials/angular-monorepo-tutorial

• https://www.youtube.com/@nxdevtools

useEffect without dependencies array

// ComponentA.tsx
import { useEffect } from 'react';

const ComponentA = () => {
  useEffect(() => {
    console.log('Component A mounted');
    return () => {
      // NOTE: Cleanup function, we will see this in a future blog post
      console.log('Component A unmounted');
    };
  });

  return <p>Component A works</p>;
};

export default ComponentA;

// App.tsx
import { useState } from 'react';
import ComponentA from './ComponentA';

function App() {
  const [isComponentAVisible, setComponentAVisible] = useState(true);
  const [count, setCounter] = useState(0);

  return (
    <>
      <p>App works</p>
      <p>Counter: {count}</p>
      <button onClick={() => setCounter((prev) => prev + 1)}>
        Increment Counter
      </button>
      <button onClick={() => setComponentAVisible(!isComponentAVisible)}>
        {isComponentAVisible ? 'Hide' : 'Show'} component A
      </button>
      {isComponentAVisible && <ComponentA />}
    </>
  );
}

export default App;

Console output :

// Component A mounted (page loads)
// Component A mounted (page loads / Only if strict mode is activated)
// Component A unmounted (hide component A clicked)
// Component A mounted (show component A clicked)
// Component A unmounted (Only if strict mode is activated)
// Component A mounted (Only if strict mode is activated)

In this case useEffects run :

• Initial render

• Every state update

• Every prop changed

• Every parent re-render

Use case : Rare. Typically only when you need to respond to any component change, such as logging or analytics tracking.

useEffect without empty dependencies array

An empty dependencies array makes the effect run only once after the initial render.

// ComponentA.tsx
import { useEffect } from 'react';

const ComponentA = () => {
  useEffect(() => {
    console.log('Component A mounted');
    return () => {
      // NOTE: Cleanup function, we will see this in a future blog post
      console.log('Component A unmounted');
    };
  }, []);

  return <p>Component A works</p>;
};

export default ComponentA;

Console output :

// Component A mounted (page loads)
// Component A mounted (page loads / Only if strict mode is activated)

// Clicking on increment counter doesn't log anything

// Component A unmounted (hide component A clicked)
// Component A mounted (show component A clicked)
// Component A unmounted (Only if strict mode is activated)
// Component A mounted (Only if strict mode is activated)

In this case useEffects run :

• Only after the initial render

• Never again until component unmounts

Use case : Component initialization, data fetching that happens once, setting up subscriptions, or DOM manipulations that should only happen on mount.

useEffect with dependencies array

When you specify dependencies, the effect runs after the initial render and whenever any dependency changes.

// ComponentA.tsx
import { useEffect } from 'react';

interface ComponentPropsA {
  readonly userId: number;
  readonly theme: 'light' | 'dark';
}

const ComponentA = ({ userId, theme }: ComponentPropsA) => {
  useEffect(() => {
    console.log(
      `Component A mounted with userId: ${userId} and theme: ${theme}`
    );

    // Example: fetch user-specific data or apply theme
    if (userId) {
      console.log(`Fetching data for user ${userId} with ${theme} theme`);
    }

    return () => {
      // NOTE: Cleanup function, we will see this in a future blog post
      console.log(`Component A unmounted with userId: deps changed`);
    };
  }, [userId, theme]); // Effect depends on userId and theme

  return <p>Component A works</p>;
};

export default ComponentA;

// App.tsx
import { useState } from 'react';
import ComponentA from './ComponentA';

function App() {
  const [isComponentAVisible, setComponentAVisible] = useState(true);
  const [userId, setUserId] = useState(1);
  const [theme, setTheme] = useState<'light' | 'dark'>('light');
  const [count, setCount] = useState(0);

  return (
    <>
      <p>App works</p>
      <p>Counter: {count}</p>
      <button onClick={() => setCount((prev) => prev + 1)}>
        Increment Counter
      </button>
      <button onClick={() => setUserId((prev) => prev + 1)}>
        Increment User ID
      </button>
      <button
        onClick={() =>
          setTheme((prev) => (prev === 'light' ? 'dark' : 'light'))
        }
      >
        Toggle Theme
      </button>
      <button onClick={() => setComponentAVisible(!isComponentAVisible)}>
        {isComponentAVisible ? 'Hide' : 'Show'} component A
      </button>
      {isComponentAVisible && <ComponentA userId={userId} theme={theme} />}
    </>
  );
}

export default App;

Console output :

// Component A mounted with userId: 1 and theme: light (page loads)
// Fetching data for user 1 with light theme (page loads)
// Component A unmounted with userId: deps changed (page loads / Only if strict mode is activated)
// Component A mounted with userId: 1 and theme: light (page loads / Only if strict mode is activated)
// Fetching data for user 1 with light theme (page loads / Only if strict mode is activated)

// Clicking on increment counter doesn't log anything

// Clicking on increment userId
// Component A unmounted with userId: deps changed
// Component A mounted with userId: 2 and theme: light
// Fetching data for user 2 with light theme

// Clicking on toggle theme
// Component A unmounted with userId: deps changed
// Component A mounted with userId: 2 and theme: dark
// Fetching data for user 2 with dark theme

In this case useEffects run :

• After the initial render

• Whenever query changes

• Whenever category changes

• Not when other state variables change

Use case : Responding to specific state or prop changes, such as fetching data based on user input, updating derived state, or synchronizing with external systems.

Quick Comparison Table

Performance Impact

The Problem with Traditional Branch Switching

Most developers are familiar with the standard Git workflow: switch branches, work on changes, commit, and switch again. This approach creates friction when you need to:

• Compare code between branches side by side
• Test different features simultaneously
• Apply hotfixes while working on a feature branch
• Run builds on multiple branches without losing your current work state

Traditional solutions involve stashing changes, switching branches, or maintaining multiple repository clones. Each approach introduces overhead and complexity.

What Git Worktree Solves

Git worktree eliminates these pain points by creating additional working directories that share the same Git repository. Each worktree operates independently while maintaining a connection to the central .git directory.

Think of it as having multiple desks in the same office. Each desk has different papers (files) spread out, but they all access the same filing cabinet (Git repository).

Basic Worktree Operations

Creating a New Worktree

# Create worktree for existing branch
git worktree add ../feature-login feature/user-login

# Create worktree with new branch
git worktree add ../hotfix-payment -b hotfix/payment-bug

The first command creates a directory ../feature-login containing the feature/user-login branch. The second creates both a new branch and worktree simultaneously.

Listing Active Worktrees

git worktree list

This shows all worktrees with their paths and current branches:

/home/user/myproject        a1b2c3d [main]
/home/user/feature-login    e4f5g6h [feature/user-login]
/home/user/hotfix-payment   h7i8j9k [hotfix/payment-bug]

Removing Worktrees

# Remove worktree (must be done from main repository)
git worktree remove ../feature-login

# Force removal if worktree has uncommitted changes
git worktree remove --force ../feature-login

Practical Development Scenarios

Scenario 1: Feature Development with Hotfix

You're developing a new feature when a critical bug appears in production:

# Currently working in main worktree on feature branch
git worktree add ../hotfix-critical -b hotfix/critical-fix

# Switch to hotfix directory
cd ../hotfix-critical

# Fix the bug, commit, and push
git add .
git commit -m "Fix critical payment processing bug"
git push origin hotfix/critical-fix

# Return to feature work without losing context
cd ../myproject

Scenario 2: Code Comparison and Testing

Compare implementations across branches without losing your current work:

# Create worktrees for comparison
git worktree add ../old-implementation legacy/payment-system
git worktree add ../new-implementation feature/payment-refactor

# Run tests in parallel
cd ../old-implementation && npm run test
cd ../new-implementation && npm run test

Scenario 3: Multiple Environment Builds

Maintain separate builds for different environments:

git worktree add ../staging-build staging
git worktree add ../production-build production

# Build staging while working on development
cd ../staging-build && npm run build:staging

Worktree Limitations and Considerations

Shared State Elements

Certain Git elements are shared across all worktrees:

• Branches: Checking out the same branch in multiple worktrees is prohibited
• Configuration: Repository configuration affects all worktrees
• Hooks: Git hooks execute from the main .git directory
• Stash: Stash entries are shared across worktrees

Best Practices

Keep worktrees focused: Use worktrees for specific, time-limited tasks rather than permanent parallel development.

Clean up regularly: Remove unused worktrees to maintain a clean working environment:

# Remove worktree and clean up references
git worktree remove ../completed-feature
git worktree prune

Avoid nested worktrees: Don't create worktrees inside other worktrees as this creates confusing repository relationships.

Use descriptive paths: Choose directory names that clearly indicate the branch or purpose.

Worktree vs. Alternatives

Git Worktree vs. Multiple Clones

Worktrees share the object database, saving disk space and keeping branches synchronized. Multiple clones require separate git fetch operations and consume more storage.

Git Worktree vs. Branch Switching

Branch switching requires stashing or committing work in progress. Worktrees maintain independent working states without interruption.

Git Worktree vs. Git Stash

Stashing saves work temporarily but doesn't allow parallel development. Worktrees enable simultaneous work on multiple branches.

Git worktree transforms parallel development from a cumbersome process into a streamlined workflow. By maintaining separate working directories while sharing the repository history, it eliminates context switching overhead and enables truly parallel development workflows. The key to effective worktree usage lies in treating them as focused, temporary workspaces rather than permanent parallel development environments.

Why rewriting history can happen

In professional development environments, clean Git history isn't just a preference, it's a requirement for maintainable codebases. Many teams follow a "one logical commit per feature" guideline, where each merge to the main branch represents a single, complete change. This approach makes code reviews more focused, rollbacks (git revert) cleaner, and debugging significantly easier when you need to trace issues months later. (git bisect)

During development, however, your feature branch accumulates multiple commits: initial implementations, bug fixes, code review responses, and style adjustments. Before merging, teams typically require you to squash these commits into a coherent story or rebase onto the latest main branch to avoid merge commits that clutter the project history.

Additionally, as main branch development continues, your feature branch falls behind. Rebasing your work onto the current main branch creates a linear history that's easier to follow than a web of merge commits. Some teams also enforce commit message standards or require sign-offs that weren't present in your original commits, necessitating history rewrites to meet project guidelines.

These practices, rebasing, squashing, and amending, all change commit hashes, creating the divergence that requires force pushing to update the remote repository.

Push force can be scary at the beginning but when you are used to it, it's pretty easy !

The problem with standard force push

The git push --force command overwrites the remote branch with your local version, regardless of what changes might exist on the remote. This brute-force approach can lead to serious problems in team environments.

A good rule to follow is to only force push on your own feature branch, but sometimes you work on a bigger branch with a colleague

# Dangerous - overwrites everything on remote
git push --force origin feature-branch

Consider this scenario: You're working on a feature branch, and a colleague pushes some critical bug fixes while you're doing a rebase. If you force push without checking, you'll completely erase their work.

# Timeline of disaster:
# 1. You start with commit A
# 2. Colleague pushes commit B to remote
# 3. You rebase locally, creating commit A'
# 4. You force push, replacing A-B with just A'
# 5. Colleague's work (commit B) is gone forever

Force-with-lease: the safer alternative

The --force-with-lease option provides a safety net. It only allows the force push if your local reference matches what's currently on the remote. If someone else has pushed changes since your last fetch, the command will fail.

# Safer - checks remote state first
git push --force-with-lease origin feature-branch

Here's how it protects you:

# Safe scenario:
git fetch origin                    # Get latest remote state
git rebase origin/main             # Rebase your work
git push --force-with-lease origin feature-branch  # Safe to push

# Protected scenario:
# Someone pushed while you were rebasing
git push --force-with-lease origin feature-branch
# Error: Updates were rejected because the remote contains work

Practical code examples

Basic Usage Comparison

# Traditional force push (dangerous)
git push --force origin feature-branch

# Force with lease (safer)
git push --force-with-lease origin feature-branch

Real-world workflow

Here's a typical development workflow using force-with-lease:

# 1. Fetch latest changes
git fetch origin

# 2. Rebase your feature branch
git checkout feature-branch
git rebase origin/main

# 3. Safely force push
git push --force-with-lease origin feature-branch

Handling rejected pushes

When force-with-lease rejects your push, here's how to handle it:

# Force-with-lease failed - someone pushed changes
git fetch origin
git log origin/feature-branch --oneline  # See what changed
git rebase origin/feature-branch         # Incorporate new changes
git push --force-with-lease origin feature-branch  # Try again

When to use each command

Use --force-with-lease when:

• Working on shared feature branches
• You've rebased or amended commits
• Collaborating with other developers
• You want protection against accidental overwrites

Use --force only when:

• You're certain no one else is working on the branch
• You're working on a personal fork
• You need to recover from a corrupted remote state
• You've explicitly coordinated with your team

The bottom line

Force-with-lease should be your default choice for overwriting remote history. It provides the same functionality as force push while protecting against the most common cause of lost work: accidentally overwriting changes you haven't seen.

The extra safety check takes virtually no additional time and can save hours of recovery work. In collaborative environments, this small change in habit can prevent significant frustration and potential data loss.

Make force-with-lease your standard practice, and reserve regular force push for those rare situations where you're absolutely certain about the state of the remote repository.

The Problem

Let's say you have an array of API status objects and need to create types from them:

const API_STATUSES = [
  { code: 'success', message: 'Request completed', httpCode: 200 },
  { code: 'error', message: 'An error occurred', httpCode: 500 },
  { code: 'loading', message: 'Request in progress', httpCode: null },
  { code: 'timeout', message: 'Request timed out', httpCode: 408 }
] as const;

// How do we get types from this array?

You could manually define union types, but that means maintaining the same information in two places:

// Manual approach - duplication!
type ApiStatusCode = 'success' | 'error' | 'loading' | 'timeout';
type ApiStatusObject = {
  code: ApiStatusCode;
  message: string;
  httpCode: number | null;
};

The Solution : [number] Index Signature

The [number] notation extracts the type of elements that can be accessed with any numeric index:

const API_STATUSES = [
  { code: 'success', message: 'Request completed', httpCode: 200 },
  { code: 'error', message: 'An error occurred', httpCode: 500 },
  { code: 'loading', message: 'Request in progress', httpCode: null },
  { code: 'timeout', message: 'Request timed out', httpCode: 408 }
] as const;

// Extract the union of all object types
type ApiStatusObject = (typeof API_STATUSES)[number];

// Extract specific property types
type ApiStatusCode = ApiStatusObject['code']; // 'success' | 'error' | 'loading' | 'timeout'

How It Works

Breaking down (typeof API_STATUSES)[number]:

1. typeof API_STATUSES - Gets the type of the array
2. [number] - Accesses the type of elements at any numeric index
3. Result - A union of all object types in the array

The [number] essentially says "give me the type of whatever can be found at any number index in this array."

Practical Example

Here's how you might use this in practice:

const API_STATUSES = [
  { code: 'success', message: 'Completed', retryable: false },
  { code: 'error', message: 'Failed', retryable: true },
  { code: 'loading', message: 'In progress', retryable: false },
  { code: 'timeout', message: 'Timed out', retryable: true }
] as const;

type ApiStatusObject = (typeof API_STATUSES)[number];
type ApiStatusCode = ApiStatusObject['code'];

function getStatusInfo(code: ApiStatusCode): ApiStatusObject | undefined {
  return API_STATUSES.find(status => status.code === code);
}

function isRetryable(code: ApiStatusCode): boolean {
  const status = getStatusInfo(code);
  return status?.retryable ?? false;
}

// TypeScript knows these are valid
console.log(isRetryable('error')); // true
console.log(isRetryable('success')); // false

// TypeScript error - invalid status code
// console.log(isRetryable('invalid')); // ❌
// Argument of type '"invalid"' is not assignable to parameter of type '"success" | "error" | "loading" | "timeout"'.(2345)

Why This Matters

Single source of truth: Your array serves as both runtime data and type definition. Add a new status object to the array, and the types update automatically.

Type safety: TypeScript catches typos and invalid values at compile time.

Better refactoring: Rename a property in your array objects, and TypeScript will help you find all the places that need updating.

Conclusion

The [number] index signature is a simple but powerful TypeScript feature. It eliminates the need to manually maintain union types that mirror your array data, giving you better type safety with less code duplication.

Next time you find yourself writing the same information in both an array and a type definition, remember this elegant solution.

This feature of NX completely changed my way of developing products, because at the end it’s “just” a nice tool but in fact it’s way more than that. You could build your own framework to do the same thing : enforcing a nice, developer-friendly architecture. But it’ll cost a lot of effort.

And that’s why NX is really nice, it gives you this kind of tool directly. So you don’t spend hours and hours creating your own tool. If I can remember correctly it was one of the goals of the NX team, simplify life of smaller developer teams.

Let me quickly explain how it changed my developer’s life, I will dedicate a full article about other feature that changed my life too, now when I create a product I think deeper about the architecture, I try to split things into libraries, scopes, boundaries… to make them re-usable and easy to maintain. And NX helps me a lot with that.

So let's dive into how these boundary enforcement features work and how you can implement them in your own monorepo.

What is really important

In the last article we talked about how to define libraries types, today we will talk about how we can enforce these rules through linting, dependency constraints, and automated checks so everyone on the monorepo can understand the architecture and be consistent. At the end we will see that you can extend this boundary concept through many things like scope, domains, and team ownership…

So NX give you a new rule on ESLint to add your libraries types, you can find this in eslint config file ( eslint.config.mjs in newer version of NX or .eslintrc.json in older version) at the root of your NX project.

Here is an example on a monorepo with React

import nx from '@nx/eslint-plugin';

export default [
    ...,
    rules: {
      '@nx/enforce-module-boundaries': [
        'error',
         {
             enforceBuildableLibDependency: true,
             allow: ['^.*/eslint(\\.base)?\\.config\\.[cm]?[jt]s$'],
             depConstraints: [/* Your rules here */]
         }
      ],
    },
  },
  ...,
];

Why you need to add a tag on your libraries

NX needs to know which library and of what type in order to apply rules, so with each generation or creation of a library, you'll need to take care to specify its tag.

If you want to create a utility-type library for example, you’ll need to add this in project.json of your library

  "tags": ["type:util"],

or in package.json of your library

"nx": {
  "tags": [
    "type:util"
  ]
}

Of course you can have multiple tags like this

"tags": ["scope:fithelper-front", "type:util"],
// or
"tags": ["scope:fithelper-front", "type:data-access"],
// or
"tags": ["scope:fithelper-front", "type:app"],
// or
"tags": ["scope:shared-components", "type:ui"],
// ...

More here : https://nx.dev/features/enforce-module-boundaries#tags

A slightly more concrete example

Now that we see how to create libraries with tags let’s bring back my previous example (https://gillesferrand.com/nx-library-types)

We want to create a new rule to be sure everything is secured by linting

Let’s start with util rules

import nx from '@nx/eslint-plugin';

export default [
    ...,
    rules: {
      '@nx/enforce-module-boundaries': [
        'error',
         {
             enforceBuildableLibDependency: true,
             allow: ['^.*/eslint(\\.base)?\\.config\\.[cm]?[jt]s$'],
             depConstraints: [
                 {
                  sourceTag: 'type:util',
                  onlyDependOnLibsWithTags: ['type:util'],
                 },
             ]
         }
      ],
    },
  },
  ...,
];

With two lines of configuration I warn NX that every libraries tagged util can only import other libraries tagged util. This constraint exists because utility libraries are specifically designed for models, types, and static functions - they should never contain components, features, or services. If we allow util libraries to import from feature libraries, data-access libraries, or ui libraries, we break the foundational nature of these utilities.

This strict rule ensures that util libraries remain purely functional and can serve as the bedrock of your architecture. Components belong in UI libraries (tagged as 'ui'), which can depend on util libraries to access shared models and helper functions, but not the other way around. This one-way dependency flow - where UI components can use utilities, but utilities cannot use components - prevents circular dependencies and keeps your architecture clean and predictable.

Here’s a more complex example

            "depConstraints": [
              {
                "sourceTag": "type:app",
                "onlyDependOnLibsWithTags": [
                  "type:shell",
                  "type:feature",
                ]
              },
              {
                "sourceTag": "scope:fithelper-front",
                "onlyDependOnLibsWithTags": [
                  "scope:fithelper-front",
                  "scope:shared"
                ]
              },
              {
                "sourceTag": "scope:shared",
                "onlyDependOnLibsWithTags": ["scope:shared"]
              },
              {
                "sourceTag": "type:feature",
                "onlyDependOnLibsWithTags": [
                  "type:feature",
                  "type:ui",
                  "type:util",
                  "type:data-access",
                  "type:facade"
                ]
              },
              {
                "sourceTag": "type:data-access",
                "onlyDependOnLibsWithTags": ["type:data-access", "type:util"]
              },
              {
                "sourceTag": "type:state",
                "onlyDependOnLibsWithTags": ["type:state", "type:util"]
              },
              {
                "sourceTag": "type:facade",
                "onlyDependOnLibsWithTags": ["type:state", "type:util"]
              },
              {
                "sourceTag": "type:ui",
                "onlyDependOnLibsWithTags": ["type:ui", "type:util"]
              },
              {
                "sourceTag": "type:util",
                "onlyDependOnLibsWithTags": ["type:util"]
              },
              {
                "sourceTag": "type:shell",
                "onlyDependOnLibsWithTags": [
                  "type:shell",
                  "type:feature",
                  "type:data-access",
                  "type:state",
                  "type:facade",
                  "type:ui",
                  "type:util"
                ]
              }
            ]

As you can see, you can create whatever boundaries you need : scopes, domains, team ownership, or any custom rules that fit your architecture. NX provides the foundational tools, and you define the constraints that make sense for your project. The more thoughtfully you design these boundaries, the more NX can help you maintain architectural consistency and prevent violations.

The beauty of this approach is its flexibility, but also its potential pitfall. While you can create any boundaries you need resist the urge to over-engineer from the start. Creating 200 scopes and 200 library types will overwhelm your team rather than help them. Start simple with 3-4 clear library types and basic scopes, then add constraints only when you encounter real problems. NX scales with your needs, so let your architecture evolve naturally.

https://nx.dev/concepts/decisions/project-dependency-rules#other-types

Ok.. but how NX enforce it ?

With ESlint !

If I try to import UI library in Util my IDE will warn me that’s is not authorized

And lint job will do it too

nx run shared-local-storage-util:lint

Other ressource

https://www.youtube.com/watch?v=q0en5vlOsWY

https://nx.dev/concepts/decisions/project-dependency-rules#other-types

https://nx.dev/features/enforce-module-boundaries#enforce-module-boundaries

npm create vite@latest my-app -- --template react
cd my-app
npm install tailwindcss @tailwindcss/vite

// vite.config.ts
import tailwindcss from '@tailwindcss/vite'
import react from '@vitejs/plugin-react'
import { defineConfig } from 'vite'


export default defineConfig({
  plugins: [
    react(), 
    // Add this
    tailwindcss()],
})

/* index.css */
@import "tailwindcss";

Create component without JSX

And yes, you can write React componentg without JSX, I will show you how and why you shouldn’t

We will use React.createElement to generate our element instead of using JSX

import React from 'react'
import { createRoot } from 'react-dom/client'
import './index.css'

const element = React.createElement(
  // DOM element
  'h1', 
  // Attributes
  {className: 'text-3xl font-bold underline'}, 
  // Children
  'Hello, world!')

createRoot(document.getElementById('root')).render(element)

Sweet it’s working

But now what if I need nested element ? It’s also possible

import React from 'react'
import { createRoot } from 'react-dom/client'
import './index.css'

const element = React.createElement(
  'section', 
  {className: 'border border-red-500 border-solid', id: 'main-heading'}, 
  React.createElement(
    'h1',
    {className: 'text-3xl font-bold underline'}, 
    'Hello, world!'
  ),
  React.createElement(
    'p',
    null, 
    'I am Gilles, a software engineer!'
  )
)

createRoot(document.getElementById('root')).render(element)

We are starting to see the main problem of React.createElement but let me exagerate it

import React from 'react';
import { createRoot } from 'react-dom/client';
import './index.css';

const element = React.createElement(
  'div',
  { 
    className: 'min-h-screen bg-gradient-to-br from-slate-50 to-blue-50 flex items-center justify-center p-4'
  },
  React.createElement(
    'div',
    { className: 'max-w-2xl w-full bg-white rounded-2xl shadow-xl border border-slate-200 overflow-hidden' },
    React.createElement(
      'div',
      { className: 'bg-gradient-to-r from-blue-600 to-indigo-600 px-8 py-6' },
      React.createElement(
        'h1',
        { 
          className: 'text-3xl font-bold text-white mb-2',
          id: 'main-heading'
        },
        'Complex Nested Example'
      ),
      React.createElement(
        'p',
        { className: 'text-blue-100 text-lg' },
        'This demonstrates more complex nesting with multiple elements and attributes.'
      )
    ),
    React.createElement(
      'div',
      { className: 'p-8 space-y-6' },
      React.createElement(
        'div',
        { className: 'space-y-4' },
        React.createElement('h2', { className: 'text-2xl font-semibold text-slate-800 border-b border-slate-200 pb-2' }, 'Subheading'),
        React.createElement('p', { className: 'text-slate-600 leading-relaxed' }, 'Another paragraph nested deeper in the structure with improved readability and spacing.')
      ),
      React.createElement(
        'div',
        { className: 'bg-slate-50 rounded-lg p-6' },
        React.createElement('ul', { className: 'space-y-3' },
          React.createElement('li', { className: 'flex items-center text-slate-700' }, 
            React.createElement('span', { className: 'w-2 h-2 bg-blue-500 rounded-full mr-3' }),
            'Enhanced Item 1 with better styling'
          ),
          React.createElement('li', { className: 'flex items-center text-slate-700' }, 
            React.createElement('span', { className: 'w-2 h-2 bg-blue-500 rounded-full mr-3' }),
            'Enhanced Item 2 with better styling'
          ),
          React.createElement('li', { className: 'flex items-center text-slate-700' }, 
            React.createElement('span', { className: 'w-2 h-2 bg-blue-500 rounded-full mr-3' }),
            'Enhanced Item 3 with better styling'
          )
        )
      ),
      React.createElement(
        'div',
        { className: 'flex justify-center pt-4' },
        React.createElement('button', { 
          className: 'bg-gradient-to-r from-blue-600 to-indigo-600 hover:from-blue-700 hover:to-indigo-700 text-white font-semibold px-8 py-3 rounded-full shadow-lg hover:shadow-xl transform hover:scale-105 transition-all duration-200 focus:outline-none focus:ring-4 focus:ring-blue-300' 
        }, 'Click me')
      )
    )
  )
);

createRoot(document.getElementById('root')).render(element)

Nesting, nesting and… nesting, yes it does work but it’ll be horrible to maintain and to read, that’s why JSX is useful, JSX is immediately more readable, familiar to anyone who knows HTML, and significantly easier to maintain.

I will deep-dive into JSX in a future article but here is the code with JSX

import React from 'react';
import { createRoot } from 'react-dom/client';
import './index.css';

const App = () => {
  return (
    <div className="min-h-screen bg-gradient-to-br from-slate-50 to-blue-50 flex items-center justify-center p-4">
      <div className="max-w-2xl w-full bg-white rounded-2xl shadow-xl border border-slate-200 overflow-hidden">
        <div className="bg-gradient-to-r from-blue-600 to-indigo-600 px-8 py-6">
          <h1 
            className="text-3xl font-bold text-white mb-2" 
            id="main-heading"
          >
            Complex Nested Example
          </h1>
          <p className="text-blue-100 text-lg">
            This demonstrates more complex nesting with multiple elements and attributes.
          </p>
        </div>

        <div className="p-8 space-y-6">
          <div className="space-y-4">
            <h2 className="text-2xl font-semibold text-slate-800 border-b border-slate-200 pb-2">
              Subheading
            </h2>
            <p className="text-slate-600 leading-relaxed">
              Another paragraph nested deeper in the structure with improved readability and spacing.
            </p>
          </div>

          <div className="bg-slate-50 rounded-lg p-6">
            <ul className="space-y-3">
              <li className="flex items-center text-slate-700">
                <span className="w-2 h-2 bg-blue-500 rounded-full mr-3"></span>
                Enhanced Item 1 with better styling
              </li>
              <li className="flex items-center text-slate-700">
                <span className="w-2 h-2 bg-blue-500 rounded-full mr-3"></span>
                Enhanced Item 2 with better styling
              </li>
              <li className="flex items-center text-slate-700">
                <span className="w-2 h-2 bg-blue-500 rounded-full mr-3"></span>
                Enhanced Item 3 with better styling
              </li>
            </ul>
          </div>

          <div className="flex justify-center pt-4">
            <button className="bg-gradient-to-r from-blue-600 to-indigo-600 hover:from-blue-700 hover:to-indigo-700 text-white font-semibold px-8 py-3 rounded-full shadow-lg hover:shadow-xl transform hover:scale-105 transition-all duration-200 focus:outline-none focus:ring-4 focus:ring-blue-300">
              Click me
            </button>
          </div>
        </div>
      </div>
    </div>
  );
};

createRoot(document.getElementById('root')).render(<App />)

And imagine if you just create component for each of your needs it will be cleaner and cleaner

What is the spread operator

The spread operator uses three dots (...) before a variable name. It "spreads" or expands the contents of arrays, objects, or strings into individual elements.

console.log([🍏,🍐,🍊]); // Output: [🍏,🍐,🍊]
// With spread operator
console.log(...[🍏,🍐,🍊]); // Output: 🍏 🍐 🍊

Using spread operator with Arrays

You can create a shallow copy of an array

const originalArray = [🍏,🍐,🍊];
const copiedArray = [...originalArray];

console.log(copiedArray); // [🍏,🍐,🍊]

You can merge multiple arrays easily

const fruits = [🍏, 🍌];
const vegetables = [🥕, 🍠];
const food = [...fruits, ...vegetables];

console.log(food); // [🍏, 🍌, 🥕, 🍠]

You can insert new elements while keeping existing ones

const healthyFood = [🍏, 🍌, 🥕, 🍠];
const moreHealthyFood = [🍑, ...healthyFood, 🥦, 🥑];

console.log(moreHealthyFood); // [🍑, 🍏, 🍌, 🥕, 🍠, 🥦, 🥑]

Using spread operator with Object

You can create a shallow copy of an object

const person = { name: 'Gilles', age: 29 };
const personCopy = { ...person };

console.log(personCopy); // { name: 'Gilles', age: 29 }

You can combine multiple objects into one

const person = { name: 'Gilles', age: 29 };
const contactInfo = { email: 'gilles@email.com', phone: '123-456-7890' };
const fullProfile = { ...person, ...contactInfo };

console.log(fullProfile);
// { name: 'Gilles', age: 29, email: 'gilles@email.com', phone: '123-456-7890' }

You can override specific properties of an object while keeping others

const person = { name: 'Gilles', age: 29, city: 'Toulouse' };
const updatedPerson = { ...person, age: 29, country: 'France' };

console.log(updatedPerson);
// { name: 'Gilles', age: 29, city: 'Toulouse', country: 'France' }

Using Spread with Function Arguments

You can pass array elements as separate arguments to functions:

function addThreeNumbers(a, b, c) {
    return a + b + c;
}

const numbers = [5, 10, 15];
const result = addThreeNumbers(...numbers);

console.log(result); // 30

Using Spread with Strings

You can spread a string into individual characters:

const word = 'hello';
const letters = [...word];

console.log(letters); // ['h', 'e', 'l', 'l', 'o']

Important Notes

Shallow Copy Limitation

The spread operator creates shallow copies, not deep copies. This means nested objects or arrays are still referenced:

const original = { 
    name: 'Gilles', 
    hobbies: ['reading', 'coding'] 
};

const copy = { ...original };
copy.hobbies.push('cycling');

console.log(original.hobbies); // ['reading', 'coding', 'cycling']
// The original object is affected!

Order Matters

When merging objects, properties from later objects override earlier ones:

const obj1 = { a: 1, b: 2 };
const obj2 = { b: 3, c: 4 };
const merged = { ...obj1, ...obj2 };

console.log(merged); // { a: 1, b: 3, c: 4 }
// obj2.b overrides obj1.b

Deep Copying with Spread

While the spread operator creates shallow copies, you can achieve deep copying by combining it with other techniques:

// For simple nested objects (no functions, dates, etc.)
const original = {
    name: 'Gilles',
    address: { city: 'Toulouse', country: 'France' },
    hobbies: ['reading', 'coding']
};

const deepCopy = {
    ...original,
    address: { ...original.address },
    hobbies: [...original.hobbies]
};

// Now changes to deepCopy won't affect original
deepCopy.address.city = 'Montréal';
deepCopy.hobbies.push('cycling');

console.log(original.address.city); // 'Toulouse' (unchanged)
console.log(original.hobbies); // ['reading', 'coding'] (unchanged)

Real life example in React and Angular

React Use Cases

The spread operator is essential in React for:

• State updates: Change one property in a state object while keeping others unchanged

• Props passing: Send multiple properties to child components at once

• Array state management: Add or remove items from lists without mutating the original array

• Event handling: Create new objects when updating form data

• Component composition: Combine default props with custom props

Angular Use Cases

In Angular, the spread operator helps with:

• Data binding: Update component properties while preserving existing data

• Array manipulation: Add, remove, or modify items in lists for templates

• Form handling: Create updated objects when processing form submissions

• API responses: Merge server data with local component state

• Template data: Combine multiple data sources for display

Both frameworks benefit from the spread operator because it helps create new objects and arrays instead of modifying existing ones, which prevents unexpected bugs and makes applications more predictable.

Conclusion

The spread operator is a powerful tool that makes JavaScript code cleaner and more readable. It simplifies many common tasks like copying arrays, merging objects, and passing arguments to functions. With careful use, you can even achieve deep copying without external libraries.

Practice using the spread operator in your projects to become more comfortable with this essential JavaScript feature. Start with simple cases and gradually work your way up to more complex scenarios.

Hello friends 🚀! As we saw in the previous article, one of NX's core features is the ability to create libraries. These libraries can be categorized into different types, each serving a unique purpose and playing a specific role in your project. Understanding these library types is crucial for organizing your codebase efficiently and making the most of NX's powerful capabilities. Even without NX, it's a good idea to separate your codebase into libraries. NX helps you leverage all of these benefits.

Feature library

Feature libraries encapsulate a specific feature or functionality within your application. They are designed to be reusable and can be imported into multiple applications as a feature. The feature library will include everything you need to create a functionality. It can import all other types of libraries to build it. It can also import other feature libraries to create a larger one.

Example : You could create a weather widget that you want to display in multiples of your application

So you will create a grouping folder named weather-widget and generate your library

weather-widget/feature -> your feature

We will see what you can import on this library and why below

Ui library

UI libraries focus on providing reusable, simple UI components. These components are generally presentational and do not contain any business logic. By centralizing your UI components in libraries, you ensure consistency across your application and make it easier to update and maintain your UI. UI libraries can import utility libraries and other UI libraries, but they cannot import feature libraries or data-access libraries. A dumb component cannot contain an entire feature or a service to manage your application's data. It makes sense.

Example : For your weather-widget you will need to create a dumb component that will take some inputs coming from the back-end, and display the actual weather in a nice way.

weather-widget/feature -> your feature

weather-widget/ui -> the dumb component stuff for your feature

Data-access library

Data access libraries handle interactions with external data sources, such as APIs or databases. They encapsulate the logic for making HTTP requests, handling data transformations, and managing state related to data access. This separation helps keep your feature libraries clean and focused on their specific responsibilities. Since you need to expose your interface in other libraries, you should store the interface linked to your service in another type: util. You can import both data-access and util types into data-access.

Example : For your weather-widget you will need to create a service so your feature will be able to get the current weather data and display it with it's dumb component

weather-widget/feature -> your functionnality

weather-widget/ui -> the dumb component stuff for your feature

weather-widget/data-access -> the service to get the data for your feature

Util library

As explained above, sometimes you will need to make imports that aren't possible without a type that doesn't depend on others. The Util library exists for this reason. Util(ity) libraries are collections of reusable types, interfaces, helper functions, pipes, and other utilities that can be used throughout your application. This library can be imported by any other existing types because it only depends on other util libraries.

Example : For your weather-widget you will need to create an interface for the data so you can use this interface in : feature for the input, ui to structure your dumb component, and in data-access to correctly type the object coming from the back-end.

weather-widget/feature -> your functionnality

weather-widget/ui -> the dumb component stuff for your feature

weather-widget/data-access -> the service to get the data for your feature

weather-widget/util -> the interface for the data for your data-access

Shell library

In NX, a "shell" library refers to a routing library that exposes routes, allowing it to be imported into multiple applications seamlessly. This type of library is particularly useful in a microfrontend architecture or in scenarios where you want to share a common routing configuration across several applications.

Overview

Can I create other types ?

Of course you can create as much types as you need, a good practice is trying to keep the number of them low. Because it can be hard to understand or you will need to document it clearly so every new member of your team can understand the goal of each types.

Example : You could create state libraries to separate data-access services and state management in your application. This way, feature libraries wouldn't depend directly on data-access services. You could also add a facade library so that features wouldn't depend on state libraries directly. Instead, the facade would depend only on state libraries.

In next article we will see how to enforce these rules with ESLint and NX.

Ressources

https://nx.dev/concepts/decisions/project-dependency-rules

Hello friends 🚀! In a monorepo, the mindset shifts from thinking in terms of applications to thinking in terms of libraries. This approach encourages the creation of reusable, modular code that can be shared across multiple applications. To illustrate this concept, I will demonstrate how to create a reusable button component.

Initially, I could implement this button directly within the apps directory because my immediate need is to display it in my register-front application. However, by doing so, I limit the reusability of this component. What if, in the future, I need to use this button in a different application within the same monorepo? By coding it as a library from the start, I ensure that this button is easily accessible across all my applications.

Creating the button as a library doesn't require much extra effort, but it brings significant benefits:

1. Reusability: Libraries are designed to be reusable across multiple applications. By placing the button component in a library, I can import and use it in any current or future applications within the monorepo.

2. Maintainability: Centralizing the button component in a library makes maintenance easier. Any updates or bug fixes to the button can be made in one place, and all applications using the library will automatically benefit from the changes.

3. Consistency: Using a library ensures that the button component behaves consistently across all applications. This helps in maintaining a uniform user experience and reduces the risk of discrepancies.

4. Separation of Concerns: Libraries promote the separation of concerns by encapsulating specific functionalities. This modularity makes the codebase cleaner and easier to understand.

5. NX Advantages: NX provides powerful tools for managing libraries, such as dependency graph visualization, and efficient incremental builds. Leveraging these tools enhances the development experience and optimizes the build process.

By coding the button component as a library, I am taking full advantage of NX's capabilities, ensuring my code is modular, reusable, and maintainable. This approach aligns with best practices in modern software development and sets the foundation for scalable and efficient applications.

Let's create our first library

The first step to create a library is to create a folder libs at the root of the project

To determine the scope of my library, I need to ask where this feature will be used. For a button, it's straightforward—I need to use it everywhere. So, I will create a new folder called shared. This shared folder can be considered as a scope.

I could put my library directly in the shared folder, but with more experience, you'll see that it's easier to be very precise. So, I will create a grouping folder for all my shared dumb components and another grouping folder for my button.

Finally, I can create my library. As a developer, I appreciate simplicity, and thankfully NX makes it easy. I will use the NX CLI to create it. However, since using the CLI can be tedious, I will use the NX Console instead.

I use Angular so I choose Library @nx/angular in NX Console, and I can fill the form

Library name: It's a good practice to name libraries in their grouping folders by their types. We will discuss library types in the next article. I will use ui for the name. "ui" will be the type of library for every dumb component.

Directory : Pretty straightforward, I need to put my library in shared/ui-components/button.

Tags: In a future article, you will see that tags are very important. The scope of my library is shared, and the type of my library is UI: scope:shared,type:ui.

In your console you can see the command that will be launched when you are done. What you see is called a dry run. A "dry run" in NX allows you to simulate the effects of a command without making actual changes. This is done using the --dry-run (or -d) flag.

nx g @nx/angular:library --name=ui --directory=shared/ui-components/button --projectNameAndRootFormat=derived --skipTests=true --tags=scope:shared,type:ui --no-interactive --dry-run

Now you understand why it's easier to generate a library with NX Console!

You can also check the result in the console to make sure it's correct:

Then you can just run it :

Here you go! Your first library is generated. In the next article, I will explain module boundaries and how to use scope and types.

In the future I will explain how we can just infer the task and get rid of all these configuration files.

Ressources

NX Console for your IDE : https://nx.dev/getting-started/editor-setup#official-integrations
Project Crystal NX, Inferred Tasks : https://nx.dev/concepts/inferred-tasks
Module boundaries : https://nx.dev/features/enforce-module-boundaries

.github: This folder contains the configuration for GitHub Actions. We will cover how to use it in another article.

.nx: This hidden folder stores various configuration and cache files used by the NX tool.

1. Cache Files: These files store the results of previous builds, linting, and testing tasks. NX uses these cache files to speed up future runs of the same tasks, making the build process more efficient.

2. Temporary Files: NX may use this directory to store temporary files needed during the execution of various tasks.

3. Configuration Files: Some settings specific to NX are stored here. These settings can include task runner configurations, workspace configurations, and other metadata.

The .nx folder is crucial for NX's ability to optimize and manage builds and other tasks in a monorepo setup. It ensures that tasks are executed efficiently by using caching and incremental builds. I will explain more about this in details soon.

apps: This folder is important as it contains all your applications. In my project, you can see two apps: one for the Angular app and one for the E2E tests. However, you can have many others here, including Angular, React, Nest, Node apps...

But here's the trick: we won't code much in the apps folder because, with NX, you will think like a library creator.

.eslintrc.json: NX enhances ESLint by adding smart features that make linting faster and more efficient in a monorepo setup

1. Unified Configuration: NX helps you manage a single set of linting rules that can be shared across all projects in your monorepo, ensuring consistency.

2. Faster Linting with Caching: NX uses caching to remember which files have been linted before, so it only checks the files that have changed, speeding up the process.

3. Linting Only What Matters: Instead of running ESLint on the entire codebase, NX allows you to lint only the projects that were affected by recent changes, saving time and money.

In essence, NX makes ESLint smarter and faster, helping maintain code quality efficiently in large monorepos.

jest.config.ts & jest.preset.js: NX comes with Jest automatically integrated, making it easy to set up and run tests in your projects. Jest is a popular testing framework, and NX ensures that it’s seamlessly incorporated into your development workflow.

NX’s integration with Jest simplifies the testing process, providing a ready-to-use setup and powerful customization options. By automating the configuration and offering easy commands to run tests, NX helps you maintain high code quality with minimal effort. Whether you’re working on a single project or managing a complex monorepo, NX and Jest together make testing straightforward and efficient.

nx.json: This file is structured to provide detailed configuration for various aspects of your workspace/monorepo, such as:

• Named Inputs: Defines sets of files that influence the caching mechanism. You can specify which files should be considered when determining whether to re-execute tasks like builds or tests, allowing for both default and environment-specific configurations.

• Target Defaults: Configures default behaviors for specific tasks (referred to as targets). This includes settings like caching, dependency rules (dependsOn), and specific inputs required for the task execution. It allows for optimizing performance and ensuring consistency across environments.

• Plugins: Defines configurations for plugins used within the NX workspace, such as Cypress or ESLint. This section details how these tools should interact with your projects, including target names and specific execution options.

• Generators: Specifies default configurations for generating assets, such as applications or libraries, using tools like Angular CLI or NX's own schematics. Settings can include which test runner or linter to use, what style format to apply, and other project-specific defaults.

• Access Tokens: In cases where NX Cloud is used, this field might contain access tokens to authenticate and connect your local development environment with NX Cloud.

package.json: I understand, you already know what is a package.json file, but here is a twist, in a monorepo you should find only one package.json that define dependencies

Using a single package.json in an NX monorepo offers several advantages:

1. Consistency: Ensures all projects use the same versions of dependencies, avoiding conflicts.

2. Simplified Management: One place to manage updates and audits, making maintenance easier.

3. Efficient Installation: Single installation step for all projects speeds up setups and CI pipelines.

4. Resource Savings: Reduces disk space by avoiding duplicate package installations.

5. Tooling Efficiency: Centralizes tools and scripts, improving build and automation processes.

6. Easier Collaboration: Simplifies onboarding and collaboration by standardizing the development environment across projects.

These benefits make a single package.json essential for scalable and efficient development in NX monorepos.

tsconfig.base.json: If you are familiar with Typescript you already know, this is a centralized configuration of TypeScript on your monorepo, all the others projects can inherit of this base.

Understanding the structure of an NX project is essential for efficiently managing a monorepo. By leveraging the various folders and configuration files, you can optimize your workflow, ensure consistency, and maintain high code quality. NX's powerful features, including caching, incremental builds, and integrated tools like ESLint and Jest, make it a robust solution for modern development needs.

In the next article, we will create our first library, and more importantly, I will introduce module boundaries.

Ressources

https://nx.dev/

But what is NX ?

I discovered NX in 2019, I used it to manage several Angular apps for a big french bank, and I still use it in my day to day job. I love this tool and it completly changed my way of coding.

NX is a smart, extensible build framework for monorepos but you can use it outside a monorepo too, it helps developers manage and scale multiple projects with ease.

Developed by Nrwl, NX supports modern front-end frameworks like Angular, React, and others, providing powerful tools for code generation, testing, and optimization. It promotes best practices in software development, such as modularization, incremental builds, and a robust dependency graph, making it ideal for large-scale applications and teams.

Installation

Basic stuff

NX gives you a nice command

npx create-nx-workspace@latest

You can choose a workspace name : blog-monorepo in my example

This is not an application name; it's the name of your monorepo. It can be your organization name.

You can choose your stack : Angular

NX will configurate your favorite stack, of course if you need more you will be able to do so after the installation, it's very extensible

Integrated or standalone ?

Earlier in the article, I mentioned that you can use NX with or without a monorepo.

Here I want to show you how to work in a monorepo, but you can use NX for just one application

Application

You can choose your Angular app name

You can choose your bundler : I will recommand esbuild, it's the new default of Angular since version 17

Other stuff

You can also choose

• Default stylesheet format

• If you will need SSR or not

• Your E2E test runner

• You can choose whether or not to use NX Cloud. I will write articles about this tool

Boom 💥 you are all set

That's it! Yes, I know, it's amazing.

NX set up everything for you, installed dependencies, and now you are ready to work!

In the next article, I will show you the project structure and explain the purpose of all the files.

Ressources

https://nx.dev/

Create or use your Angular project

ng new project
cd project

**Install and configure TailwindCSS **

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init # Will generate a file tailwind.config.js

Configure the paths of all your template files

Edit your tailwind.config.js to add these lines :

module.exports = {
  content: [
    "./src/**/*.{html,ts}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Add TailwindCSS directives to your CSS file style.css

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

**Enjoy using TailwindCSS ** ng serve

When you generate a new Angular project, it comes with some tools for unit testing, Karma and Jasmine

Sometimes you need to replace theses tools with another framework like Jest

What is Jest ?

Jest is a testing framework developed by Facebook, it is very popular for unit testing in React. It comes with a lot of tools :

• Mocking tools

• Assertions tools

• Code coverage

• JSDOM library to allow Jest to run outside a browser, it is very useful to run test on CI

• Watch mode to re-run only affected tests ...

Why Jest instead of Karma and Jasmine

We like to use Jest instead of Karma and Jasime because it can run without a browser, and it can run easily on CI. Also Jest is way faster than Karma, it's well documented, you can run only affected tests...

Jest can come with @types/jest package which contains type declaration, useful for type checking for example

Jest Preset Angular

jest-preset-angular is Jest preset configuration and TypeScript preprocessor with source map support for Jest that lets you use Jest to test Angular projects.

Installation

To install jest-preset-angular and dependencies all at once you can use

with npm npm install -D jest jest-preset-angular @types/jest or with yarn yarn add -D jest jest-preset-angular @types/jest

Configuration

In your project root create a file setup-jest.ts

import 'jest-preset-angular/setup-jest';

and a file jest.config.js

module.exports = {
  preset: 'jest-preset-angular',
  setupFilesAfterEnv: ['<rootDir>/setup-jest.ts'],
  globalSetup: 'jest-preset-angular/global-setup',
};

Edit your tsconfig.spec.json like this { "extends": "./tsconfig.json", "compilerOptions": { "outDir": "./out-tsc/spec", "module": "CommonJs", "types": ["jest"] }, "include": ["src/**/*.spec.ts", "src/**/*.d.ts"] } Edit your package.json ... "watch": "jest --watch", "test": "jest" ...

You can now run test with npm run test

Clean up Karma and Jasmine

You can now remova Karma and Jasmine from your project

Delete src/test.js

Delete in angular.json

        "test": {
          ...
        }

Run in terminal this command to clean up all dependencies

npm uninstall @types/jasmine jasmine-core karma karma-chrome-launcher karma-coverage karma-jasmine karma-jasmine-html-reporter

or

yarn remove @types/jasmine jasmine-core karma karma-chrome-launcher karma-coverage karma-jasmine karma-jasmine-html-reporter

Sources :

https://www.xfive.co/blog/testing-angular-faster-jest/

https://thymikee.github.io/jest-preset-angular/docs/

undefined

In JavaScript, undefined means a variable has been declared but has not yet been assigned a value or assigned undefined :

// console.warn(notDeclared); // Impossible not defined
console.warn(typeof notDeclared); // logs : undefined

let test;
console.warn(test); // logs : undefined
console.warn(typeof test); // logs : undefined

const testConst = undefined;
console.warn(testConst); // logs : undefined
console.warn(typeof testConst); // logs : undefined

// Impossible, missing initializer in const declaration
/* const testConst2; 
console.warn(testConst2); // Broken code
console.warn(typeof testConst2); // Broken code */

null

Unlike undefined, null is an assignment value, null can be assigned to a variable as a representation of no value :

const test = null;
console.warn(test); // logs : null
console.warn(typeof test); // logs : object

As you can see undefined and null are very different undefined is a type itself, and null seems like an object but no it is in reality a primitive value

To understand why null is not an object I will quote a sentence from the book Professional JavaScript for Web Developers :* "You may wonder why the typeof operator returns 'object' for a value that is null. This was actually an error in the original JavaScript implementation that was then copied in ECMAScript. Today, it is rationalized that null is considered a placeholder for an object, even though, technically, it is a primitive value."*

More examples

Sometimes JavaScript is fun, or horrible depending on how you feel 🤒

console.warn(null === undefined); // logs : false
console.warn(null == undefined); // logs : true
console.warn(null === null); // logs : true

// null = 'value'; // Impossible ReferenceError
// let undefined = 'value'; Impossible trick :
// Identifier 'undefined' has already been declared

// /!\ DON'T DO THIS /!\
(function () {
  var undefined = 'wtf';
  console.warn(undefined, typeof undefined); // logs : wtf string
})();

// /!\ DON'T DO THIS /!\
(function (undefined) {
  console.warn(undefined, typeof undefined); // logs: wtf2 string
})('wtf2');

That's it for undefined and null !

🚀 In my next article you can learn how to use conditions in JavaScript 🚀

In JavaScript likes others languages we are using variables ! 😱

They are containers for storing data values, in this article I will just explain how to use them, because the entire subject is a little bit hard, and at the beginning you don't need to know everything to start using them.

Examples

If you want to know the difference between let and var I can recommend this fantastic article by Flavio Copes : Click me

In all cases you should try it ! It's very simple but it's a must in every language 🤘

🚀 In my next post you can learn what is undefined in JavaScript 🚀

Hello World

As usual the first thing to do when you are beginning a new language : Hello World !

Why Hello World ? 😉

In JS they are multiple different ways to do that :

• Using alert box
• Using the console
• Modifying the DOM ...

I coded for you few examples, feel free to do the same thing on your computer, you just need a text editor and a web browser to open your HTML file 👊

Code

Explanations

alert() method will open an alert box when the page is loaded containing the string that you passed in

console.log() method is logging your string as a message in the console

console.warn() method is logging your string as a warning in the console

document.querySelector("#id") is returning the DOM element with ID, and textContent will help to add text to this element

🚀 In my next post you can see how to declare variables in JS 🚀

JavaScript

JavaScript or JS is now considered as a high-level programming language and it's currently one of the most popular language in use, it was originally developed as a scripting language by Netscape to make websites more dynamic.

Possibilities of JavaScript

• Literally everything 😱 ...
• Change DOM (Document Object Model)
• Add CSS dynamically
• Track users move on your website
• Validate inputs in HTML form
• Use AJAX to load data without refreshing page
• Create re-usable components
• HTTP Request to your back-end
• Unit testing
• End-to-end testing
• Create your back-end
• Create animations
• Create PWA (Progressive Web Apps)
• Create Mobile Apps
• Create games
• Create software (VS Code) ...

It's impossible to cite everything, JavaScript is just too big 💪

That's why JS is fascinating, and that's why you should learn it ! In the beginning It may seem a little bit difficult compared to others languages, but practice makes perfect !

🚀 In my next post you can see some example of JS 🚀

Ressources

Mozilla Developer

Wikipedia

W3Schools