Forem: Dan Bui

Lexical scope in JavaScript

Dan Bui — Sun, 09 Nov 2025 13:53:31 +0000

Recently, a friend asked me, “What is lexical scope? Is it a type of Scope?”:). Great question!. Scope in JS often causes confusion. In this post, let’s discover Scope, Lexical scope in JavaScript

Scope

Let’s start with scope. Scope determines the accessibility of variables. There are 3 types of scope:

Global
Function
Block

Global Scope

Variables are declared outside any function or block
Can be accessed everywhere in the code

Function Scope

Variables are declared inside a function
Can be accessed only in a function, nested function, and can not be accessed outside of this function

Block Scope

Variables are declared inside a block (for, if..) (let, const)
Can be accessed only in a block scope, can not be accessed outside of this block
var doesn’t have block scope (because of hoisting, it will be moved on top of their scope, outside of block scope)

The question: “Is lexical scope the 4th scope in the above list?”

Lexical scope
Pay your attention to example below:

var babyName = 'globalBaby';

function foo(){
    console.log('babyName', babyName);
}

function bar(){
    var babyName = 'Doraemon';
    foo();
}

bar();

/// What will be logged?

Define global babyName
Define foo function, try log babyName
Define bar function , declare babyName inside this function (function scope)
Call bar function

So far, we know about function scope. As the definition, inside bar function the babyName can be accessed by foo function . Let’s check the result of above example

var babyName = 'globalBaby';

function foo(){
    console.log('babyName', babyName);
}

function bar(){
    var babyName = 'Doraemon';
    foo();
}

bar();
/// What will be logged?
/// Actual logging: babyName globalBaby

The value of babyName is ‘globalBaby’, not Doraemon, as we expected? But why? That is the mechanism of scope known as Lexical scope or Static Scope. Lexical scope is a fundamental principle; it determines the accessibility of a variable based on where the code is defined rather than when the code is run. We can think, the lexical scope is similar to the scope’s property.

The value of babyName is ‘globalBaby’ because:

Foo function “remember" babyName = ‘globalBaby’ at the define time
At the run time, inside bar function Foo function can not access babyName which is defined inside this function

Conclusion

Scope is a crucial fundamental, but developers often miss it. I am one of them 😃 . A solid understanding of scoping helps us code and debug better! If you have any comments or adjustments, feel free to drop a comment

Standalone component in Angular

Dan Bui — Wed, 29 Oct 2025 07:17:46 +0000

Standalone components were officially released with Angular 15. After one year of using it, converting to standalone components, in this post, I will share my experiences of using it

SCAM

Before touching the standalone component, let’s start with SCAM. What is SCAM?
SCAM stands for Single Component As Module. It is the golden rule for creating a shared component ui, looks like this:

shared-button-ui/
├── shared-button-ui.component.ts
├── shared-button-ui.component.html
├── shared-button-ui.component.scss
└── shared-button-ui.module.ts

Inside shared-button-ui.module.ts

@NgModule({
  imports: [
    CommonModule,
  ],
  declarations: [SharedUiButtonComponent],
  exports: [SharedUiButtonComponent],
})
export class SharedUiButtonModule {}

Declare SharedUiButtonComponent inside the declarations array
Then re-export them by defining inside the exports array
Anywhere that intends to use SharedUiButtonComponent, must import SharedUiButtonModule

Standalone Component

Since version 14, Angular has introduced standalone components, pipes, and directives. It looks like this:

@Component({
  selector: 'app-button-ui',
  imports: [
    MatProgressSpinner,
    OtherNgModules
  ],
  templateUrl: './shared-button-ui.component.html',
  standalone: true,
  styleUrl: './shared-button-ui.component.scss'
})
export class ShareButtonUiComponent {}

Pay your attention to the Components’ metadata; there are two new properties:

imports
standalone

Compared to before, it is similar to mixing @NgModule with @Component together. Is it right? The answer is right!
With the “alone” style, now a component, pipe, or directive is an @NgModule itself. It means:

Standalone don’t rely on ngModule anymore
Standalone can import their dependencies
Standalone can be imported by other components or modules directly

So far, we mentioned SCAM best way for creating a shared component. And now, Standalone is a perfect replacement. Compare to SCAM:

Reduce boilerplate code, without creating ngModule
Avoid redundant imports, such as putting inside the SharedModule together

Conclusion

In the recent update from Angular’s team, they focus on streamlining DX as well as the Development process, a standalone component is one of them! It is a great time to convert our regular components into standalone components. We must not convert all at once; we can adopt incrementally

Structure Angular app with Nx workspace

Dan Bui — Thu, 23 Oct 2025 04:15:09 +0000

Building a robust, maintainable, and scalable front-end application isn’t easy; many things have to be done. Well structure is one of the most important parts. In this post, I will share my preferred Angular structure with the Nx workspace

Prerequisite

Angular 17
Nx workspace

What is Nx?

In recent years, Nx workspace has become the most popular tool for building and managing applications. Nx is an open-source, technology-agnostic build platform designed to efficiently manage codebase of any scale. Nx understands our project relationship and dependencies, executes tasks smarter and faster!

Group

First of all, I separate the app into three main groups:

Core - singleton services or other parts that should import only once when the application is instantiated
Shared - Components or other parts that are shared entire our application
Feature - Smart components that map one-to-one with our business

Each part of the group has a prefix that corresponds to the group’s name. For instance, core-service, shared-button-ui, feature-product-list. As my style, I like a flat folder over a nested folder 🙂.( nested folder style we structure like this: core/services shared/button-ui )

