Forem: Giuseppe Ciullo

Orchestrating Scalable Frontends: The Power of the Composition Root

Giuseppe Ciullo — Fri, 20 Feb 2026 10:39:29 +0000

In previous chapters, we built the foundations of our frontend architecture. With Atomic Design, we organized our UI into shared/components, separating reusable, domain-agnostic elements from specific contexts. With Feature-Driven Architecture, we isolated the domain by introducing features/ as autonomous business units.

But a real-world application isn't just a collection of isolated modules. It is a system where domains must collaborate. The question becomes inevitable: How can we allow features to communicate with each other without destroying the isolation we just built?

The answer lies in introducing a higher level of orchestration: the Pages layer acting as a Composition Root.

Revisiting the Structure

Our architecture, consistent with our previous principles, looks like this:

src/
├─ shared/             # Reusable UI & utilities (Atomic Design)
├─ features/           # Isolated domains (Feature-Driven)
│   ├─ cart/
│   └─ checkout/
├─ pages/              # Orchestration & Composition Layer
└─ app/                # Global bootstrapping

We have already defined a fundamental rule: A feature can depend on shared/, but it must not know about the existence of other features. features/cart should never import anything from features/checkout. This is not a technical limitation; it is a design choice that preserves domain independence.

The Risk of the "Cannibal Feature" (God Feature)

Why can't we just let features talk to each other? Because refusing a higher orchestration layer exposes us to a fatal risk: Feature Cannibalization.

In a flat architecture, if the Cart needs to trigger the Checkout, a developer will eventually be forced to import the Checkout module into the Cart. At that moment, isolation vanishes. One of the two features "eats" the other, becoming a bloated module—a God Feature—that drags along dependencies, logic, and types that do not belong to it.

The Illusion of Simplicity

Eliminating the pages/ layer might seem like a simplification. In reality, we are just hiding complexity. If the Cart feature contains the navigation logic to the Checkout, that component is no longer truly reusable. If you wanted to use that Cart in an informational Sidebar without a checkout tomorrow, you couldn't do it without dragging along the entire payment system.

The principle is clear: A Feature must be "dumb" regarding the global context to be "smart" regarding its business logic.

Pages as a Composition Root

In the book Clean Architecture, Robert C. Martin introduces the concept of the Composition Root. It is the place where dependencies are assembled and modules are composed. In the frontend, the Page represents this architectural pivot.

The Page is not just a route container; it is the level where:

Features are instantiated.
Their contracts (callbacks, events) are connected.
Responsibilities are coordinated.

The Director and the Actors

Think of the Page as a Theater Director:

Features are the actors: they know how to play their part perfectly, but they don't decide when to enter the stage.
The Page is the director: it knows that when Actor A (Cart) emits an event, it must signal Actor B (Checkout) to step in.

Hierarchy of Responsibilities

The architecture takes a clear shape based on decreasing knowledge:

Layer	Responsibility	Knowledge Level
app/	Bootstrapping	Knows everything (Global State, Routing)
pages/	Orchestrate	Knows multiple features, but not their internal logic
features/	Domain	Knows only itself
shared/	Utility	Domain Agnostic (Knows nothing of business)

The correct flow is always vertical:
Feature A ← Page → Feature B
(Never: Feature A → Feature B)

Substitutability and Maturity

Many codebases start by allowing direct communication between modules. It works while the project is small. Over time, changes propagate unpredictably.

Introducing an explicit orchestration layer is the moment a project stops being just "functional" and becomes truly evolvable. Imagine wanting to replace the checkout/ domain entirely:

features/
├─ cart/
├─ checkout/
└─ new-checkout/

The only change occurs in the pages/ layer. The Cart remains untouched. This is possible because orchestration is centralized in the composition root, not distributed across features.

The Core Principle

Features solve business problems.
Pages solve coordination problems.

Atomic Design gave us order in the UI. Feature-Driven Architecture gave us domain isolation. The Pages layer gives us control over the flows. Separation is important, but knowing where to compose is even more vital.

Next Step: Toward the Page-Level Store

As long as the data flow is linear, composition via props in the Page is sufficient. But what happens when multiple features must stay synchronized in real-time or a complex dashboard requires shared state without violating isolation?

In the next article, we will explore the Page-Level Store: an ephemeral, page-scoped state that allows fluid communication while keeping domain boundaries intact.

Connect on LinkedIn for more updates and insights.

Feature-Driven Architecture: Designing Scalable Applications

Giuseppe Ciullo — Mon, 02 Feb 2026 10:02:27 +0000

Introduction

In the first article of this series, we discussed Atomic Design as a method to build coherent, reusable, and well-composed interfaces.
It’s an extremely effective approach when the main challenge is organizing the UI.

But as an application grows, the UI soon stops being the real problem.

Code increases, features multiply, requirements change faster than we’d like. At that point, new questions arise:

Where does the application logic really live?
How can we modify one feature without breaking others?
How can multiple people work on the same codebase without stepping on each other’s toes?

This is where architectural scalability comes into play.
And it’s exactly where Atomic Design alone is not enough.

Scalability is not just performance

When we talk about scalability, we often immediately think about performance, load, or infrastructure.
In reality, the first scalability problem is the code itself.

An application doesn’t scale when:

Every new feature requires changes in multiple places
Logic is scattered and hard to trace
Dependencies between parts of the application are implicit and fragile
Understanding the context of a change is more expensive than the change itself

In short: it doesn’t scale when cognitive overhead grows faster than the code.

Feature-Driven Architecture exists precisely to address this problem.

What a feature really is

A feature is not a single screen.
It’s not even an isolated function.

A feature is a unit of value for the user.

From an architectural point of view, a feature represents:

A clear objective
A complete behavior
A well-defined context

When a user says “I want to do X”, they are usually referring to a feature.

Thinking in terms of features shifts the focus:

From technology to domain
From technical layers to functional value

And this shift is what enables scalability.

Feature-Driven Architecture: the key principle

The core principle is simple:

Organize code around features, not technical layers.

Each feature becomes a cohesive container that includes everything needed to implement that behavior.

This doesn’t mean eliminating technical concepts, but reducing their visibility at a global level.
Details stay local to the feature, where they make sense.

The main advantage:

