DEV Community: Angela Pat.

Frontend Code organization, regardless of the stack in times of AI 🤖

Angela Pat. — Tue, 03 Feb 2026 20:28:58 +0000

Let's talk about Frontend architecture. We all know that Frontend has become complex with the days and why is it so?
Front-end is where all user requirements, user enhancements, use of the Business domain, handling of errors, optimizations, and much more all come together. Our frontend architecture is responsible for the cohesion of the new and old codebase.

In the time of AI agents 🤖

Even now, with the rise of AI agent coding tools, clean and well organized code remains critical.
Without clear instructions, AI can easily overcomplicate solutions. AI agents understand domain logic through code structure. The clearer and more consistent patterns you have, the less context the Agent holds, because the agent will follow a predictable organization.

For that reason, my rule of thumb is simple: Follow a feature approach to code organization

What is a feature approach?

Also called a modular approach is the practice of breaking down a solution or user requirements into smaller units, where each unit has a single responsibility.

Following this approach helps maintain a solution over the long term and makes it easier to add new features, whether they are simple or complex.

With so many stacks out there, why not use the basic organization offered by a library or framework?

Of course you can! A framework or library often provides a playground or a basic project structure to get you started. However, as tasks grow bigger and features begin to interact with one another, it becomes our responsibility to break down big user requirements or concepts into self-contained units.

A use case:

Let's say your Admin panel website, needs a new feature an Employees overview page with the following use cases:

Page: Employees Overview***
 - Filter (search, role, age range)
 - List employees
 - Open modal for Editing a new employee 
 - Open a modal for adding a new employee

Now, we can design the architecture by breaking the solution into smaller building blocks.

For example:

With our rough idea in place, we can start organizing our code using a feature approach. We take a big feature and split it into smaller and independent blocks called features or modules.

project 
└─── common/            
│       └─── components/
│               └──── Modal
│       └─── hooks/ 
│               └─── useUserLanguage.ts  
│       └─── models/ 
│               └─── user.ts 
└─── core/
│       └─── authentication/
│       └─── i18n/
│       └─── translations/
│       └─── router/
│       └─── api/
│       └─── store/
└───features/
│   └───employees-overview/
|       │─── EmployeesOverview.tsx (Main component)
│       └─── components/
│             └────── employee-filter/
│             └────── employee-list/
│             └────── employee-add/
│             └────── employee-edit/
│                        └────── hooks/
│                                 └───── useFetchUser.ts
│                                 └───── useUpdateUser.ts
│                        └────── components/
│                        └────── helpers/ 
│                        └────── models/  
│                        └────── EmployeeEdit.tsx
└───lib/
│   └───utils

Let me explain you shortly about some of the important folders and what functionality they cover

common Also called shared: Contains code that can be reused across features. You can organize them by components, hooks, composables, helpers, etc.
- helpers Also called functions: Pure functions that performance specific tasks.
- models: Represent your entities. It's recommended that your entities match the backend for consistency and a single source of truth, with slight differences when needed, for example, dates (the backend uses UTC, while the frontend uses a Date object).
features: Feature-based code aligned with your business goals.
core (optional): Contains the foundational code of your app. This folder is optional because you can either keep these files in a dedicated core folder, making it easy to find anything your app relies on, or place them directly in your main structure.
lib Also called utility functions: Generic technical functions that are not related to domain or business logic and can be used across your code.

Conclusion 💞

Start thinking in terms of features, responsibilities, and blocks and let your team and AI agents maintain the code more easily 💪

Object literals with satisfies operator for UI field mapping

Angela Pat. — Tue, 29 Apr 2025 17:56:11 +0000

Our Frontend is responsible for converting fields into labels that make more sense to users.

So far I have seen the use of Enums to solve that purpose but we can also use Objects literals with satisfies and I believe its more developer friendly, flexible and when compiled, it resembles JS.

Object literals: Meant to be used for key-value pairs.

Object literals with satisfies: Preserves the exact literal types.

A use case:

Let’s say we have an Artist songs page that can be sorted by either title, album name, duration , and # of plays. Our sorting mechanism, in this case a REST API, allows sorting by any of the fields.

First, I would create a declarative sort dropdown component where the keys match the API fields and the values offer user-friendly labels

Solution with Object literal

const artistSongSortOptions = {
  title: 'Title',
  albumName: 'Album name',
  duration: 'Duration',
  numberOfPlays: 'Number of Plays',
} as const satisfies Record<string, string>
// We make object read-only by using as const

// Create type from artistSongSortOptions keys
type ArtistSongSortBy = keyof typeof artistSongSortOptions;

🕵️‍♀️ Hover over that new created type