App Structure

After grouping, we have the structure below:

├── apps
│   └── my-app
└── libs
    ├── core-api
    ├── core-guard
    ├── core-interceptor
    ├── core-layout
    ├── core-service
    ├── customer
    │   ├── feature-detail
    │   └── feature-list
    ├── shared-button-ui
    ├── shared-hover-directive
    ├── shared-percent-pipe
    └── shared-upper-case-pipe

Let's explain from top to bottom

Core-service

Type: lib (folder)

Tag: type: core

Services which we intend to keep as a singleton, such as user-service,theme-service, often @injectable({provideIn:’root’})

Tip

Prevent CoreModule from being imported twice:

import { NgModule, Optional, SkipSelf } from '@angular/core';

@NgModule({
  // declarations, imports, exports, etc.
})
export class CoreModule {
  // This is the constructor guard
  constructor(@Optional() @SkipSelf() parentModule?: CoreModule) {
    if (parentModule) {
      throw new Error(
        'CoreModule has already been loaded. Import it only in the AppModule.'
      );
    }
  }
}

Core-guard

Type: lib (folder)

Tag: type: core

Guards we apply across our application, such as role-guard, auth-guard

Core-interceptor

Type: lib (folder)

Tag: type: core

Interceptors we apply in our application, such as response-interceptor, error-interceptor

Core-api

Tag: type: core

Type: lib (folder)

Api service which interacts with our back-end system, such as product-api,order-api, often @injectable({provideIn:’root’})

Core-layout

Tag: type: core

Type: lib (folder)

Including all layouts which is loaded at the initial page load and loading only one, such as app-header, app-layout, app-footer

Shared-ui-[componet-name]

Tag: type: ui

Type: lib (folder)

Components that we intend to share across our application. Keep it dump as much as possible, such as shared-ui-button, shared-ui-dropdown.

Shared-directive-[directive-name]

Tag: type: directive

Type: lib (folder)

Directives which we intend to share across our application, such as shared-directive-hover, shared-directive-double-click, keep it separate, avoid putting it together

Shared-pipe-[pipe-name]

Tag: type: pipe

Type: lib (folder)

Pipes which we intend to share across our application, such as shared-pipe-percent, shared-pipe-upper-case, keep it separate, avoid putting it together

Feature-[feature-name]

Tag: type: feature

Type: lib (folder)

I strictly follow the DDD (Domain Driven Development) approach. There are 2 dimensions:

Horizontal: Each domain business has sub-domains/features. For instance, a customer domain has sub-domains/features: customer-profile, customer-list, customer-order. We have the structure below:
```
├── apps
│   └── my-app
└── libs
    ├── customer
    │   ├── feature-detail
    │   └── feature-list
```

Vertical: Inside each domain/sub-domains involves these parts:

pipe
directive
service
component
constant
helper

feature-name/
├── constant/        // For feature-specific constants or enums
├── directive/
├── helper/          // For utility classes or pure functions
├── pipe/
├── service/
└── feature-name.component.ts  // The main component

These ones are used internally or shared with sub-domains

Conclusion

Above, I shared my preferred Angular structure with Nx. Well-structured code is the “key” for building maintainable, scalable applications. In the next post, I will share my boundaries setup (Nx workspace). If you have another viewpoint or adjustment, feel free to drop a comment.

Transition from Angular to Flutter

Dan Bui — Mon, 20 Oct 2025 03:10:07 +0000

The Frontend ecosystem is growing rapidly nowadays. As a frontend developer, the ability to switch between frameworks is essential. In this post, I will share my experiences when I transitioned from Angular to Flutter

Recently, I have contributed to a Flutter project. Unfortunately, I have never worked with Flutter; my expertise is Angular and web development. After one year of discovering Flutter and delivering some successful features, I realize it doesn’t matter which framework you are using; fundamentals and mindset are the most important.

Comparison

Both belong to the frontend land, powered and maintained by Google. Below, we list out some differences:

Angular
- Language base: Typescript
- Platform: Web (Browsers)
- UI Rendering: Html, Css, and the Browser’s DOM
Flutter
- Language base: Dart
- Platform: Cross-platform (Android/Ios/Desktop/Web)
- UI Rendering: Renders its own widgets using the Skia Graphics Engine,

Technique

Below, we list out the primary technique we have used for each one

Angular
- State management: Ngrx
- UI library: Angular Material
Flutter
- State management: Getx
- Ui library: Material

Transition mindset (Angular → Flutter)

Although they run on different platforms, they are the same ideal. When the user takes action, we update our ui to reflect the user’s action. Each one provides its own way to handle it. Let's go through side by side

Component - Widget

Component in Angular

Widget in Flutter

We have a comparison table below:

Part	Angular	Flutter
controller	feature.component.ts	feature_controller.dart
view	feature.component.css	feature_page.dart
module	feature.module.ts	feature_bindings.dart

Dependency injection

Angular	Flutter
Built in dependency system	GetX provide solution

Routing

Angular	Flutter
Built in Route management	GetX provide solution

Reactive programming

Angular	Flutter
RxJs	RxDart

Above, we compare some main key differences. Technically, each one uses its own technique, but the ideal is the same. Solid fundamentals help us move and adapt faster!

Conclusion

Above, I share my experiences in transiting from Angular to Flutter. To build a robust mobile app as well as a web application, many things have to be done. Technique can be changed, but our mindset remains the same; core fundamentals are “key” to help us transition faster!