A feature can evolve independently
Context is clear and limited
The system grows by addition, not by entanglement

And this is how an architecture scales.

Example: the `cart` feature

To make this more concrete, here’s an example of how a single feature might be organized:

features/
└─ cart/
    ├─ components/   # UI elements specific to the cart
    ├─ helpers/      # reusable functions or logic helpers specific to the cart
    ├─ state/        # state management for the cart (local or global)
    ├─ views/        # pages or screens related to the cart
    ├─ types/        # type definitions or interfaces
    ├─ tests/        # tests for cart feature
    ├─ mocks/        # mock data or services for testing/development
    └─ index.ts      # entry point for exposing public parts of the feature

Example `index.ts`:

// Only expose what should be used outside the feature
export * from './components';
export * from './helpers';
export * from './types';

// Do NOT export state, views, tests, or mocks
// These remain internal to the feature

⚠️ Important rules for exposing feature parts

Expose only what is meant to be used outside the feature.
Components, helpers, and types are usually safe to export.
Keep everything else private.

state/ → internal state logic
views/ → screens or containers
tests/ → testing code
mocks/ → fake data

Always use the index.ts as the single entry point for external usage. This keeps the feature encapsulated and makes the boundaries clear.

Combining Atomic Design and Feature-Driven Architecture

Atomic Design and Feature-Driven Architecture are not mutually exclusive—they can complement each other perfectly.
While features contain the business logic, state, views, and tests, Atomic Design provides a shared language for building UI components that can be reused across multiple features.

Here’s an example of how the folder structure could look when combining both approaches:

features/
├─ cart/
│   ├─ components/
│   ├─ helpers/
│   ├─ state/
│   ├─ views/
│   ├─ types/
│   ├─ tests/
│   ├─ mocks/
│   └─ index.ts
├─ checkout/
└─ wishlist/

shared/
├─ components/
│   ├─ atoms/        
│   ├─ molecules/    
│   └─ organisms/    
└─ utils/            # shared utilities, helpers, and services

Key points:

shared/components/atoms, molecules, organisms → reusable UI building blocks
features/ → contains everything a feature needs to work independently
Features can use shared atomic components while keeping their own feature-specific components inside components/
This approach keeps reusability clear, modularity high, and boundaries well defined, allowing both UI and business logic to scale independently

By combining Atomic Design with Feature-Driven Architecture, we get the best of both worlds:

consistent, reusable UI
scalable, autonomous features

Features and reusability: a mindset shift

One of the most interesting effects of this approach is how it changes the concept of reusability.

In a Feature-Driven Architecture:

A feature is not reusable by default
Reusability is a conscious choice, not an initial requirement

This is very different from how we often think about architecture, especially on the UI side.

Atomic Design remains extremely useful, but its role changes:

It builds generic, stable elements
It doesn’t force reusability where it’s not needed

The feature becomes the place where complexity is accepted and managed.
Shared elements become few, solid, and truly generic.

Less premature abstraction, more clarity.

Scaling the team, not just the code

Another often overlooked aspect of scalability is the human factor.

When code is organized around features:

Responsibilities are easier to assign
The context is clearer
Conflicts decrease

Features become a natural unit for:

Planning
Parallel development
Testing
Maintenance

In practice, the architecture begins to reflect the way people think and work.
And that’s one of the strongest signs of a system that truly scales.

When it makes sense to adopt this approach

Feature-Driven Architecture is not a silver bullet.

It makes sense when:

The application is expected to grow
The domain is non-trivial
Multiple people work on the same codebase
Change is constant, not exceptional

In very small applications, the initial overhead might not be justified.
But when complexity is real, not organizing around features becomes more costly in the long run.

Conclusion

Feature-Driven Architecture teaches us to look beyond a single screen or component: organizing code around independent features reduces the risk of conflicts, isolates contexts, and makes the application clearer and easier to maintain.

Scalability, in this sense, is not just a technical goal—it’s the ability of both the code and the team to grow without chaos. Each feature becomes a manageable ecosystem that can evolve without compromising other parts of the application.

In the next article, we’ll explore how to combine multiple features, orchestrate them, and make them work together without losing cohesion—taking a collection of independent units and turning it into a truly scalable frontend.

Connect on LinkedIn for more updates and insights.

[Boost]

Giuseppe Ciullo — Fri, 16 Jan 2026 10:08:41 +0000

Atomic Design: From UI Composition to Real-World Applications

Giuseppe Ciullo ・ Jan 15

#frontend #webdev #architecture #react

Atomic Design: From UI Composition to Real-World Applications

Giuseppe Ciullo — Thu, 15 Jan 2026 15:49:07 +0000

Atomic Design is one of the most frequently mentioned patterns when talking about frontend architecture.
It’s easy to explain, easy to visualize, and it works really well… until the application starts to grow.

The problem is not Atomic Design itself, but the role we assign to it.
Using it as an application architecture leads to rigid structures that are hard to test and even harder to evolve.

In this article we’ll explore:

what Atomic Design does really well
where its structural limits begin to show
how to place it correctly inside a modern frontend architecture

This is the first chapter of a series dedicated to frontend application architectures.

Atomic Design is a composition pattern, not an architecture

Atomic Design was created to solve a specific problem:
building consistent user interfaces by composing small, reusable components.

The model is well known:

Atoms
Molecules
Organisms
Templates
Pages

All of this answers one question:

How do I build the UI?

It does not answer questions like:

where does the domain live?
who orchestrates application flows?
how does the application scale?

And this is where the misunderstanding often begins.

The real-world short circuit

Organisms that turn into mini applications

A typical “organism” that grows over time often ends up looking like this:

fetchData()
applyBusinessRules()
manageGlobalState()
renderUI()

At this point:

it is no longer a presentational component
it becomes hard to test
it is tightly coupled to a single feature

The UI turns into the place where logic accumulates, creating a monolith disguised as components.

The false Molecule vs Organism problem

Many teams spend time asking:

“Is this component a molecule or an organism?”

In practice, this distinction is often subjective and largely irrelevant.
In a healthy architecture, the real question is:

Does this component know about the domain?

If the answer is yes, it does not belong in Atomic Design, regardless of what you call it.

The problem is not Atomic Design

Atomic Design:

✅ organizes the UI
❌ does not define domain boundaries
❌ does not orchestrate application flows
❌ does not manage business state

Expecting it to do so means using it out of context.

A proposal: separate UI and application architecture

A sustainable frontend architecture is built on a clear separation between:

UI Composition
Application Architecture

Atomic Design should live only in the first layer.

Atomic Design as a UI library (with a key rule)

shared/
 └─ ui/
     ├─ atoms/
     ├─ molecules/
     └─ organisms/

UI state vs Business state

Components in shared/ui may have state, but only if it is:

ephemeral
interaction-related
not a business decision

Valid examples:

isOpen
isHovered
isActive

Invalid examples:

global data
backend-synchronized state
application-level cache

UI components should never be aware of:

Redux / Zustand
data-fetching libraries
domain logic

Dependency Rule (non-negotiable)

Components in shared/ui must never import anything from features/

This single rule:

prevents hidden coupling
keeps the UI truly reusable
preserves architectural clarity over time

Features as the primary architectural unit

features/
 ├─ products/
 ├─ cart/
 └─ checkout/

Features contain:

business state
side effects
orchestration
UI composition

This is where the intelligence of the application lives.

Testing strategy: an often underestimated benefit

This separation improves not only the codebase, but the way we test.

UI (Atomic Design)

Storybook
visual regression testing
visual snapshots
accessibility testing

Focus:
👉 “Does this component look and behave correctly?”

Features (Application Architecture)

integration tests
flow tests
interaction between state, APIs, and UI

Focus:
👉 “Does this use case work?”

Separating UI and architecture also means separating testing responsibilities.

Why this approach works

Atomic Design stays simple
the UI is predictable and reusable
features are isolatable
the domain is readable from the file system
the application scales without increasing chaos

Each layer has a clear responsibility.

Conclusion

Atomic Design is not your architecture.
And that’s exactly why it works so well.

Used as a UI composition pattern, it is an excellent tool.
Used as an application architecture, it becomes a source of complexity.

In the next article of this series, we’ll dive into a feature-driven architecture, designed to organize logic, state, and domain at scale.

Connect on LinkedIn for more updates and insights..

Still splitting text with .split(" ")? Intl.Segmenter is the native way to handle words, sentences, and characters — correctly, across languages. No regex. No hacks. Just smart, locale-aware segmentation.

Giuseppe Ciullo — Wed, 12 Nov 2025 09:57:57 +0000

Stop Splitting Strings the Wrong Way: Discover Intl.Segmenter

Giuseppe Ciullo ・ Nov 11

#webdev #javascript #programming #tutorial

Stop Splitting Strings the Wrong Way: Discover Intl.Segmenter

Giuseppe Ciullo — Tue, 11 Nov 2025 11:44:20 +0000

How many times have you done this?

const text = "I love pizza and pasta";
text.split(" ");
// ["I", "love", "pizza", "and", "pasta"]

Looks fine — until you deal with punctuation, multiple spaces, or languages that don’t even use spaces.
Try splitting a French sentence with apostrophes, or a Japanese one with no whitespace at all.
Suddenly .split(" ") feels more like a guess than a rule.

That’s where Intl.Segmenter comes in.

What Is `Intl.Segmenter`?

Intl.Segmenter is part of the JavaScript Internationalization API.
It splits text into human-perceived units — words, sentences, or characters — using the rules of a specific language.

In other words, it doesn’t just separate symbols.
It understands how people actually read and write.

Understanding Granularity

The secret sauce of Intl.Segmenter lies in its granularity — the level at which text is broken down.
You can choose between three modes:

grapheme → splits text into visible characters (user-perceived symbols)
word → splits into words, respecting language-specific rules
sentence → splits into sentences, automatically detecting punctuation and spacing

Each level serves a different purpose:
use graphemes for counting characters, words for tokenization, and sentences for text analysis.

Here’s the beauty: the same phrase can be segmented differently depending on the locale.

Example: One Sentence, Three Languages

Let’s see how Intl.Segmenter handles the same idea across English, French, and Japanese.

const sentences = {
  en: "I love sushi.",
  fr: "J’aime les sushis.",
  ja: "私は寿司が好きです。"
};

for (const [locale, text] of Object.entries(sentences)) {
  const segmenter = new Intl.Segmenter(locale, { granularity: "word" });
  const words = [...segmenter.segment(text)]
    .filter(s => s.isWordLike)
    .map(s => s.segment);

  console.log(locale, words, `(${words.length} words)`);
}

Output:

en [ 'I', 'love', 'sushi' ] (3 words)
fr [ 'J’aime', 'les', 'sushis' ] (3 words)
ja [ '私', 'は', '寿司', 'が', '好き', 'です' ] (6 words)

Same sentence.
Different segmentation — perfectly adapted to each language’s rules.

Example: Word Segmentation (English)

const text = "Pizza, pasta and ice cream!";
const segmenter = new Intl.Segmenter("en", { granularity: "word" });

const words = [...segmenter.segment(text)]
  .filter(s => s.isWordLike)
  .map(s => s.segment);

console.log(words);
// ["Pizza", "pasta", "and", "ice", "cream"]

Each element is not just a string — it’s a full object with metadata:

{
  segment: "Pizza",
  index: 0,
  input: "Pizza, pasta and ice cream!",
  isWordLike: true
}

Example: Grapheme Segmentation

Need to count or slice user-visible characters correctly?

const text = "Café résumé";
const graphemeSegmenter = new Intl.Segmenter("en", { granularity: "grapheme" });

const graphemes = [...graphemeSegmenter.segment(text)].map(s => s.segment);
console.log(graphemes);
// ["C", "a", "f", "é", " ", "r", "é", "s", "u", "m", "é"]

Each accented character counts as one, not two code units.
Perfect for counters, highlighting, or text selection logic.

Example: Sentence Segmentation

const paragraph = "I love pizza. Pasta is great too! Let's eat.";
const sentenceSegmenter = new Intl.Segmenter("en", { granularity: "sentence" });

for (const segment of sentenceSegmenter.segment(paragraph)) {
  console.log(segment.segment);
}

Output:

I love pizza.
Pasta is great too!
Let's eat.

Automatically handles punctuation and spacing.

Example: Real-world Use — Word Counter