Nice. Object literals are just brilliant ✨

With this approach you can easily complete the following:

Display a list of available options, coming from Object.keys(artistSongSortOptions)
When an option is selected by the user, you can show the user-friendly text by accessing artistSongSortOptions[selectedOption]
Fetch API with sortBy of a type ArtistSongSortBy

A later use case:

Time passes, and you need to display a new page for multiple artists; an API allows sorting only by one of the valid fields: title, albumName, duration, numberOfPlays, and a new field artistName (it's a list of artists, we would like to sort by artist name as well 😉)

I would simply use again object literals

const multiArtistSongSortOptions = {
  ...artistSongSortOptions,
  artistName: 'Artist name',
} as const satisfies Record<string, string>
// We make object read-only by using as const
// Create type from artistSongSortOptions keys
type MultiArtistSongSortBy = keyof typeof multiArtistSongSortOptions

🕵️‍♀️ Hover over that new created type

Advantages of developing this way

Single source of truth: Automatic type updates
Type safety
Simple HTML generation
Consistency with API

Another way is to use Enums, however I consider the use of object literal more intuitive. If you still prefer Enums and want to use them for field mappings, I would recommend using ESLint, check out this post.

Eslint rules for dealing with Enums peculiarities

Angela Pat. — Tue, 29 Apr 2025 17:53:36 +0000

As of now Enum have their peculiarities in Typescript; they can behave hmm... How should I put it? Inconsistenly. If you still love Enums then, let me suggest some EsLint rules for writing better Enum

Enums peculiarities
Helpful ESLint Rules for Enums!

Prerequisites

EsLint: New to ESLint? It helps you write better JavaScript and TypeScript. https://typescript-eslint.io/

Enums peculiarities

I am going to walk you through a few peculiarities I’ve come across while building components using declarative rendering.

Let me show you with examples

Enums with string or number values

Enums behave different when its created with string values versus numbers.

With string values

 enum TransferStatus {
  Pending = 'pending',
  Completed = 'completed',
  Failed = 'failed',
}

console.log(Object.keys(TransferStatus)) 
// Output : ["Pending", "Completed", "Failed"]

With number values

 enum TransferStatus {
  Pending,
  Completed,
  Failed,
}

console.log(Object.keys(TransferStatus)) 
// Output : ["0", "1", "2", "Pending", "Completed", "Failed"] 
// 🤯 Wow, I got all keys and all values

console.log(Object.values(TransferStatus)) 
// Output: ["Pending", "Completed", "Failed", 0, 1, 2] 
// 🤡 All values and keys

Enums declared explicitly versus implicitly

Enums dont behave the same way when they are declared explicitly versus implicitly. With numbers, values may loose order when refactoring

With explicit values

 enum GameDifficulty {
  Easy = 0,
  Normal = 1,
  Hard = 2,
}
// If ordered alphabetically
 enum GameDifficulty {
  Easy = 0,
  Hard = 2,
  Normal = 1,
}
// All good here with order

With implicit values

enum GameDifficulty {
  Easy,
  Normal,
  Hard,
}

// If ordered alphabetically
 enum GameDifficulty {
  Easy,
  Hard,
  Normal,
}
// value of Hard changed from 2 to 1 
// 🤯 You would have to apply changes everywhere in your code

Helpful ESLint Rules for Enums!

If you still love Enums, then I'd suggest using some EsLint rules to enforce consistency and make code more predictable for you and your team members

Initialize Enum values explicitly for clarity and consistency

'@typescript-eslint/prefer-enum-initializers': 'error'

Ensure all enum values are unique.

'@typescript-eslint/no-duplicate-enum-values': 'error'

Use enums with string values only This is the one I like. Consitency all the way! 💞

@typescript-eslint/no-magic-numbers': [
      'error',
      {
        'ignoreEnums': false
      }
    ]

Summary

In this post, I address common inconcistencies with Enum when building dynamic declarative components. I also show with some examples that you met when building components dinamycally.
It also shares some EsLint rules to safeguard you against the peculiarities of Enum.

DEV Community: Angela Pat.

Frontend Code organization, regardless of the stack in times of AI 🤖

In the time of AI agents 🤖

What is a feature approach?

With so many stacks out there, why not use the basic organization offered by a library or framework?

A use case:

Conclusion 💞

Object literals with satisfies operator for UI field mapping

A use case:

Solution with Object literal

A later use case:

Advantages of developing this way

Eslint rules for dealing with Enums peculiarities

Table of Contents

Prerequisites

Enums peculiarities

Enums with string or number values

With string values

With number values

Enums declared explicitly versus implicitly

With explicit values

With implicit values

Helpful ESLint Rules for Enums!

Summary