You can build a word counter that works in any language:

function countWords(text, locale = "en") {
  const segmenter = new Intl.Segmenter(locale, { granularity: "word" });
  return [...segmenter.segment(text)].filter(s => s.isWordLike).length;
}

console.log(countWords("Pizza, pasta and ice cream!")); // 5
console.log(countWords("J’aime le chocolat et le café.")); // 6
console.log(countWords("私は寿司が好きです。")); // 6

No regex, no guesswork — fully locale-aware.

Conclusion

Splitting text isn’t just a technical task — it’s a linguistic one.
Intl.Segmenter gives JavaScript the power to understand words, sentences, and meaning, not just characters.

No regex. No libraries. No fragile logic.

To explore more, visit the official MDN Web Docs.
And connect on LinkedIn for more updates and insights.

[Boost]

Giuseppe Ciullo — Tue, 30 Sep 2025 09:22:08 +0000

Your .join(", ") Is Lying to You: Meet Intl.ListFormat

Giuseppe Ciullo ・ Sep 29

#javascript #frontend #programming #webdev

Your .join(", ") Is Lying to You: Meet Intl.ListFormat

Giuseppe Ciullo — Mon, 29 Sep 2025 07:15:17 +0000

How many times have you done this as a front-end developer?

["Pizza", "Pasta", "Ice Cream"].join(", ")
// "Pizza, Pasta, Ice Cream"

Looks fine… until you realize something’s wrong: the final “and” is missing.

So you patch it with slice, map, conditionals, maybe even a helper function that grows messier with every project.

But here’s the thing: you shouldn’t be solving this problem at all. There’s already a native API designed for this: Intl.ListFormat.

What Is `Intl.ListFormat`?

Intl.ListFormat is part of the Internationalization API. Its job is simple: turn an array into a human-friendly string that respects language and cultural conventions.

No custom utilities, no edge cases, no spaghetti code.

Styles and Types: Beyond `.join()`

Unlike .join(), Intl.ListFormat gives you control over style, meaning, and locale. Even small differences matter: a comma before “and” (Oxford comma), using “&” instead of “and”, or changing “and” to “or”.

Punctuation Matters: Automatic Commas and Localization

One of the benefits of Intl.ListFormat is automatic punctuation according to the locale. Small details like commas before “and” (the Oxford comma in American English) or the absence of it in British English are not something you have to implement manually anymore.

For example, in en-US, the list "Pizza, Pasta, and Ice Cream" includes the Oxford comma, making it clear and unambiguous. In en-GB, the same list becomes "Pizza, Pasta and Ice Cream", dropping the extra comma as per British conventions.

Even when you use types like unit or disjunction, Intl.ListFormat automatically inserts commas where needed and uses the appropriate conjunction (or none, if the type doesn’t require one). This removes a whole class of small localization bugs that would otherwise require custom logic.

In short, Intl.ListFormat not only formats the words in a list but also ensures your punctuation matches the expectations of your users’ language, making your app feel more polished and professional.

Examples

const foods = ["Pizza", "Pasta", "Ice Cream"];

// Long + conjunction (default, en-US)
new Intl.ListFormat("en-US", { 
  style: "long", 
  type: "conjunction" 
}).format(foods);
// "Pizza, Pasta, and Ice Cream"
// Oxford comma before 'and'

// Long + conjunction (en-GB)
new Intl.ListFormat("en-GB", { 
  style: "long", 
  type: "conjunction" 
}).format(foods);
// "Pizza, Pasta and Ice Cream"
// No Oxford comma in British English

// Short + conjunction
new Intl.ListFormat("en-US", { 
  style: "short", 
  type: "conjunction" 
}).format(foods);
// "Pizza, Pasta, & Ice Cream"
// Compact style, using "&"

// Long + disjunction
new Intl.ListFormat("en-US", { 
  style: "long", 
  type: "disjunction" 
}).format(foods);
// "Pizza, Pasta, or Ice Cream"
// Shows "or" instead of "and"

// Unit style (no conjunction, items treated as a unit)
new Intl.ListFormat("en-US", { 
  type: "unit" 
}).format(foods);
// "Pizza, Pasta, Ice Cream"
// Simple comma-separated listing

Notice how small changes in locale, style, or type completely affect the output. These are the details that make lists readable, natural, and culturally correct.

Real-World Use Cases

E-commerce → “Available in pizza, pasta, & ice cream.”
Social apps → “Liked by Anna, John, & 3 others.”
Dynamic lists → When you don’t know in advance how many items will show up.

In all these cases, .join() falls short. Intl.ListFormat handles these tiny but important differences for you.

Conclusion

Every time you render a list, you’re not just outputting text — you’re communicating.
And communication lives in details: a comma in the right place, the correct “and” or “or”, a style that feels natural to the user’s language.

Those details are what make your app feel professional instead of hacked together.

To dive deeper into Intl.ListFormat and explore additional features, visit the official MDN Web Docs. There, you'll find comprehensive documentation and practical examples to help you master this powerful API.

Connect on LinkedIn for more updates and insights.

Simplify Currency Formatting in React: A Zero-Dependency Solution with Intl API

Giuseppe Ciullo — Tue, 25 Feb 2025 09:56:58 +0000

Currency formatting is a crucial aspect of many web applications, especially in e-commerce or financial dashboards. A clear and intuitive interface helps users quickly understand costs, avoiding ambiguities due to differences in currency or numerical formats. Let's see how to create a React component to display monetary amounts using Intl.NumberFormat, avoiding external dependencies and keeping the code lightweight and performant.

What is `Intl.NumberFormat`?

The Intl.NumberFormat API is the native method for formatting numbers based on user localization. With this API, we can handle currency formatting efficiently without relying on additional libraries. Its advantages include:

Compatibility with modern browsers without the need for external libraries
Support for multiple currencies and formatting styles
Reduced bundle size, improving performance and reducing application load times.

How `Intl.NumberFormat` Works

The Intl.NumberFormat API works by taking a locale and an optional set of formatting options to produce a localized string representation of a number. When instantiated, it creates a formatter that applies the specified rules, such as currency, percentage, or decimal formatting. Under the hood, it leverages the JavaScript Intl (Internationalization) object to ensure proper number formatting based on the selected locale.

For example, different locales format the same number in distinct ways:

const usdFormatter = new Intl.NumberFormat("en-US", {
  style: "currency",
  currency: "USD",
});

const eurFormatter = new Intl.NumberFormat("de-DE", {
  style: "currency",
  currency: "EUR",
});

console.log(usdFormatter.format(1234.56)); // "$1,234.56"
console.log(eurFormatter.format(1234.56)); // "1.234,56 €"

By utilizing this approach, applications can seamlessly adapt to various user preferences and regional conventions without requiring external dependencies.

How to Use `Intl.NumberFormat`

Using Intl.NumberFormat in your application is simple. You initialize a new instance with a locale and a set of options, then call .format(value) to get the formatted output. The API allows for extensive customization, making it versatile for different use cases.

Here’s how to format a number as a currency value in US dollars:

const formatter = new Intl.NumberFormat("en-US", {
  style: "currency",
  currency: "USD",
});

console.log(formatter.format(1234.56)); // "$1,234.56"

Beyond currency formatting, you can adjust properties like minimumFractionDigits and maximumFractionDigits to control decimal precision:

const preciseFormatter = new Intl.NumberFormat("en-US", {
  style: "currency",
  currency: "USD",
  minimumFractionDigits: 3,
  maximumFractionDigits: 3,
});

console.log(preciseFormatter.format(1234.5)); // "$1,234.500"

For more details and advanced usage, refer to the official MDN documentation.

Creating the `CurrencyFormatter` Component

Let’s create a simple React component that leverages Intl.NumberFormat to format monetary values according to the selected currency and locale.

const CurrencyFormatter = ({ value, currency = "USD", locale = "en-US" }) => {
  const formattedValue = new Intl.NumberFormat(locale, {
    style: "currency",
    currency,
  }).format(value);

  return <span>{formattedValue}</span>;
};

export default CurrencyFormatter;

Using the Component

After creating our CurrencyFormatter component, we can easily use it within a React application. This allows us to display monetary amounts clearly and professionally without writing redundant code.

import CurrencyFormatter from "./CurrencyFormatter";

const App = () => (
  <div>
    <strong>Price:</strong>
    <CurrencyFormatter value={1999.99} currency="EUR" locale="it-IT" />
  </div>
);

export default App;

Additional Customizations

If we need more control over the formatting, we can add optional parameters such as the minimum and maximum number of decimal digits. This allows us to adapt the display to different contexts where the component will be used.

With this customization, we ensure that monetary values are displayed with the desired level of precision, enhancing the user experience and usability of the application.

const CurrencyFormatter = ({ value, currency = "USD", locale = "en-US", minimumFractionDigits = 2, maximumFractionDigits = 2 }) => {
  const formattedValue = new Intl.NumberFormat(locale, {
    style: "currency",
    currency,
    minimumFractionDigits,
    maximumFractionDigits,
  }).format(value);

  return <span>{formattedValue}</span>;
};

Conclusion

Using Intl.NumberFormat to format currencies is an efficient, high-performance, and dependency-free solution. This approach allows us to ensure the correct display of currencies based on user localization without adding unnecessary weight to our project.

Crush Date and Time Formatting Natively: Unleash the Hidden Power of Intl.DateTimeFormat

Giuseppe Ciullo — Fri, 10 Jan 2025 10:32:03 +0000

Introduction to Native `Intl` APIs

The Intl APIs in JavaScript are a powerful and native solution for handling localization and formatting of data such as dates and numbers in various languages. Unlike many third-party libraries, these APIs offer:

High performance: Integrated into the JavaScript engine.
Smaller bundle sizes: Eliminates the need for external dependencies.
Global support: Includes localization for a wide range of languages and regions.

Unlike external libraries, native APIs do not require updates or maintenance by the developer. Additionally, they are optimized for the underlying JavaScript engine, providing a lighter and faster approach to localization and formatting.

In this article, we will focus on Intl.DateTimeFormat, an API dedicated to formatting dates and times based on the desired localization. We will see how this API can replace popular libraries such as Moment.js, date-fns, or Day.js for formatting needs, offering a modern and native alternative.

Description of `Intl.DateTimeFormat`

Intl.DateTimeFormat is a class that allows for localized formatting of dates and times. It provides advanced features such as support for different localizations, customizable formats, and handling of alternative calendars and time zones.

Creating a Formatter

A formatter is an instance of Intl.DateTimeFormat that stores a specific configuration for date formatting. By using a formatter, you can repeatedly apply the same format to different dates, making your code more efficient and readable.

To create a formatter, use the Intl.DateTimeFormat constructor with the desired parameters:

const formatter = new Intl.DateTimeFormat(locale, options);

locale: A string defining the localization (e.g., "en-US" for American English, "it-IT" for Italian).
options: An optional object to specify date components (e.g., weekday, month, year, etc.).

While it is common to save the formatter instance in a variable for reuse, this step is not strictly required. The Intl.DateTimeFormat constructor can be invoked directly to format dates inline, as shown below:

console.log(new Intl.DateTimeFormat('en-US', { year: 'numeric', month: 'long', day: 'numeric' }).format(new Date(2024, 11, 19)));
// Output: "December 19, 2024"

However, creating a formatter instance becomes particularly useful when the same format needs to be applied to multiple dates, improving code consistency and avoiding redundancy:

const formatter = new Intl.DateTimeFormat('en-US', {
  year: 'numeric',
  month: 'long',
  day: 'numeric'
});

console.log(formatter.format(new Date(2024, 11, 19))); // Output: "December 19, 2024"
console.log(formatter.format(new Date(2023, 5, 15))); // Output: "June 15, 2023"

Basic Examples: Getting Started with `Intl.DateTimeFormat`

Explore the simplicity and power of Intl.DateTimeFormat with these foundational examples. We'll demonstrate how to create a formatter for default and custom formats that can be reused across your application.

1. Default Formatting

If no options are provided, the formatter uses the default format of the selected locale.

const date = new Date(2024, 11, 19);
const formatter = new Intl.DateTimeFormat('en-US');
console.log(formatter.format(date)); // Output: "12/19/2024"

2. Custom Formatting

Customize the output by specifying the desired options.

const date = new Date(2024, 11, 19);
const formatter = new Intl.DateTimeFormat('en-US', {
  weekday: 'long',
  year: 'numeric',
  month: 'long',
  day: 'numeric'
});
console.log(formatter.format(date)); // Output: "Thursday, December 19, 2024"

Advanced Examples: Unlocking the Full Potential of `Intl.DateTimeFormat`

Take your date and time formatting to the next level with advanced scenarios, such as handling multiple localizations, alternative calendars, and time zones. These examples showcase the versatility and adaptability of Intl.DateTimeFormat in complex applications.

1. Formatting with Alternative Calendars

const islamicFormatter = new Intl.DateTimeFormat('ar-SA-u-ca-islamic');
console.log(islamicFormatter.format(new Date(2024, 11, 19))); // Output: Date in the Islamic calendar

2. Handling Time Zones

const date = new Date(Date.UTC(2024, 11, 19, 15, 30)); // Ensure the date is set in UTC

// Formatter for UTC
const utcFormatter = new Intl.DateTimeFormat('en-US', {
  timeZone: 'UTC',
  year: 'numeric',
  month: 'short',
  day: '2-digit',
  hour: '2-digit',
  minute: '2-digit',
  timeZoneName: 'short',
});
console.log(utcFormatter.format(date)); 
// Output: "Dec 19, 2024, 03:30 PM UTC"

// Formatter for Tokyo time zone
const tokyoFormatter = new Intl.DateTimeFormat('ja-JP', {
  timeZone: 'Asia/Tokyo',
  year: 'numeric',
  month: 'short',
  day: '2-digit',
  hour: '2-digit',
  minute: '2-digit',
  timeZoneName: 'short',
});
console.log(tokyoFormatter.format(date)); 
// Output: "2024/12/20 00:30 JST"

// Formatter for Berlin time zone
const berlinFormatter = new Intl.DateTimeFormat('de-DE', {
  timeZone: 'Europe/Berlin',
  year: 'numeric',
  month: 'short',
  day: '2-digit',
  hour: '2-digit',
  minute: '2-digit',
  timeZoneName: 'short',
});
console.log(berlinFormatter.format(date)); 
// Output: "19. Dez. 2024, 16:30 MEZ"

TypeScript and `Intl.DateTimeFormat`

Using Intl.DateTimeFormat with TypeScript ensures type safety and better development experience. The TypeScript definitions for Intl.DateTimeFormat are built-in, providing autocomplete and documentation for its methods and properties.

Here's an example:

const formatter: Intl.DateTimeFormat = new Intl.DateTimeFormat('en-US', {
  year: 'numeric',
  month: 'long',
  day: 'numeric'
});

const formattedDate: string = formatter.format(new Date(2024, 11, 19));
console.log(formattedDate); // Output: "December 19, 2024"

The strict typing helps avoid runtime errors by catching potential issues at compile time, such as incorrect options or method calls.

Comparison with Popular Libraries

Why Consider `Intl.DateTimeFormat`?

Lightweight: It is native and does not require external libraries, reducing bundle size.
Performance: Often faster than solutions based on libraries.
Built-in Localization: Natively supports various languages and calendars.

Example: Simple Formatting

With Moment.js

const moment = require('moment');
console.log(moment("2024-12-19").format('dddd, MMMM Do YYYY'));

With date-fns

const { format } = require('date-fns');
console.log(format(new Date(2024, 11, 19), 'EEEE, MMMM do yyyy'));

With Day.js

const dayjs = require('dayjs');
console.log(dayjs("2024-12-19").format('dddd, MMMM D, YYYY'));

With Intl.DateTimeFormat

const formatter = new Intl.DateTimeFormat('en-US', {
  weekday: 'long',
  year: 'numeric',
  month: 'long',
  day: 'numeric'
});
console.log(formatter.format(new Date(2024, 11, 19)));

While external libraries might offer syntactic sugar, the native API provides equivalent functionality without sacrificing flexibility or efficiency.The slightly longer syntax of the native API is a small trade-off for its benefits in maintainability, performance, and simplicity.

Conclusion

Intl.DateTimeFormat provides a robust, native solution for date and time formatting, making it an excellent alternative to popular libraries like Moment.js, date-fns, and Day.js. With its high performance, built-in localization, and simplified maintenance, it's a valuable tool for modern JavaScript applications.

To dive deeper into Intl.DateTimeFormat and explore additional features, visit the official MDN Web Docs. There, you'll find comprehensive documentation and practical examples to help you master this powerful API.

Supercharge Your Web Animations: Optimize requestAnimationFrame Like a Pro

Giuseppe Ciullo — Thu, 26 Sep 2024 14:05:10 +0000

Smooth and performant animations are essential in modern web applications. However, managing them improperly can overload the browser’s main thread, causing poor performance and janky animations. requestAnimationFrame (rAF) is a browser API designed to sync animations with the display's refresh rate, ensuring smoother motion compared to alternatives like setTimeout. But using rAF efficiently requires careful planning, especially when handling multiple animations.

In this article, we will explore how to optimize requestAnimationFrame by centralizing animation management, introducing FPS control, and keeping the browser’s main thread responsive.

Understanding FPS and Why It Matters

Frames per second (FPS) is crucial when discussing animation performance. Most screens refresh at 60 FPS, meaning that requestAnimationFrame is called 60 times per second. To maintain smooth animations, the browser must complete its work within about 16.67 milliseconds per frame.

If too many tasks run during a single frame, the browser might miss its target frame time, causing stuttering or dropped frames. Lowering the FPS for certain animations can help reduce the load on the main thread, providing a balance between performance and smoothness.

Centralized Animation Manager with FPS Control for Better Performance

To manage animations more efficiently, we can centralize their handling with a shared loop rather than having multiple requestAnimationFrame calls scattered throughout the code. A centralized approach minimizes redundant calls and makes it easier to add FPS control.

The following AnimationManager class allows us to register and unregister animation tasks while controlling the target FPS. By default, we aim for 60 FPS, but this can be adjusted for performance needs.

class AnimationManager {
  private tasks: Set<FrameRequestCallback> = new Set();
  private fps: number = 60; // Target FPS
  private lastFrameTime: number = performance.now();
  private animationId: number | null = null; // Store the animation frame ID

  private run = (currentTime: number) => {
    const deltaTime = currentTime - this.lastFrameTime;

    // Ensure the tasks only run if enough time has passed to meet the target FPS
    if (deltaTime > 1000 / this.fps) {
      this.tasks.forEach((task) => task(currentTime));
      this.lastFrameTime = currentTime;
    }

    this.animationId = requestAnimationFrame(this.run);
  };

  public registerTask(task: FrameRequestCallback) {
    this.tasks.add(task);
    if (this.tasks.size === 1) {
      this.animationId = requestAnimationFrame(this.run); // Start the loop if this is the first task
    }
  }

  public unregisterTask(task: FrameRequestCallback) {
    this.tasks.delete(task);
    if (this.tasks.size === 0 && this.animationId !== null) {
      cancelAnimationFrame(this.animationId); // Stop the loop if no tasks remain
      this.animationId = null; // Reset the ID
    }
  }
}

export const animationManager = new AnimationManager();

In this setup, we calculate the deltaTime between frames to determine if enough time has passed for the next update based on the target FPS. This allows us to throttle the frequency of updates to ensure the browser’s main thread isn’t overloaded.

Practical Example: Animating Multiple Elements with Different Properties

Let’s create an example where we animate three boxes, each with a different animation: one scales, another changes color, and the third rotates.

Here’s the HTML:

<div id="animate-box-1" class="animated-box"></div>
<div id="animate-box-2" class="animated-box"></div>
<div id="animate-box-3" class="animated-box"></div>

Here’s the CSS:

.animated-box {
  width: 100px;
  height: 100px;
  background-color: #3498db;
  transition: transform 0.1s ease;
}

Now, we’ll add JavaScript to animate each box with a different property. One will scale, another will change its color, and the third will rotate.

Step 1: Adding Linear Interpolation (lerp)

Linear interpolation (lerp) is a common technique used in animations to smoothly transition between two values. It helps create a gradual and smooth progression, making it ideal for scaling, moving, or changing properties over time. The function takes three parameters: a starting value, an ending value, and a normalized time (t), which determines how far along the transition is.

function lerp(start: number, end: number, t: number): number {
  return start + (end - start) * t;
}

Step 2: Scaling Animation

We start by creating a function to animate the scaling of the first box:

function animateScale(
  scaleBox: HTMLDivElement,
  startScale: number,
  endScale: number,
  speed: number
) {
  let scaleT = 0;

  function scale() {
    scaleT += speed;
    if (scaleT > 1) scaleT = 1;

    const currentScale = lerp(startScale, endScale, scaleT);
    scaleBox.style.transform = `scale(${currentScale})`;

    if (scaleT === 1) {
      animationManager.unregisterTask(scale);
    }
  }

  animationManager.registerTask(scale);
}

Step 3: Color Animation

Next, we animate the color change of the second box:

function animateColor(
  colorBox: HTMLDivElement,
  startColor: number,
  endColor: number,
  speed: number
) {
  let colorT = 0;

  function color() {
    colorT += speed;
    if (colorT > 1) colorT = 1;

    const currentColor = Math.floor(lerp(startColor, endColor, colorT));
    colorBox.style.backgroundColor = `rgb(${currentColor}, 100, 100)`;

    if (colorT === 1) {
      animationManager.unregisterTask(color);
    }
  }

  animationManager.registerTask(color);
}

Step 4: Rotation Animation

Finally, we create the function to rotate the third box:

function animateRotation(
  rotateBox: HTMLDivElement,
  startRotation: number,
  endRotation: number,
  speed: number
) {
  let rotationT = 0;

  function rotate() {
    rotationT += speed; // Increment progress
    if (rotationT > 1) rotationT = 1;

    const currentRotation = lerp(startRotation, endRotation, rotationT);
    rotateBox.style.transform = `rotate(${currentRotation}deg)`;

    // Unregister task once the animation completes
    if (rotationT === 1) {
      animationManager.unregisterTask(rotate);
    }
  }

  animationManager.registerTask(rotate);
}

Step 5: Starting the Animations

Finally, we can start the animations for all three boxes:

// Selecting the elements
const scaleBox = document.querySelector("#animate-box-1") as HTMLDivElement;
const colorBox = document.querySelector("#animate-box-2") as HTMLDivElement;
const rotateBox = document.querySelector("#animate-box-3") as HTMLDivElement;

// Starting the animations
animateScale(scaleBox, 1, 1.5, 0.02); // Scaling animation
animateColor(colorBox, 0, 255, 0.01); // Color change animation
animateRotation(rotateBox, 360, 1, 0.005); // Rotation animation

Note on the Main Thread

When using requestAnimationFrame, it’s essential to keep in mind that animations run on the browser’s main thread. Overloading the main thread with too many tasks can cause the browser to miss animation frames, resulting in stuttering. This is why optimizing your animations with tools like a centralized animation manager and FPS control can help maintain smoothness, even with multiple animations.

Conclusion

Managing animations efficiently in JavaScript requires more than just using requestAnimationFrame. By centralizing animations and controlling the FPS, you can ensure smoother, more performant animations while keeping the main thread responsive. In this example, we showed how to handle multiple animations with a single AnimationManager, demonstrating how to optimize for both performance and usability. While we focused on maintaining a consistent FPS for simplicity, this approach can be expanded to handle different FPS values for various animations, though that was beyond the scope of this article.

Github Repo: https://github.com/JBassx/rAF-optimization
StackBlitz: https://www.stackblitz.com/~/github.com/JBassx/rAF-optimization

LinkedIn: https://www.linkedin.com/in/josephciullo/

React Custom Hook Controller Pattern: Creating a Sortable Table

Giuseppe Ciullo — Wed, 15 May 2024 09:21:08 +0000

In React development, custom hooks are a handy tool for sharing logic between components, but they're not limited to just that. They are particularly useful for managing complex state interactions or combining multiple hooks. In this article, we'll explore how custom hooks can be used to create a sortable table in a React app. We'll discuss their benefits and show how to implement them for this specific use case.

The problem

In many situations in React development, when we need to add complex features, we often find it hard to do so in a way that keeps the code clean and easy to manage. If we don't have a clear plan, putting this feature directly into the component can make the code too complicated and hard to work with. In this case, let's consider a very simple example:

Understanding Custom Hook Controllers

React's custom hook controllers serve as central hubs for managing complex state and behavior across components. They enhance the concept of custom hooks by providing a structured approach to encapsulate detailed logic. By consolidating logic within these controllers, developers can streamline their codebases, making them cleaner and more manageable. This organizational approach facilitates code comprehension, debugging, and collaboration. Additionally, the modular nature of custom hook controllers simplifies testing, as logic is encapsulated within reusable functions.

Implementing the pattern

Let's review the previous code and see how we can improve it using custom hook controllers. We'll start by refining the existing code to create a custom hook controller named useSortableTable, which effectively encapsulates the sorting logic:

Now that we have defined the useSortableTable custom hook controller, let's integrate it into our table:

In this updated SortableTable, we import and use the useSortableTable hook controller. It returns the sorted data (sortedData), the current sort key (sortKey), the sort direction (sortDirection), and a function to toggle sorting by key (sortByKey). We utilize these values to render the table headers with appropriate sorting indicators and to display the sorted data in the table body.

Adding new features

One of the advantages of using custom hook controllers is the ease of adding new features to your components. Let's enhance our sortable table component by adding a feature to toggle the selection of table rows.

We can simply add selected property in each TableDataItem, which indicates whether an item is selected or not. To implement the toggle selection feature, we can utilize this property along with the toggleSelect function provided by our useSortableTable hook controller.

Now that we have updated our useSortableTable hook to include the toggleSelect function, let's integrate it into our SortableTable component:

In this updated SortableTable component, we've added a new column for selection in the table. Each row contains a checkbox input that reflects the selected property of the corresponding TableDataItem. We use the toggleSelect function from the useSortableTable hook controller to toggle the selection state when the checkbox is clicked.

This new feature enhances the functionality of our sortable table component, allowing users to select or deselect individual table rows with ease.

Conclusion

React's custom hook controllers provide an effective approach to managing complex state interactions within applications. By encapsulating intricate logic within a centralized custom hook controller, developers can achieve cleaner and more maintainable codebases. This approach not only promotes better code organization but also facilitates testing and enhances reusability.

Furthermore, the flexibility and extensibility of custom hook controllers allow for seamless integration of new features, demonstrating their versatility in handling evolving application requirements. In summary, leveraging custom hook controllers empowers developers to build scalable and maintainable React applications by promoting code separation, facilitating testing, and enhancing reusability. Embracing this approach can lead to more efficient development workflows and robust applications in the long run.

Github repo
LinkedIn

Forem: Giuseppe Ciullo

Orchestrating Scalable Frontends: The Power of the Composition Root

Revisiting the Structure

The Risk of the "Cannibal Feature" (God Feature)

The Illusion of Simplicity

Pages as a Composition Root

The Director and the Actors

Hierarchy of Responsibilities

Substitutability and Maturity

The Core Principle

Next Step: Toward the Page-Level Store

Feature-Driven Architecture: Designing Scalable Applications

Introduction

Scalability is not just performance

What a feature really is

Feature-Driven Architecture: the key principle

Example: the cart feature

Example index.ts:

⚠️ Important rules for exposing feature parts

Combining Atomic Design and Feature-Driven Architecture

Features and reusability: a mindset shift

Scaling the team, not just the code

When it makes sense to adopt this approach

Conclusion

[Boost]

Atomic Design: From UI Composition to Real-World Applications

Giuseppe Ciullo ・ Jan 15

Atomic Design: From UI Composition to Real-World Applications

Atomic Design is a composition pattern, not an architecture

The real-world short circuit

Organisms that turn into mini applications

The false Molecule vs Organism problem

The problem is not Atomic Design

A proposal: separate UI and application architecture

Atomic Design as a UI library (with a key rule)

UI state vs Business state

Dependency Rule (non-negotiable)

Features as the primary architectural unit

Testing strategy: an often underestimated benefit

UI (Atomic Design)

Features (Application Architecture)

Why this approach works

Conclusion

Still splitting text with .split(" ")? Intl.Segmenter is the native way to handle words, sentences, and characters — correctly, across languages. No regex. No hacks. Just smart, locale-aware segmentation.

Stop Splitting Strings the Wrong Way: Discover Intl.Segmenter

Giuseppe Ciullo ・ Nov 11

Stop Splitting Strings the Wrong Way: Discover Intl.Segmenter

What Is Intl.Segmenter?

Understanding Granularity

Example: One Sentence, Three Languages

Example: Word Segmentation (English)

Example: Grapheme Segmentation

Example: Sentence Segmentation

Example: Real-world Use — Word Counter

Conclusion

[Boost]

Your .join(", ") Is Lying to You: Meet Intl.ListFormat

Giuseppe Ciullo ・ Sep 29

Your .join(", ") Is Lying to You: Meet Intl.ListFormat

What Is Intl.ListFormat?

Styles and Types: Beyond .join()

Punctuation Matters: Automatic Commas and Localization

Examples

Real-World Use Cases

Conclusion

Simplify Currency Formatting in React: A Zero-Dependency Solution with Intl API

What is Intl.NumberFormat?

How Intl.NumberFormat Works

How to Use Intl.NumberFormat

Creating the CurrencyFormatter Component

Using the Component

Additional Customizations

Conclusion

Crush Date and Time Formatting Natively: Unleash the Hidden Power of Intl.DateTimeFormat

Introduction to Native Intl APIs

Description of Intl.DateTimeFormat

Creating a Formatter

Basic Examples: Getting Started with Intl.DateTimeFormat

1. Default Formatting

2. Custom Formatting

Example: the `cart` feature

Example `index.ts`:

What Is `Intl.Segmenter`?

What Is `Intl.ListFormat`?

Styles and Types: Beyond `.join()`

What is `Intl.NumberFormat`?

How `Intl.NumberFormat` Works

How to Use `Intl.NumberFormat`

Creating the `CurrencyFormatter` Component

Introduction to Native `Intl` APIs

Description of `Intl.DateTimeFormat`

Basic Examples: Getting Started with `Intl.DateTimeFormat`

Advanced Examples: Unlocking the Full Potential of `Intl.DateTimeFormat`

TypeScript and `Intl.DateTimeFormat`

Why Consider `Intl.DateTimeFormat`?