File descriptor giải thích vì sao file, TCP connection, Unix socket, pipe và nhiều cơ chế event của Linux có thể được xử lý theo một mô hình thống nhất. Unix Domain Socket, hay UDS, là một ứng dụng trực tiếp của mô hình đó: thay vì để các service cùng máy giao tiếp qua TCP port, chúng có thể giao tiếp qua một socket path trong filesystem.

Đây là một pattern đặc biệt hữu ích khi triển khai Nginx ở public edge, còn Node.js hoặc Go chạy như các backend service nội bộ.

File descriptor là gì?

File descriptor, thường gọi tắt là FD, là một số nguyên mà kernel cấp cho process để đại diện cho một tài nguyên I/O đang mở.

Ví dụ, một process web service có thể giữ các FD như sau:

0  -> stdin
1  -> stdout
2  -> stderr
3  -> access log
4  -> TCP listener :443
5  -> client connection
6  -> upstream connection
7  -> Unix socket listener

Điểm quan trọng là FD không chỉ đại diện cho file trên disk. Trong Linux, FD có thể đại diện cho:

• Regular file
• TCP hoặc UDP socket
• Unix Domain Socket
• Pipe giữa các process
• Log file và temporary file
• Event mechanism như epoll, eventfd hoặc timerfd

Vì vậy, câu “everything is a file” nên được hiểu theo nghĩa thực dụng hơn:

Linux có một mô hình I/O thống nhất, trong đó nhiều loại tài nguyên được process thao tác thông qua file descriptor.

Một process có thể đọc, ghi, đóng hoặc chờ sự kiện trên nhiều loại tài nguyên bằng các primitive tương tự như read, write, close, poll và epoll.

Socket là một loại FD

Khi application mở một socket, kernel trả về một FD. Application dùng FD đó để gửi và nhận dữ liệu.

Với TCP hoặc Unix stream socket, socket là một luồng byte hai chiều. Nó không tự biết đâu là ranh giới của request, JSON object hay business message.

Ví dụ, application gửi hai phần dữ liệu:

hello
world

Bên nhận có thể nhận chúng thành một block helloworld, hoặc thành nhiều phần nhỏ hơn. Đây là lý do HTTP, gRPC và các protocol custom phải có cơ chế framing.

Điều này dẫn đến một nguyên tắc quan trọng:

Socket vận chuyển bytes; protocol định nghĩa message.

HTTP nói cho hai bên biết request bắt đầu và kết thúc ở đâu. WebSocket định nghĩa frame. Một protocol tự thiết kế phải tự quyết định message length, delimiter hoặc format frame.

Unix Domain Socket là gì?

Unix Domain Socket là socket để các process giao tiếp với nhau trên cùng một host.

Thay vì service listen trên TCP port:

127.0.0.1:8080

service có thể listen trên một socket path:

/run/my-api/api.sock

Luồng giao tiếp sẽ như sau:

Nginx -> /run/my-api/api.sock -> application

Socket path đó xuất hiện trong filesystem, nhưng không phải file chứa request hay response. Nó là tên của một socket endpoint do kernel quản lý.

UDS phù hợp khi:

• Hai process chạy cùng host.
• Backend không cần được truy cập trực tiếp từ mạng.
• Có một trust boundary local rõ ràng.
• Muốn dùng Unix user, group và file permissions để kiểm soát quyền kết nối.

Vì sao UDS phù hợp cho local web service?

Với một backend chỉ phục vụ sau Nginx, mở TCP listener ra 0.0.0.0:3000 thường không cần thiết. Kể cả 127.0.0.1:3000 vẫn là một TCP endpoint, trong khi UDS mô tả rõ hơn rằng service này chỉ dành cho local IPC.

Một kiến trúc rõ ràng hơn là:

Internet
   |
HTTPS :443
   |
Nginx
   |
Unix Domain Socket
   |
Node.js hoặc Go service

Lợi ích chính của UDS không chỉ là hiệu năng. Giá trị lớn hơn nằm ở thiết kế và vận hành:

• Backend không phải mở port network riêng.
• Permission của filesystem trở thành một lớp access control.
• Topology thể hiện rõ public ingress và internal IPC.
• Không cần quản lý port allocation cho local-only service.
• Giảm nguy cơ expose nhầm backend qua firewall hoặc network configuration.

UDS không thay thế TCP khi service chạy khác host, khác VM, khác node Kubernetes hoặc cần service discovery. Trong các trường hợp đó, TCP, QUIC hoặc một transport network-native vẫn là lựa chọn phù hợp hơn.

Nginx và file descriptor

Nginx là một reverse proxy event-driven, xử lý số lượng lớn connection bằng cách theo dõi readiness của nhiều FD.

Khi proxy một request, Nginx thường làm việc với ít nhất hai socket FD:

Client connection <-> Nginx <-> Upstream connection

Nếu backend chạy local qua UDS:

Browser
   |
TCP/TLS
   |
Nginx
   |
Unix socket
   |
Go API hoặc Node.js service

Nginx đọc request từ client socket, áp dụng TLS termination, routing, rate limit và buffering, sau đó chuyển request đến upstream socket. Response đi ngược lại.

Bên cạnh socket FD, Nginx còn quản lý FD cho static files, access log, error log, cache file và proxy temporary file. Vì vậy, giới hạn FD là một capacity concern thực sự, đặc biệt với API có nhiều keep-alive connection hoặc WebSocket connection dài hạn.

Nginx proxy tới Unix socket

Ví dụ cấu hình tối giản:

upstream api {
    server unix:/run/my-api/api.sock;
}

server {
    listen 443 ssl;
    server_name api.example.com;

    location / {
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_pass http://api;
    }
}

Từ góc nhìn application, backend vẫn phục vụ HTTP như bình thường. Khác biệt chỉ là transport giữa Nginx và service:

Nginx -> TCP localhost -> backend

được thay bằng:

Nginx -> UDS -> backend

Đây là một thay đổi hạ tầng, không phải thay đổi business protocol.

Node.js: stream abstraction trên socket

Node.js có mô hình event-driven và stream-oriented rất phù hợp với socket I/O. HTTP server trong Node.js có thể listen trực tiếp trên một Unix socket path.

import http from 'node:http';

const socketPath = '/run/my-api/api.sock';

const server = http.createServer((req, res) => {
  res.setHeader('content-type', 'application/json');
  res.end(JSON.stringify({ ok: true }));
});

server.listen(socketPath);

Trong production, service cần xử lý lifecycle của socket path: bảo đảm directory tồn tại, dọn stale socket an toàn khi khởi động, đặt permission phù hợp, và graceful shutdown khi nhận SIGTERM.

Điểm quan trọng nhất ở Node.js là backpressure. Socket có buffer hữu hạn; nếu client đọc chậm, application không thể tiếp tục ghi vô hạn mà không tăng memory usage.

Với Node streams, nếu write() trả về false, service nên đợi sự kiện drain trước khi tiếp tục ghi. Điều này quan trọng nhất với streaming response, WebSocket fan-out, media relay hoặc proxy tự viết.

Go: transport độc lập với HTTP server

Go tách application protocol khỏi transport khá tự nhiên. http.Server nhận một net.Listener, còn listener đó có thể là TCP hoặc Unix socket.

listener, err := net.Listen("unix", "/run/my-api/api.sock")
if err != nil {
    log.Fatal(err)
}

server := &http.Server{
    Handler: handler,
}

log.Fatal(server.Serve(listener))

Điểm hay của mô hình này là HTTP handler không cần biết request đến qua TCP hay UDS. Service có thể chuyển transport mà không phải thay đổi business logic.

Go runtime quản lý network polling và cho phép goroutine block ở API level mà vẫn scale tốt với nhiều connection. Tuy nhiên, application vẫn phải đặt timeout, deadline, connection limit và giới hạn body size. Goroutine không loại bỏ giới hạn FD, memory hay kernel socket buffer.

FD là một đơn vị capacity

Trong hệ thống connection-heavy, chỉ nhìn CPU và RAM là chưa đủ. FD cũng là tài nguyên cần theo dõi.

Một reverse proxy request đang hoạt động có thể dùng:

1 FD cho client connection
1 FD cho upstream connection

WebSocket hoặc SSE còn giữ các FD đó lâu hơn request HTTP thông thường.

Ngoài connection, các resource như database pool, Redis client, log file, static file và temporary file đều có thể tiêu FD. Khi cạn FD, service thường xuất hiện lỗi như:

too many open files
EMFILE
accept() failed

Vì vậy, cần cấu hình đồng bộ:

systemd LimitNOFILE
        |
Nginx worker FD limit
        |
Nginx worker_connections
        |
Node.js / Go service limit
        |
database và outbound connection pools

Tăng LimitNOFILE không phải là giải pháp duy nhất. Nó cần đi cùng timeout, rate limit, max connections, backpressure và observability.

Buffering, timeout và slow client

Nginx có thể buffer response từ backend trước khi gửi cho client. Điều này giúp backend trả dữ liệu nhanh và không bị giữ connection quá lâu bởi một Internet client đọc chậm.

Với API response thông thường, Nginx buffering thường nên được giữ bật. Chỉ nên tắt nó cho các luồng cần streaming end-to-end như SSE hoặc một số token-streaming endpoint.

Ở cả Nginx, Node.js và Go, timeout nên được đặt theo từng pha:

• Thời gian kết nối upstream.
• Thời gian đọc request header/body.
• Thời gian chờ upstream response.
• Idle timeout cho keep-alive hoặc long-lived connection.
• Graceful shutdown deadline.

Một hệ thống tốt không chỉ phục vụ được client nhanh; nó còn phải tự bảo vệ trước client chậm, upstream treo và traffic đột biến.

Vận hành UDS an toàn

Socket runtime nên nằm dưới /run, ví dụ:

/run/my-api/api.sock

Không nên đặt socket ở /tmp dùng chung hoặc trong source directory.

Một pattern tốt là để systemd tạo runtime directory:

[Service]
User=my-api
Group=my-api
SupplementaryGroups=nginx

RuntimeDirectory=my-api
RuntimeDirectoryMode=0750
UMask=0007

LimitNOFILE=65536

Mục tiêu permission là:

/run/my-api/          my-api:my-api  0750
/run/my-api/api.sock  my-api:nginx   0660

Application có quyền tạo socket; Nginx có quyền connect; process không liên quan không có quyền truy cập.

Kết luận

File descriptor là nền tảng I/O chung của Unix/Linux. File, socket, pipe và event mechanism có thể được process quản lý qua FD, dù semantics của chúng khác nhau.

Unix Domain Socket là cách tự nhiên để kết nối các service trên cùng host. Trong một web stack phổ biến, Nginx nhận public traffic qua TCP/TLS, còn Node.js và Go backend nhận local traffic qua UDS.

Nguyên tắc thực dụng là:

Dùng Nginx và TCP/TLS cho public edge; dùng UDS cho local IPC trong cùng host và trust boundary; dùng TCP, QUIC hoặc transport network-native khi đi qua VM, container namespace, node hoặc mạng thực sự.

Memory leaks có thể được định nghĩa là một bộ nhớ (memory) không được sử dụng trong ứng dụng nữa nhưng vì một lý do nào đó mà nó chưa được giải phóng và trả về hệ điều hành hoặc một cái pool chứa các bộ nhớ (memory) chưa sử dụng. Các ngôn ngữ lập trình khác nhau sẽ có các cách khác nhau để quản lý bộ nhớ. Những cách quản lý bộ nhớ này sẽ giúp giảm thiểu khả năng bị memory leaks của chương trình. Tuy nhiên, việc xác định một vùng bộ nhớ có còn được sử dụng hay không lại là một vấn đề khó có thể xác định. Chỉ có developer mới có khả năng quyết định xem là vùng nhớ này nên được giải phóng hay không. Một số ngôn ngữ (như javascript) cung cấp tính năng tự động giải phóng bộ nhớ cho developer, một số khác thì developer cần phải tự mình giải phóng bộ nhớ khi không sử dụng đến nó nữa.

Quản lý bộ nhớ trong JS

Javascript là một trong những ngôn ngữ có garbage collection. Những ngôn ngữ lập trình như Javascript thế này sẽ thay developer quản lý bộ nhớ bằng cách kiểm tra định kỳ các vùng nhớ được cấp phát trước đó có có thể được “với tới” bởi các phần khác trong ứng dụng. Có thể nói cách khác là những ngôn ngữ như Javascript sẽ giúp biến vấn đề từ “những vùng nhớ nào vẫn còn cần trong ứng dụng” thành “những vùng nhớ nào có thể được ứng dụng access đến”. Sự khác biệt của 2 vấn đề là không nhiều nhưng lại rất quan trọng: chỉ developer mới có thể biết được là vùng nhớ nào còn cần để chạy tuy nhiên, việc xác định xem một vùng nhớ có thể vươn tới không trong ứng dụng thì có thể làm tự động bởi thuật toán.

Memory leaks trong JS

Lý do chính của memory leaks trong các ngôn ngữ có garbage collection là các reference không mong muốn vào bộ nhớ (unwanted references), tức là một vùng nhớ được trỏ đến mà lại không được sử dụng trong ứng dụng. Để có thể hiểu rõ hơn về nó, trước hết ta cần tìm hiểu các hoạt động của garbage collector, cách nó xác định một vùng nhớ có thể được “với tới” (reach) bởi ứng dụng.

Mark and sweep

Hầu hết các garbage collector đều sử dụng thuật toán mark-and-sweep để thực hiện việc giải phóng bộ nhớ. Thuật toán này bao gồm các bước sau:

1. Đầu tiên, garbage collector sẽ xây dựng một danh sách các roots. Roots thực chất là các biến toàn cục mà có reference được lưu trong code. Trong Javascript, window chính là một biến toàn cục như vậy. Window sẽ luôn hiện hữu trong chương trình nên garbage collector có thể coi nó và tất cả các con của nó luôn hiện hữu.
2. Tất cả roots và con của chúng sẽ được đánh dẫu là đang hoạt động. Tất cả những vùng nhớ mà có thể được vươn tới từ roots thì đều được coi là đang hoạt động và không đánh dấu là rác (garbage).
3. Tất cả các vùng nhớ mà không được đánh dấu là rác (garbage) thì bây giờ đều sẽ được coi là rác. Bây giờ thì các collector có thể giải phóng các vùng nhớ này.

Mặc dù thuật toán này được tối ưu bởi các GC (garbage collector) hiện đại tuy nhiên cơ chế của nó vẫn không đổi: những vùng nhớ vươn tói được thì được coi là đang hoạt động, những vùng nhớ khác sẽ được coi là rác.

Những tham chiếu không mong muốn (Unwanted references) là những tham chiếu đến các vùng bộ nhớ mà developer biết là nó không được cần đến nữa nhưng vì lý do nào đó mà nó vẫn được giữ lại trong hệ thống. Trong JS, những tham chiếu không mong muốn này là các biến (variables) được giữ đâu đó trong code mà nó sẽ không được sử dụng đến nữa nhưng lại trỏ đến một vùng nhớ mà cần được giải phóng.

Để hiểu được memory leaks trong JS, ta cần biết được là khi nào thì một tham chiếu bị lãng quên.

4 loại memory leaks trong JS

1: Biến toàn cục

Javascript có một cơ chế là đặt biến mà không cần khai báo. Ví dụ:

a = 'value';
console.log(a); //"a"

Khi một biến được khai báo như trên thì JS sẽ tự động gán nó vào global object (window trên browser). Nếu như biến này chỉ hoạt động trên phạm vi toàn cục (global scope) thì cũng không có sự khác biệt cho lắm. Tuy nhiên, nếu nó được định nghĩa trong một hàm thì đó lại là chuyện khác. Ví dụ:

function foo() {
  bar = 'đây là biến toàn cục ẩn';
}

Đoạn code trên sẽ tương đương với đoạn code sau trên browser:

function foo() {
  window.bar = 'đây là biến toàn cục';
}

Nếu khai báo bar trong phạm vi của hàm foo mà lại không sử dụng var để khai báo thì biến bar sẽ được tạo với phạm vi toàn cục, và đây là một ví dụ điển hình về memory leaks.

Một cách khác mà có thể vô tình tạo ra biến toàn cục đó là thông qua this:

function foo() {
  this.variable = 'có thể là biến toàn cục';
}

foo();

Vì this trong hàm sẽ trỏ đến biến root toàn cục (window) nếu hàm đó được gọi trực tiếp không thông qua object nào khác nên ở ví dụ trên, biến variable sẽ được gắn vào phạm vi toàn cục.

Một cách để giảm thiểu những lỗi trên đó là thêm "use strict;" vào dòng đầu tiên của file JS. Nó sẽ giúp ngăn chặn việc khai báo biến toàn cục như trên.

Chú ý khi làm việc với biến toàn cục

Biến toàn cục không bao giờ được giải phóng bộ nhớ tự động theo thuật toán mark-and-sweep ở trên. Vì thế, biến toàn cục chỉ nên được sử dụng để lưu tạm dữ liệu để xử lý. Nếu cần lưu một lượng lớn dữ liệu vào biến toàn cục thì cần đảm bạo là nó sẽ bị gán về null hoặc gán lại dữ liệu khi mà bạn đã sử dụng xong nó.

2: Callback và timer bị lãng quên

Sau đây là một ví dụ dẫn đến memory leak khi sử dụng setInterval:

var data = getData();
setInterval(function(){
  var node = document.getElementById("Node");
  if(node){
	node.innerHTML = JSON.stringify(someResource));
  }
}, 1000);

Đây là một ví dụ về một timer bị treo. Timer bị treo tức là khi timer tham chiếu đến các node hoặc dữ liệu mà không còn được sử dụng nữa. Ở ví dụ trên, nếu như node bị xóa ở một lúc nào đấy thì toàn bộ đoạn code xử lý trong hàm callback của interval sẽ không cần đến nữa. Tuy nhiên, vì interval vẫn còn hoạt động nên các vùng nhớ được sử dụng trong hàm callback của interval cũng không được giải phóng (muốn giải phóng cần dừng interval lại). Tiếp đó, các object từ bên ngoài mà được hàm callback của interval tham chiếu đến cũng không thể được giải phóng vì vẫn có thể vươn tới được thông qua hàm callback kia. Theo ví dụ trên thì đó là data.

Một trường hợp có thể dẫn đến leaks đó là do các observers object (DOM và event listener của chúng). Điều này chỉ ảnh hưởng đến các trình duyệt cũ (vd: IE6) vì các trình duyệt mới sẽ tự động làm điều này cho chúng ta. Đây là một bug của GC của IE6 và dẫn đến việc tham chiếu quay vòng.

3: Tham chiếu tới các DOM đã bị xóa

Có những lúc bạn muốn lưu các DOM vào một số cấu trúc dữ liệu như mảng hoặc object trong JS code để làm một loạt các tác vụ nào đấy. Ví dụ bạn muốn update dữ liệu của một vài element nào đấy thì việc lưu các element này vào một mảng là hoàn toàn hợp lý. Khi điều này xảy ra thì sẽ có 2 tham chiếu đên DOM element này: một là từ DOM tree, hai là từ đối tượng mảng của JS. Nếu bạn muốn xóa các element này thì bạn cần phải xóa toàn bộ các tham chiếu tới chúng để có thể giải phóng bộ nhớ.

Ví dụ:

var elements = {
  button: document.getElementById('button'),
  image: document.getElementById('image'),
  text: document.getElementById('text'),
};

function doStuff() {
  image.src = 'http://some.url/image';
  button.click();
  console.log(text.innerHTML);
}

function removeButton() {
  // button là con của body.
  document.body.removeChild(document.getElementById('button'));

  // Ở đây thì button vẫn được tham chiểu đến bởi elements. Nói cách khác là
  // nó vẫn nằm trong bộ nhớ và không thể được giải phóng.
}

Còn một vấn đề quan trọng nữa là khi tham chiếu đến một node lá hoặc một inner node của DOM tree, ví dụ như một ô trong bảng (<td> của <table>). Nếu bạn tham chiếu đến <td> này trong JS code thì khi bạn xóa <table> chứa node này thì GC sẽ không giải phóng được cả table chứ không phải là chỉ mỗi <td> node không được giải phóng. Vì node con còn tham chiếu đến node cha nên nó sẽ được GC coi là vẫn được tham chiếu và bỏ qua nó. Vì thế nên cẩn thận khi tham chiếu đến các DOM.

4: Closures

Closures có nghĩa đơn giản là hàm nằm trong phạm vi của một hàm khác có thể tham chiếu tới các biến của hàm bao nó. Vì sao Closures có thể gây ra leak, hãy xem ví dụ sau:

var theThing = null;
var replaceThing = function () {
  var originalThing = theThing;
  var unused = function () {
    if (originalThing) console.log('hi');
  };
  theThing = {
    longStr: new Array(1000000).join('*'),
    someMethod: function () {
      console.log(someMessage);
    },
  };
};
setInterval(replaceThing, 1000);

Ví dụ này cho ta thấy mỗi khi replaceThing được gọi, theThing sẽ tạo ra một object mới chứa một mảng và một closures (someMethod). Cùng lúc đó, biến unused cũng lưu một closures tham chiếu đên originalThing (là object theThing được tạo ra từ việc gọi replaceThing ở bước trước đó). Một điều quan trọng nữa là khi một scope được tạo ra cho các closures mà có cùng scope cha, chúng sẽ cùng chia sẻ scope đó. Trong ví dụ này thì someMethod và unused đều chia sẻ cùng một scope. Mặc dù unused không được gọi đến nhưng vì nó có tham chiếu đến originalThing nên nó sẽ được GC coi là vẫn đang hoạt động. Khi đoạn code này chạy thì bộ nhớ của chương trình sẽ tăng đều đặn và có thể nhìn thấy ngay được. Về bản chất, một linked-list của closures được tạo (với root là theThing) khi đoạn code trên được chạy và đó là lý do bộ nhớ bị tăng dần theo thời gian.

Garbage Collectors (bộ dọn rác)

Mặc dù GCs giúp chúng ta không phải quản lý bộ nhớ bằng tay nữa, tuy nhiên ta cũng sẽ phải đánh đổi lại một vài thứ. Một trong số đó là việc các GCs hoạt động theo một cách khó đoán biết. Thông thường rất khó có thể chắc chắn rằng một hoạt động thu thập các vùng nhớ không được sử dụng được thực thi hay không. Điều này cũng có nghĩa là trong một số trường hợp, số lượng vùng nhớ của một chương trình nhiều hơn số bộ nhớ mà chương trình đó cần. Trong một số trường hợp khác, ứng dụng sẽ bị ảnh hưởng bởi một khoảng thời gian nhỏ chương trình bị delay để thực hiện công việc thu thập bộ nhớ. Hiện nay, hầu hết GC đều hoạt động theo cách là chỉ thực hiện việc thu thập bộ nhớ khi cấp phát bộ nhớ cho chương trình. Nếu không cần cấp phát bộ nhớ, GCs sẽ không hoạt động. Chúng ta sẽ xem xét các tình huống sau:

1. Chương trình đã cấp phát một số lượng nhỏ bộ nhớ.
2. Sau đó, hầu hết (hoặc toàn bộ) các phần tử được đánh dấu là không thể vươn tới nữa.
3. Chương trình không thực hiện việc cấp phát bộ nhớ nữa.

Trong tình huống này, hầu như tất cả các GC sẽ không thực hiện việc thu thập bộ nhớ nữa. Nói cách khác, mặc dù có những phần tử không thể vươn tới được nữa trong chương trình, chúng sẽ không được thu hồi lại bộ nhớ. Đây không hẳn là leaks, tuy nhiên nó vẫn dẫn đến việc chương trình ngốn bộ nhớ.

Chrome Memory Profiling Tools

Chrome cung cấp một tập các công cụ để kiểm tra tình trạng sử dụng bộ nhớ của code JS. Có 2 view quan trọng liên quan đến bộ nhớ đó là: timeline và profiles.

Timeline View

Timeline View có thể giúp ta biết được mô hình sử dụng bộ nhớ của chương trình. Từ đây ta có thể nhìn được việc rò rỉ bộ nhớ, việc bộ nhớ sử dụng tăng liên tục theo thời gian mà không giảm xuống sau mỗi lần GC được chạy. Ví dụ:

Ta có thể thấy được việc bộ nhớ rò rỉ được thể hiện thông qua việc JS heap tăng dần theo thời gian. Mặc dù sau khi được thu thập với một số lượng lớn tại đoạn cuối thì chương trình vẫn sử dụng số lượng bộ nhớ nhiều hơn so với lúc bắt đầu. Số lượng Node cũng cao hơn. Đây là dấu hiệu của việc các node DOM bị rò rỉ đâu đó trong code.o

Profiles view

Đây là công cụ sẽ luôn gắn bó với bạn khi phải điều tra về rò rỉ bộ nhớ. Profiles view cho phép bạn lấy ảnh chụp (snapshot) về việc sử dụng bộ nhớ của một chương trình Javascript. Nó cũng cho phép bạn ghi lại những lần cấp phát bộ nhớ theo thời gian. Mỗi một loại kết quả sẽ có các danh sách liệt kê khác nhau được đưa ra, tuy nhiên những thứ mà bạn cần quan tâm đó là danh sách tổng hợp (summary list) và danh sách so sánh (comparision list).

Summary View sẽ cho ta thấy được tổng quan về các loại objects được khởi tạo và cấp phát cùng với các kích thước tổng hợp (aggregated size): kich thước nông (Shallow size) là tổng kích thước của tất cả các object của một loại cụ thể nào đó và kích thước giữ lại (retained size) bao gồm shallow size và kích thước của các object được lưu lại bởi object này. Nó cũng cho ta một thông tin về khoảng cách giữa một object với root.

Comparision View cũng cung cấp cùng một thông tin như summary view nhưng nó cho phép ta so sánh giữa các snapshot khác nhau.

Ví dụ: Tìm kiếm rò rỉ dữ liệu trong Chrome

Có 2 kiểu rò rỉ dữ liệu chủ yếu là: rỏ rỉ dẫn đến việc bộ nhớ bị tăng một cách đều đặn theo thời gian và rò rỉ chỉ xảy ra một lần duy nhất và không gây ra việc bộ nhớ bị tăng trong tương lai nữa. Việc tìm rò rỉ dữ liệu mà bộ nhớ bị tăng dần theo thời gian khá là đơn giản và rõ ràng (sử dụng timeline view). Tuy nhiên thì đây lại là rò rỉ gây ra nhiều rắc rối nhất: nếu bộ nhớ cứ tăng dần theo thời gian, nó sẽ khiến trình duyệt chạy chậm dận và cuối cùng sẽ dẫn đến việc script bị ngừng chạy. Rò rỉ mà không dẫn đến việc bộ nhớ bị tăng theo thời gian có thể dễ dàng được tìm ra khi bộ nhớ lớn đến một mức độ nào đó. Thông thường những rò rỉ kiểu này không được chú ý quả nhiều. Nói theo một cách khác, những rò rỉ nhỏ mà chỉ xảy ra một lần thường được coi là một vấn đề để tối ưu code. Tuy nhiên, những rò rỉ mà làm bộ nhớ tăng dần theo thời gian thì được coi là bug và nó cần được fix.

Ở đây ta sẽ sử dụng một ví dụ từ Chrome. Toàn bộ đoạn code như sau:

var x = [];

function createSomeNodes() {
  var div,
    i = 100,
    frag = document.createDocumentFragment();
  for (; i > 0; i--) {
    div = document.createElement('div');
    div.appendChild(
      document.createTextNode(i + ' - ' + new Date().toTimeString())
    );
    frag.appendChild(div);
  }
  document.getElementById('nodes').appendChild(frag);
}
function grow() {
  x.push(new Array(1000000).join('x'));
  createSomeNodes();
  setTimeout(grow, 1000);
}

Khi grow được gọi, nó sẽ bắt đầu tạo một div và gán nó vào DOM. Nó cũng sẽ khởi tạo một mảng lớn (1 triệu phần tử) và gán nó vào một mảng được tham chiếu bỏi một biến toàn cục (x). Việc này sẽ dẫn đến việc bộ nhớ bị tăng đều đặn và có thể nhận biết được với Timeline view.

Phát hiện việc bộ nhớ bị tăng đều đặn trong Chrome

Ta sẽ bắt đầu với ví dụ sau của chrome. Sau khi click vào ví dụ của Chrome, mở Dev Tools, click vào tab timeline, tích chọn memory và click vào nút record. Tiếp đó quay lại trang ví dụ và click vào The Button để bắt đầu việc rò rỉ bộ nhớ. Sau một khoảng thời gian thì dừng lại việc record và xem kết quả:

Note: Ví dụ này sẽ khiến bộ nhớ bị tăng mỗi giây. Sau khi dừng việc record thì các bạn có thể đặt breakpoint vào grow để dừng việc thực thi script.

Có 2 dấu hiệu lớn trong bức ảnh trên cho thấy việc rò rỉ bộ nhớ: biểu đồ cho nodes (đường kẻ màu xanh lá) và biểu đồ cho JS heap (đường kẻ màu xanh đậm). Số lượng node luôn luôn tăng và không bao giờ giảm. Đây là dấu hiệu cảnh báo lớn.

JS heap cũng tăng dần theo thời gian tuy nhiên điều này khó nhìn ra hơn do hiệu ứng từ GC. Các bạn có thể thấy là bộ nhớ tăng sau lại giảm một cách liên tục. Điểm quan trọng cần chú ý ỏ đây là sau mỗi lần bộ nhớ được giảm thì kích thước của JS heap vẫn lớn hơn so với lần giảm trước đấy. Nói cách khác, mặc dù GC đã thành công thu thập được rất nhiều bộ nhớ, một vài trong số đó bị rò rỉ.

Bây giờ ta đã chắc chắn chương trình của mình bị rò rỉ bộ nhớ, ta cần phải tìm ra nguyên nhân của nó.

Tạo 2 snapshot

Để tìm ra nguyên nhân rò rỉ, ta sẽ sử dụng đến công cụ profiles của Chrome. Cụ thể hơn, ta sẽ sử dụng tính năng Take Heap Snapshot.

Đầu tiên, reload lại trang và tạo một snapshot ngay sau khi load xong trang. Ta sẽ sử dụng snapshot này làm cơ sở. Sau đó, click vào The Button một lần nũa, chờ khoảng một vài giây, tạo một snapshot khác. Sau đó tạo breakpoint để dừng việc rò rỉ bộ nhớ lại.

Có 2 cách mà ta có thể sử dụng để kiểm tra sự khác nhau giữa 2 snapshot. Thứ nhất là sử dụng chức năng Summary rồi bắt đầu từ phía bên phải chọn Objects allocated between Snapshot 1 and Snapshot 2. Hoặc chọn Comparision thay cho Summary. Trong cả 2 trường hợp, ta sẽ thấy một danh sách các object được khởi tạo giữa 2 snapshot.

Trong trường hợp này thì việc tìm ra leaks rất đơn giản. Hãy xem Size Delta của (string). 8MB với 58 object mới. Điều này rất đáng nghi ngờ: object mới được tạo nhưng không được giải phóng và 8MB bị chiếm mất.

Nếu ta mở danh sách khởi tạo của (string) ta sẽ thấy có một vài object lớn được khởi tạo bên cạnh các object nhỏ. Nếu ta chọn một trong số các object lớn này thì ta sẽ thấy một vài điểm thú vị trong mục retainers:

Ta thấy rằng object được chọn là một phần tử của mảng. Tiếp đó ta biết được mảng này được tham chiếu bởi biến x nằm ở trong window. Điều này cho ta thấy được toàn bộ con đường từ object lớn của chúng ta liên kết thế nào với root (window). Ta đã tìm được một nguyên nhân dẫn đến rò rỉ và nơi nó được tham chiếu.

Ví dụ này khá đơn giản: object lớn được khởi tạo thế này không thường xuyên xuất hiện trong chương trình. Tuy nhiên trong chương trình này cũng có xuất hiện việc rò rỉ DOM có kích cỡ nhỏ hơn. Những node này có thể tìm thấy được thông qua snapshot tuy nhiên đối với những site lớn, mọi chuyện sẽ trở nên rắc rối hơn nhiều. Các phiên bản Chrome hiện tại có cung cấp một tính năng đó là: Record Heap Allocations

Record Heap Allocations

Ta se bắt đầu với viêc để cho đoạn script tiếp tục được chạy và quay lại tab Profiles của Chrome Dev Tools. Ấn nút Record Heap Allocations. Khi mà tool đang chạy, các bạn sẽ thấy một vài vạch xanh trên biểu đồ ở phía trên đầu. Nó thể hiện việc khởi tạo object khi chạy chương trình.

Ta có thể thấy được tính năng của công cụ này: chọn một khoảng thời gian để xem object nào được khởi tạo trong khoảng thời gian này. Ta đặt khoảng thời gian này gần các vạch xanh đậm nhất có thể. Chỉ có 3 hàm khởi tạo được show trong danh sách: một trong số đó liên quan đến rò rỉ do (string) ở phía trên, tiếp theo là liên quan đến việc khởi tạo DOM và cái cuối cùng là khởi tạo Text.

Chon một trong những hàm khởi tạo của HTMLDivElement trong danh sách và chọn Allocation stack.

Từ ảnh trên ta thấy được là phần tử được khởi tạo bởi grow -> createSomeNodes. Nếu ta để ý kỹ mỗi vạch trên biểu đồ, ta sẽ thấy là hàm khởi tạo HTMLDivElement được gọi nhiều lần. Nếu ta quay trở lại với snapshot comparision view, ta sẽ thấy là nó chỉ khởi tạo object mà không xóa chúng đi. Nói cách khác là nó luôn khởi tạo object mà không cho phép GC thu thập một vài trong số chúng. Giờ khi ta đã biết objects bị rò rỉ ở đâu (createSomeNodes), ta có thể quay trở lại code để sửa lại nó.

Các tính năng hữu ích khác

Thay vì sử dụng Summary view, ta có thể sử dụng Allocation view:

Giao diện này cho ta thấy một danh sách các hàm và bộ nhớ khởi tạo liên quan đến chúng. Ta có thể thấy ngay là grow và createSomeNodes là nổi bật hơn cả. Khi chọn grow ta sẽ thấy đối tượng khởi tạo liên quan được gọi đến. Ta có thể để ý thấy (string) HTMLDivElement và Text là những hàm khởi tạo của các đối tượng bị rò rỉ.

Note: để sử dụng được tính năng này, vào Dev Tools -> Settings và enable record heap allocation stack traces trước khi record.

Node.js is a JavaScript runtime built on Chrome’s V8 JavaScript Engine.

JavaScript thì dễ hiểu rồi (Thật ra Chrome cũng dễ hiểu), nhưng còn Runtime với Engine là gì? Mối quan hệ giữa chúng như thế nào?

JavaScript Engine có thể được định nghĩa một cách đơn giản như sau: Một chương trình hoặc thư viện thực thi mã JavaScript, cung cấp các cơ chế khởi tạo object, gọi function,… Có thể đơn giản là một interpreter hoặc một JIT compiler to bytecode.

Tất nhiên, vì cả bài viết này chỉ nhằm nhiệm vụ trả lời Nodejs là gì, mà biết được JavaScript Engine là gì tức là đã xong 50% vấn đề, nên ta sẽ giải thích lại, một cách phức tạp và dài dòng hơn, bắt đầu từ những khái niệm cơ bản hơn như Interpreter và Compiler.

Interpreter và Compiler

• Interpreter (của ngôn ngữ A): Một thành phần có chức năng trực tiếp thực thi một đoạn code (được viết bằng ngôn ngữ A). Có thể coi CPU như một interpreter của tập chỉ lệnh tương ứng. Ngày nay, interpreter thường hiểu theo ý nghĩa trực tiếp một chương trình từ source code mà không qua chuyển đổi thành machine code.
• Compiler: Dịch từ ngôn ngữ A sang ngôn ngữ B sao cho khi thực thi thu được kết quả tương đương. Thường được sử dụng để dịch source code từ ngôn ngữ bậc cao A sang ngôn ngữ B có bậc thấp hơn dễ dàng interprete hơn, và tất nhiên ngôn ngữ dễ interprete nhất là machine code.

Thời gian cần để compile thường không phải là nhỏ, nhất là khi cần tối ưu hoá kết quả. Để giảm thiểu thời gian compile, có một cách (đánh đổi bởi tốc độ thực thi sau khi compile) là không dịch trực tiếp source code ra machine code mà dịch sang một ngôn ngữ trung gian và sử dụng interpreter cho ngôn ngữ trung gian này, thường gọi là bytecode, với đặc điểm là thời gian compile từ ngôn ngữ nguồn sang bytecode nhanh hơn sang machine code, tốc độ thực thi nhanh hơn việc trực tiếp interprete source code, mặc dù chậm hơn machine code.

Từ interpreter và bytecode trong định nghĩa về JavaScript Engine đã rõ ràng, vậy còn JIT compiler?

Để có một cái nhìn về JIT compiler, chúng ta cần xem xét nó trong một mối quan hệ biện chứng giữa nó và một khái niệm khác: AOT compiler.

Ahead-of-Time (AOT) và Just-in-Time (JIT) compilation: Từ time được nhắc đến ở đây là runtime. AOT dịch toàn bộ source code trước khi bắt đầu chạy chương trình, JIT thì trái lại compile source code trong thời gian chạy. Triết lý của JIT compilation là thay vì phải chờ compiler dịch toàn bộ source, việc có thể mất nhiều thời gian, ta dịch từng phần mà ta cần dùng trước rồi bắt đầu chạy với chúng ngay lập tức.

Interpreter và compiler có thể kết hợp trở thành engine của một ngôn ngữ theo 1 trong 2 cách:

• AOT kết hợp interpreter: Source code được compile toàn bộ thành machine code hoặc bytecode trước khi khởi chạy chương trình, sau đó sử dụng một interpreter để thực thi. Ví dụ Python được AOT compiler dịch thành cpython bytecode trong chớp nhoáng và cpython được chạy trên interpreter.
• JIT kết hợp interpreter: Thực tế là full compiled code chạy nhanh hơn nhưng tốn nhiều thời gian trước khi bắt đầu chạy, trực tiếp interprete source code thì có thể bắt đầu chạy ngay nhưng tốc độ thực thi chậm. Giải pháp trung hoà là sử dụng interpreter để khởi chạy nhanh chóng source code, rồi dùng JIT compiler để dịch và thay thế source code bằng compiled code sau khi đã dịch xong.

V8 Engine

V8 là một open source JavaScript engine viết bằng C++, phát triển bởi Google như là một phần trong dự án Chromium, phát hành lần đầu cùng với phiên bản đầu tiên của trình duyêt Chrome. V8 compile trực tiếp JavaScript thành native machine code thay vì sử dụng interpreting bytecode theo cách truyền thống.

Nodejs được xây dựng lần đầu trên V8 do tốc độ thực thi đáng kinh ngạc so với các JavaScript Engine trước đó, đủ sức đảm đương một hệ thống yêu cầu hiệu năng cao trên server-side. Ngày nay thì các Engine của các hãng khác cũng đã bắt kịp V8 rồi, vừa rồi Nodejs cũng đã phát hành một phiên bản sử dụng Chakra Engine của Microsoft tại https://github.com/nodejs/node-chakracore, nhưng có lẽ khi nhắc đến Nodejs thì ta chỉ cần giới thiệu về V8 là đủ.

V8 Engine được Google lựa chọn quả thật là một cái tên mang nhiều cảm xúc, gợi lên hình ảnh về những động cơ ô tô mạnh mẽ, sản sinh công suất lớn từ thiết kế 8 xy-lanh sắp xếp hình chữ V mà hiếm khi nào có tổng dung tích dưới 3.0 L, thậm chí lên đến hơn 8.0 L, ví như động cơ của chiếc Audi R8.

Khá chắc là các kỹ sư của Google cũng rất mê xe, bởi họ tiếp tục đặt tên cho các thành phần trong động cơ V8 của mình là Crankshaft, TuborFan và Ignition, các thành phần kỹ thuật của động cơ đốt trong hiện đại mà chúng ta sẽ bắt gặp trong phần sau của bài viết.

Lan man vậy thôi, bây giờ, ba yếu tố then chốt tạo nên hiệu năng cao của V8 là:

• Fast Property Access
• Dynamic Machine Code Generation
• Efficient Garbage Collection

Fast Property Access

JavaScript là một dynamic programming language, có nghĩa, các property có thể được thêm, bớt, thay đổi trong thời gian chạy. Hầu hết các JavaScript Engine sử dụng một cấu trúc dữ liệu dạng dictionary để lưu giữ các property trong object, mỗi truy cập đến property yêu cầu một dictionary dynamic lookup để tìm ra vị trí của property trong memory, chậm hơn cách truy cập trực tiếp đến property trong các class-based language truyền thống.

Để tránh dynamic lookup, V8 tự động ngầm tạo một hidden class cho mỗi object, biến object trong JavaScript thành class-based. Mỗi khi object được thêm property, V8 tạo mới một hidden class và object chuyển hidden class của nó sang class mới này.

Kể từ khi object trong JavaScript trở thành class-based, một kỹ thuật compiler optimization kinh điển trở nên khả thi và được đưa vào V8, Inline Caching, giúp tăng lực cho JavaScript lên thậm chí vài chục lần với long runtime.

Dynamic Machine Code Generation

V8 dịch trực tiếp JavaScript source code sang native machine code, cho tốc độ interprete cao, đồng thời có khả năng linh động tối ưu hoá (và tái tối ưu) compiled code trong thời gian chạy dựa trên các dữ liệu thu thập được từ profiler.

V8 có 2 compiler, ban đầu, tất cả source code của bạn sẽ được phân tích cú pháp, chuyển thành AST rồi đẩy vào Full-Codegen Compiler, nơi sẽ cho ra phiên bản machine code đầu tiên của chương trình.

Full-Codegen Compiler: Nhiệm vụ là chuyển source code của bạn thành machine code nhanh nhất có thể, khỏi optimize gì luôn. Nó cũng thêm vào một ít type-feedback code thu thập thông tin để phục vụ công việc optimize code sau này. Compiler không tiến hành bất cứ phân tích và không biết gì về kiểu dữ liệu trong source code tại thời điểm này.

Để gia tăng hiệu năng, V8 tiếp tục theo dõi chương trình trong runtime bằng một profiler, một thành phần trong kiến trúc của V8, sẽ thu thập thông tin và tìm xem function nào là hot function, tức được dùng đi dùng lại rất nhiều lần, đó là thời điểm cần tiến hành optimize cho một compiled code tốt hơn. Và đó là thời điểm Crankshaft vào cuộc.

Optimizing compiler: Crankshaft (và mới đây là TuborFan được thêm vào) đưa ra những dự đoán về function dựa vào những thông tin thu được từ profiler, re-compile và thay thế phần code chưa được optimize bằng cách sử dụng on-stack replacement (OSR).

Nếu những giả định là sai lầm, ví dụ nó cho rằng a, b sẽ luôn là number trong phép tính a + b ở đâu đó, và sử dụng thẳng phép cộng 2 số ở đây thay vì lần nào cũng phải kiểm tra kiểu và sử dụng + operator thích hợp, mà bất chợt b lại nhận kiểu là string, thì nó chỉ đơn giản là de-optimizing và tái sử dụng phần code chưa optimize.

Đây là cách V8 đối xử với source code của chúng ta:

Nguồn ảnh: v8project.blogspot.com

Trong năm 2016, một interpreter mang tên Ingition được thêm vào V8 với mục đích giảm thiểu chiếm dụng bộ nhớ trên những hệ thống có memory nhỏ như Android.

Efficient Garbage Collection

Garbage collector của V8, được quảng cáo là một stop-the-world, generational, accurate, garbage collector làm nhiệm vụ thu hồi memory đối với những object không còn được process sử dụng một cách rất hiệu quả. Còn nó hiệu quả như thế nào, tại sao hay thậm chí nó có thật sự hiệu quả hơn các engine khác hay không thì mình cũng không rõ.

Ban đầu, JavaScript được thiết kế để thực hiện một số nhiệm vụ nhỏ nhoi và ngắn ngủi, ví dụ như đặt một event listener cho một element trên browser, engine lúc ấy chỉ đơn giản là một interpreter đọc và thực thi JavaScript source code. Dần dần, theo thời gian, chúng ta yêu cầu nhiều hơn từ nó.

Ứng dụng đầu tiên giao phó những nhiệm vụ nặng nề cho JavaScript là Google Map. Từ đây người ta nhận ra sự cần thiết của một JavaScript nhanh hơn, trong một runtime dài hơi hơn.

JIT compilation cần nhiều thời gian để khởi tạo hơn interpretation, nhưng nhanh hơn rất nhiều trong runtime dài. Với những web application dùng nhiều JavaScript của mình, Google đã dành nhiều công sức để thúc đẩy các trình duyệt cải thiện hiệu suất của JavaScript, và V8 ra đời như một kết quả.

Giờ đây, một process JavaScript chạy càng lâu, càng được optimize và càng sở hữu hiệu năng cao hơn, mọi người cảm thấy nó đã khả thi để xuất hiện trong một môi trường khắc nghiệt hơn là trên web browser, server-side.

JavaScript Runtime

Được giới thiệu là một JavaScript Runtime, Nodejs có gì khác biệt với một JavaScript Engine? Lấy cảm hứng từ một câu trả lời trên Stackoverflow, chúng ta có thể tạm hiểu như sau:

JavaScript chạy trên một container – một chương trình sẽ nhận source code của bạn và thực thi nó. Chương trình này làm hai điều:

• Phân thích source code và thực thi từng đơn vị có thể.
• Cung cấp một vài object để JavaScript có thể tương tác với thế giới bên ngoài.

Phần đầu, gọi là Engine. Phần còn lại, gọi là Runtime.

Trên thực tế, V8 implement một ECMAScript theo đúng chuẩn, tức là những gì ngoài chuẩn thì không có mặt trong V8.

Để tương tác với môi trường, V8 cung cấp các lớp template bọc ngoài các object và function viết bởi C++. Các C++ function này có thể làm nhiệm vụ đọc/ghi file system, thao tác networking hoặc giao tiếp với các process khác trong hệ thống. Bằng cách thiết lập một JavaScript context với global scope chứa các JavaScript instance tạo ra từ các template và chạy source code của chúng ta trong context này, mã của chúng ta đã sẵn sàng để giao tiếp với thế giới.

Và đó là nhiệm vụ của một Runtime Library: Tạo ra một runtime environment cung cấp các thư viện built-in dưới dạng các biến global để mã của bạn có thể sử dụng trong thời gian chạy, đón nhận source code như là một argument và thực thi nó trong context đã tạo.

Với browser runtime environment như Chrome, context mà Chrome cung cấp cho V8 bao gồm các biến global như window, console, DOM object, XMLHttpRequest và timer setTimeout().

Tất cả những thứ ấy đến từ Chrome, không phải từ bản thân V8. Thay vào đó, V8 cung cấp các built-in object chuẩn, có mặt trong mọi environment của JavaScript, được miêu tả trong ECMAScript Standard, bao gồm các kiểu dữ liệu, operator, một số object và function đặc biệt như các value property (Infinity, NaN, null, undefined), Object, Function, Boolean, String, Number, Map, Set, Array, parseInt(), eval(),…

Rời xa thế giới browser, rời xa DOM, Nodejs mang đến cho chúng ta nhiều built-in library hơn như fs để giao tiếp với file system, http và https cho networking, tls, tty, cluster, os,… Vấn đề là không phải lúc nào ta cũng cần tất cả những thứ này, việc tạo một context mang quá nhiều global variable không cần thiết như vậy rõ ràng không phải là một cách làm hay.

Nodejs bởi vậy nhóm nhiều chức năng vào các module khác nhau và thực hiện một cơ chế module loading thông qua từ khoá require và exports, cho phép tạo ra những context linh động hơn. Tất nhiên, cơ chế này được implement bằng C/C++.

Đó là diễn giải đằng sau lời giới thiệu runtime built on Chrome’s V8 JavaScript Engine của Nodejs, và đó là cách mã JavaScript của bạn thao tác với các low-level API, theo một cách đồng bộ (synchronous). V8 chạy mã của bạn trong một single thread, tuần tự từng lệnh một, sử dụng một cấu trúc để quản lý các active subroutine gọi là call stack.

Call Stack và Event Loop

Call stack không phải là một điều gì đó mới mẻ, thực tế chúng ta luôn luôn phải sử dụng nó để đảm bảm chương trình thực thi một cách đúng đắn, chẳng qua trong các ngôn ngữ bậc cao, việc cung cấp một call stack được ẩn đi và tự động hoá. Nếu push quá nhiều stack frame vào và tiêu tốn hết không gian được cấp cho call stack, chúng ta sẽ đối diện với Stackoverflow huyền thoại.

Câu chuyện về call stack của JavaScript có lẽ chúng ta đều đã được nghe kể rất nhiều lần. Ta đều biết rằng stack frame được push mỗi khi một hàm được gọi, và được pop với lệnh return. Sau khi lần lượt xử lý hết các lệnh trong chương trình, call stack trở nên rỗng ruột, một phép màu mang tên event loop sẽ nhặt các hàm callback trong một tạo vật gọi là event queue (hay task queue), đẩy vào trong call stack, và V8 engine tiếp tục thực thi hàm đang nằm trong call stack này.

Đây là cách JavaScript thực hiện asynchronous call. Đây cũng là lý do tại sao gọi timer setTimeout() với đối số là 0, hàm callback của chúng ta vẫn phải chờ cho đến khi tất cả code trong chương trình thực thi xong (call stack trở thành empty) thì mới được invoke.

Nguồn ảnh: geeksforgeeks.org

V8 nhận event loop như là một đối số đầu vào khi khởi tạo environment, các môi trường khác nhau sẽ có event loop và API để tạo asynchronous request, thứ mà sẽ đẩy callback function của ta vào trong event queue rồi vật vờ ngồi đợi, của riêng mình.

Với Nodejs, event loop implementation của nó là libuv. Thiếu đi libuv, bức tranh về một Nodejs event-driven asynchronous non-blocking I/O sẽ không thể hoàn thiện. V8 thì thậm chí còn chẳng biết I/O là cái gì chứ đừng nói đến blocking hay không blocking.

// app.js
// câu hỏi vui: Đoán kết quả lệnh (1) và lệnh (2) :cười:
var obj = {
    mMethod: function() {
        console.log(this)
    }
}

obj.mMethod(); // (1)

var _mMethod = obj.mMethod;
_mMethod();  // (2)

Đọc tới đây chắc một số bạn biết về this rồi sẽ bật cười là sao lại viết là biến this. Nếu bạn nghĩ tới mức đó thì xin chúc mừng bạn, bạn đã đúng. this trong JS là một từ khoá chứ không phải là một biến nào cả. Bạn không thể gắn giá trị trực tiếp cho this được cũng như chẳng thể nào delete nó đi. Vậy từ khoá này có gì lại rắc rối vậy?

Bản chất của từ khoá this

Các đoạn mã của JavaScript được thực thi trong một ngữ cảnh nhất định (Execution Context). Các ngữ cảnh này lại được sắp xếp để thực hiện chương trình một cách tuần tự. Bạn có thể tưởng tượng thế này, mỗi ngữ cảnh chứa một số đoạn mã nhất định, và toàn chương trình của ta sắp xếp các ngữ cảnh này vào một ngăn xếp (stack). Sau đó các ngữ cảnh sẽ được gọi ra thực thi dần cho tới hết, tức là ngữ cảnh trên đỉnh của ngăn xếp sẽ chứa các đoạn mã sẵn sàng chạy.

Mỗi ngữ cảnh thực thi này có tương ứng một ThisBinding có giá trị không đổi đại diện cho ngữ cảnh thực thi đó. Và từ khoá this sẽ bằng giá trị ThisBinding trong ngữ cảnh đang thực thi hiện thời. Như vậy this sẽ đại diện cho ngữ cảnh đang thực thi và nó cần được đánh giá lại tham chiếu khi ngữ cảnh thực thi thay đổi.

Có 3 kiểu ngữ cảnh thực thi là toàn cục (global), eval và hàm (function). Global là ngữ cảnh ở mức trên cùng của toàn bộ chương trình, tức là nó chứa các đoạn mã không nằm trong function hay được gọi bởi eval và global sẽ là ngữ cảnh thực thi chương trình mặc định. Eval là ngữ cảnh chứa các mã được gọi bởi hàm eval. Còn function là các đoạn mã nằm trong một function nào đó. Ta sẽ xem chi tiết từng ngữ cảnh thực thi qua phần dưới đây.

Các ngữ cảnh thực thi

Toàn cục - Global

Là ngữ cảnh thực thi nằm ở trên cùng của ngăn xếp ngữ cảnh, tức là ngữ cảnh đầu tiên thực thi chương trình. Ví dụ trong các mã thực thi phía máy khách trong trang web thì ngữ cảnh toàn cục này nằm ngay sau thẻ . Trong ngữ cảnh toàn cục này thì ThisBinding sẽ được thiết lập giá trị là đối tượng toàn cục (Global Object). Trong Nodejs thì đối tượng toàn cục là đối tượng toàn cục của Nodejs - khởi đầu là một đối tượng trống, trong trình duyệt thì nó là đối tượng window, nhưng cần chú ý là nếu ở trong chế độ strict mode thì đối tượng toàn cục là undefined. Ta có thể cùng nhau xem xét ví dụ dưới đây.

console.log(this); // đối tượng toàn cục trong ngữ cảnh toàn cục

this.mX = 'I love JavaScript'; // sử dụng đối tượng toàn cục

console.log(this.mX); // in ra giá trị của thuộc tính mX

var obj = {
  mMethod: function () {
    console.log(this); // in ra giá trị this hiện thời
  },
};

obj.mMethod(); // không còn là đối tượng toàn cục nữa

Gọi mã - Eval

Với trường hợp sử dụng hàm eval ta phân làm 2 trường hợp.

Gọi eval trực tiếp

Gọi eval trực tiếp là ta gọi trực tiếp hàm eval như ví dụ bên dưới. Với trường hợp này thì ThisBinding sẽ được gắn giá trị là ngữ cảnh gốc của đoạn mã đó.

function callMe() {
  console.log(this);
}

var obj = {
  callMe: function () {
    console.log(this);
  },
};

eval('callMe()'); // đối tượng toàn cục

eval('obj.callMe()'); // đối tượng obj

Gọi eval gián tiếp

Gọi eval gián tiếp là ta gọi hàm eval thông qua một biến được gắn giá trị tương ứng như truyền hàm eval qua tham số hàm khác hoặc gắn nó với một biến nào đó. Với trường hợp này thì ThisBinding sẽ được gắn giá trị là ngữ toàn cục.

// this trong mã thực thi của eval sẽ là đối tượng toàn cục
this.callMe = function () {
  console.log('callMe in Global Object');
};

var obj = {
  callMe: function () {
    console.log(this);
  },
  _callMe: function (_eval) {
    _eval('console.log(this)');
    _eval('callMe()');
  },
};

obj._callMe(eval); // gọi gián tiếp eval qua tham số hàm

var mEval = eval; // gắn eval với một biến

mEval('console.log(this)'); // gọi gián tiếp eval qua biến mEval

Hàm - Function

Khi hàm được gọi thì ngữ cảnh thực thi của nó sẽ phụ thuộc vào tham số đầu vào và ngữ cảnh gọi nó. Giả sử hàm của ta là F, với tham số là argumentsLits, và ngữ cảnh gọi F tương ứng với thisValue. Việc xác định thisBinding được xác định như sau:

1. If hàm trong chế độ strict, ThisBinding được gắn là thisValue.
2. Else if thisValue là null hoặc undefined, ThisBinding được gắn là đối tượng toàn cục.
3. Else if Type(thisValue) không là Object, ThisBinding được gắn là ToObject(thisValue).
4. Else ThisBinding được gắn là thisValue

Xem thêm về cách gắn thisBinding tại đây.

Để rõ ràng hơn ta xét một số tình huống cụ với việc gọi hàm.

Gọi thông qua ngữ cảnh toàn cục

Trường hợp này this sẽ tham chiếu tới đối tượng toàn cục.

function mMethod() {
  console.log(this); // đối tượng toàn cục - global object
}

mMethod();

var obj = {
  myMethod: function () {
    return (function () {
      console.log(this); // đối tượng toàn cục
    })();
  },
};

obj.myMethod();

Gọi thông qua đối tượng

Trường hợp này this sẽ tham chiếu tới đối tượng thisValue - đối tượng tương ứng chứa hàm.

// Tạo đối tượng obj
var obj = {
  mMethod: function () {
    console.log(this);
  },
  oMethod: function () {
    console.log('▼ oMethod');
    console.log(this);
    console.log('▲  oMethod');
  },
};

obj.mMethod(); // this sẽ tương ứng với đối tượng obj
obj['oMethod'](); // this sẽ tương ứng với đối tượng obj

// Gắn mMethod cho đối tượng khác
var obj1 = {
  mVal: "I'm obj1",
};
obj1.mMethod = obj.mMethod;

obj1.mMethod(); // this sẽ tương ứng với đối tượng obj1

// Gọi qua khởi tạo đối tượng với từ khoá new
function MyObject(val) {
  this.mVal = val || 'I xxx JS';

  this.mMethod = function () {
    console.log(this);
  };
}

var mObj1 = new MyObject();
var mObj2 = new MyObject("I'm object 2");

mObj1.mMethod(); // this sẽ tương ứng với đối tượng mObj1
mObj2.mMethod(); // this sẽ tương ứng với đối tượng mObj2

Gọi thông qua một số hàm đặc biệt

Trong JavaScript có xây dựng sẵn một số hàm đặc biệt cho phép ta sử dụng this qua đối tượng đầu vào như:

• Function.prototype.apply(thisArg, argArray)
• Function.prototype.call(thisArg[, arg1[ , arg2, …]])
• Function.prototype.bind( thisArg[, arg1[ , arg2, …]])
• Array.prototype.every(callback[, thisArg])
• Array.prototype.some(callback[, thisArg])
• Array.prototype.forEach(callback[, thisArg])
• Array.prototype.map(callback[, thisArg])
• Array.prototype.filter(callback[, thisArg])

Bằng việc sử dụng các hàm trên ta có thể thể sử dụng this như là giá trị của đối tượng thisArg. Việc này rất tiện cho ta thay đổi thisBinding một cách chủ động. Ta có thể xem ví dụ sau:

var obj = {
  mMethod: function (firstName, lastName) {
    var firstName = firstName || 'Vô';
    var lastName = lastName || 'Danh';
    console.log('Hello ' + firstName + ' ' + lastName);
    console.log(this);
  },
};

var obj1 = {
  mVal: "I'm obj1",
};

obj.mMethod.apply(obj1); // đối tượng obj1

obj.mMethod.apply(obj1, ['Chí', 'Phèo']); // đối tượng obj1

obj.mMethod.call(obj1, 'Thị', 'Nở'); // đối tượng obj1

Đoạn mã trên sẽ in ra this là đối tượng obj1 chứ không còn là obj, do call và apply đã đẩy trực tiếp this qua tham số đầu vào.

Một số trường hợp dễ nhầm lẫn

Gọi thông qua ngữ cảnh khác

Ta xét trường hợp sau:

var obj = {
  mVal: 'Việt Nam',

  mMethod: function () {
    console.log('Hello ' + this.mVal);
  },
};

var oMethod = obj.mMethod; // oMethod nằm trong ngữ cảnh toàn cục

oMethod();

Khi thực hiện đoạn mã trên kết quả in ra sẽ là Hello undefined, vì ta đã đẩy this ra đối tượng toàn cục mất rồi. Vậy làm sao để có được đúng kết quả là Hello Việt Nam? Để giải quyết được cái này ta sẽ sử dụng hàm bind để đẩy giá trị đối tượng obj cho biến this ở đây như sau:

var obj = {
  mVal: 'Việt Nam',

  mMethod: function () {
    console.log('Hello ' + this.mVal);
  },
};

var oMethod = obj.mMethod.bind(obj); // this trong oMethod sẽ bị ép thành giá trị obj

oMethod();

Vì sao lại là bind mà không phải là call hay apply? Vì bind sẽ giữ giá trị của obj để gọi nhiều lần chứ không chỉ gọi một lần như với call hay apply. Các bạn có thể đọc thêm bài viết về call, apply và bind. Với trường hợp gọi một lần với call hoặc apply ta có thể cùng nhau xem ví dụ sau:

var obj = {
  mVal: 'Việt Nam',

  mMethod: function () {
    console.log('Hello ' + this.mVal);
  },
};

var obj1 = {
  mVal: 'Nhật Bản',
};

obj.mMethod.call(obj1); // in ra là: Hello Nhật Bản

Đoạn mã trên sẽ gọi hàm mMethod của đối tượng obj nhưng this trong hàm mMethod đã được ép thành đối tượng obj1. Với việc gọi 1 lần này ta có thể mượn phương thức mMethod của đối tượng obj để thực thi cho đối tượng obj1 mà không cần tạo phương thức này cho đối tượng obj1. Cái này khá kool đúng hem ^.^

Hàm phản hồi - Callback

Gọi thông qua hàm phản hồi cũng chính là một trường hợp của gọi thông qua ngữ cảnh khác vì hàm phản hồi được thực thi trong một ngữ cảnh khác. Ta xét ví dụ sau:

var obj = {
  mVal: 'Việt Nam',

  mMethod: function () {
    console.log('Hello ' + this.mVal);
  },
};

var obj1 = {
  oMethod: function (callback) {
    return callback();
  },
};

obj1.oMethod(obj.mMethod);

Vì gọi trong ngữ cảnh của đối tượng obj1 nên mMethod lúc này sẽ lấy giá trị cho this là obj1 chứ không còn là obj nữa. Vẫn làm tương tự như phần 3.1, ta sử dụng bind để đẩy giá trị ngữ cảnh obj vào cho mMethod như sau:

var obj = {
  mVal: 'Việt Nam',

  mMethod: function () {
    console.log('Hello ' + this.mVal);
  },
};

var obj1 = {
  oMethod: function (callback) {
    return callback();
  },
};

obj1.oMethod(obj.mMethod.bind(obj));

Hoàn hảo, đoạn mã trên đã cho ta kết quả như mong muốn. Đọc tới đây, nhiều bạn thắc mắc sao cần gì phải tách ra 3.1 với 3.2 làm gì cho rắc rối? Tách ra thế này có lợi thế là không bị vướng quá nhiều vấn đề vào cả một cụm, ví hàm phản hồi là một trường hợp rất hay được sử dụng khi lập trình với JavaScript. Ví dụ như trong Nodejs, hàm phản hồi là một thành phần quan trọng, một khái niệm cơ bản nhất cần nắm được để có thể lập trình với Nodejs. Hay nhiều bạn có sử dụng JQuery để làm phía trình duyệt, các sự kiện click vào một nút nào đó chẳng hạn, các bạn đều sử dụng luôn được từ khoá this ngay trong hàm phản hồi của các nút đó mà không cần quan tâm tới ngữ cảnh thực thi hiện tại là gì cả. Để làm được việc đó, jQuery đều đã bind các nút tương ứng đó cho các hàm phản hồi cho các bạn rồi đó.

Hàm lồng nhau

Ta cùng xét sự nhập nhằng qua ví dụ sau.

var obj = {
  mVal: 'Việt Nam',

  oVal: {
    oMethod: function (callMe) {
      callMe();
    },
  },

  mMethod: function () {
    this.oVal.oMethod(function () {
      console.log('Hello ' + this.mVal);
    });
  },
};

obj.mMethod(); // in ra là: Hello undefined

Với đoạn mã trên ta mong muốn nó in ra được giá chỉ của biến mVal trong đối tượng obj nhưng thực tế nó sẽ in ra Hello undefined? Nguyên nhân là ngữ cảnh của thực thi ở console.log lúc này là đối tượng oVal mất rồi. Vậy làm sao ta có thể sử dụng được biến mVal của đối tượng obj? Muốn làm được như vậy ta cần lấy được ngữ cảnh thực thi của đối tượng obj bằng cách nhớ lại ngữ cảnh thực thi thông qua một biến trung gian và sử dụng biến này với ngữ cảnh của đối tượng oVal. Ví dụ dưới đây sẽ thực hiện theo ý tưởng này:

var obj = {
  mVal: 'Việt Nam',

  oVal: {
    oMethod: function (callMe) {
      callMe();
    },
  },

  mMethod: function () {
    var _this = this; // nhớ ngữ cảnh thực thi của obj trong biến _this

    this.oVal.oMethod(function () {
      console.log('Hello ' + _this.mVal); // gọi tới ngữ cảnh thực thi của obj
    });
  },
};

obj.mMethod();

Kết luận

Từ khoá this hơi rắc rối một chút nên khi lập trình ta cần chú ý tới ngữ cảnh thực thi để sử dụng từ khoá này cho hiệu quả và đúng đắn dựa vào ngữ cảnh gọi nó và kiểu của ngữ cảnh thực thi. Ta cũng cần chú ý hơn ở những đoạn sử dụng tới hàm phản hồi hay hàm lồng nhau. Ngoài ra ta có thể thay đổi được ngữ cảnh thực thi của một đối tượng bằng cách sử dụng call, apply hoặc bind như đã mô tả phía trên.

Về việc sử dụng Call, Apply và Bind cụ thể ra sao thì các bạn đọc thêm ở bài viết này.

Ngoài ra, bạn có thể tham khảo về chuẩn ECMAScript 5.1.

Về cơ bản call và apply gần giống nhau và được giới thiệu từ phiên bản 3 theo chuẩn ECMAScript, còn bind được giới thiệu từ phiên bản 5 thì lại khác hẳn về bản chất nhưng cũng có mối quan hệ mật thiết với 2 phương thức kia. Vậy nên trong bài này ta sẽ đi dần từ call với apply tới bind.

Call và Apply

Cú pháp:

• call()

  Function.prototype.call(thisArg[, arg1[ , arg2, …]])

• apply()

  Function.prototype.apply(thisArg, argArray)

Phương thức call() và apply() để gọi thực thi một hàm với một ngữ cảnh chỉ định thông qua tham số thisArg và các tham số đầu vào của hàm tương ứng. Tức là nó sẽ cho phép hàm thực thi được với một ngữ cảnh chỉ định nào đó tuỳ ý. Sự khác nhau giữa chúng là call() sẽ nhận tham số hàm qua từng biến đầu vào riêng biệt còn apply() thì lại nhận các tham số hàm qua một mảng chứa các biến đầu vào. Ta cùng xét ví dụ bên dưới:

var obj = {
  firstName: 'Vô',
  lastName: 'Danh',

  mMethod: function (firstName, lastName) {
    var firstName = firstName || this.firstName;
    var lastName = lastName || this.lastName;
    console.log('Hello ' + firstName + ' ' + lastName);
  },
};

var obj1 = {
  firstName: 'Ông',
  lastName: 'Ké',
};

obj.mMethod(); // Hello Vô Danh

obj.mMethod.call(obj1); // Hello Ông Ké

obj.mMethod.apply(obj1); // Hello Ông Ké

obj.mMethod.call(obj1, 'Thị', 'Nở'); // Hello Thị Nở

obj.mMethod.apply(obj1, ['Chí', 'Phèo']); // Hello Chí Phèo

Với đoạn mã trên ta có thể thấy rằng, sau khi gọi call() hoặc apply() ngữ cảnh thực thi của mMethod đã được đổi sang obj1 và call() cho phép ta truyền tham số đầu vào riêng biệt còn apply() lại cho phép truyền vào như một mảng.

Từ phiên bản 5, apply() còn có thể được truyền vào một đối tượng tựa mảng (chú thích [1]) thay vì mảng:

var obj = {
  firstName: 'Vô',
  lastName: 'Danh',

  mMethod: function (firstName, lastName) {
    var firstName = firstName || this.firstName;
    var lastName = lastName || this.lastName;
    console.log('Hello ' + firstName + ' ' + lastName);
  },
};

var obj1 = {
  firstName: 'Ông',
  lastName: 'Ké',
};

obj.mMethod.apply(obj1, ['Chí', 'Phèo']); // Hello Chí Phèo

obj.mMethod.apply(obj1, { length: 2, 0: 'Chí', 1: 'Phèo' }); // Hello Chí Phèo

Với việc sử dụng call() hoặc apply() ta có thể làm được rất nhiều việc hay ho như sử dụng phương thức của một ngữ cảnh khác như ở ví dụ trên, hay đẩy ngữ cảnh thực thi cho hàm phản hồi hoặc thay đổi cách truyền tham số hàm rất hiểu quả. Các bạn có thể xem ở ví dụ sau:

• Truyền ngữ cảnh thực thi cho hàm phản hồi

function print() {
  console.log(this.mVal);
}

var obj = {
  mVal: 'Tôi yêu thành phố Hồ Chí Minh',

  mMethod: function (callback) {
    // truyền đối tượng hiện tại cho hàm phản hồi callback
    callback.call(this);
  },
};

obj.mMethod(print);

• Thay đổi cách truyền tham số hàm

// Math.min([value1[,value2[, ...]]])
// Ta sử dụng mảng cho tham số đầu vào thay vì các giá trị rời rạc
console.log(Math.min.apply(null, [100, -1, 8, 219])); // -1

Cũng không tồi đấy chứ, bằng call, apply ta có thể linh hoạt hơn khi lập trình, đỡ được nhiều công sức biến đổi rắc rối và tận dụng được mã nguồn rất hiệu quả.

Bind

Cú pháp:

Function.prototype.bind( thisArg[, arg1[ , arg2, …]])

Phương thức bind() sẽ tạo ra một hàm mới có nội dung thực thi như hàm được gọi nhưng được gắn với một ngữ cảnh thực thi chỉ định qua tham số thisArg. Như vậy khác với call() và apply(), bind() sẽ không gọi để thực thi hàm mà sẽ lưu lại ngữ cảnh thực thi cho một hàm nào đó như ví dụ sau:

var obj = {
  mVal: 'Việt Nam',

  mMethod: function () {
    console.log('Hello ' + this.mVal);
  },
};

var oMethod = obj.mMethod.bind(obj); // this trong oMethod sẽ bị ép thành giá trị obj

oMethod(); // Hello Việt Nam

obj.mVal = 'Hà Nội';

oMethod(); // Hello Hà Nội

Như vậy khác với call() và apply(), khi gọi bind() hàm sẽ không thực thi ngay mà chỉ gắn ngữ cảnh thực thi cho phương thức mMethod. Vì mMethod được gắn với ngữ cảnh đối tượng obj, nên mỗi lần thực thi nó sẽ sử dụng this như là đối tượng obj. Như trong ví dụ phía trên, sau khi ta thay đổi giá trị của biến mVal trong đối tượng obj thì mMethod cũng sẽ in ra giá trị đã bị thay đổi.

Về bản chất thì bind() có thể được thực hiện như sau:

Function.prototype.bind = function (context) {
  var _this = this;
  return function () {
    _this.apply(context, arguments);
  };
};

Bằng việc sử dụng apply(), ta có thể thay đổi ngữ cảnh thực thi cho một hàm, còn để lưu lại ngữ cảnh dành cho việc thực thi sau này ta tạo ra một hàm mới như trong đoạn mã trên.

Vì tính chất lưu lại được ngữ cảnh nên bind() rất hay được sử dụng với hàm phản hồi như xử lý sự kiện click vào một nút nào đó chẳng hạn. Ví dụ như khi sử dụng jQuery, ta có thể lấy được giá trị cho this bằng button trong các hàm phản hồi của sự kiện click vào một button vì jQuery đều đã buộc (bind) sẵn button cho hàm phản hồi được truyền vào.

<!doctype html>
<html>
  <head>
    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js"></script>
    <script>
      $(document).ready(function () {
        $('#btn').click(function () {
          console.log(this);
          $(this).text(Number($(this).text()) + 1);
        });
      });
    </script>
  </head>
  <body>
    <button id="btn">0</button>
  </body>
</html>

Ngoài ra, ta có thể làm được rất nhiều việc khá hay ho như tạo shortcut cho hàm nào đó, hay nhóm lại các tham số theo từng cụm như ví dụ bên dưới:

var obj = {
  firstName: 'Thánh',
  lastName: 'Gióng',

  mMethod: function (hello, firstName, lastName) {
    var hello = hello || 'Hello',
      firstName = firstName || this.firstName,
      lastName = lastName || this.lastName;

    console.log(hello + ' ' + firstName + ' ' + lastName);
  },
};

// tạo shortcut
var print = obj.mMethod.bind(obj);
print();

var print = obj.mMethod.bind(obj, 'Hello', 'Mr', 'Bean');
print();

// Nhóm theo hello
print = obj.mMethod.bind(obj, 'Xin chào bạn');
print();

// Nhóm theo firstName
print = obj.mMethod.bind(obj, 'Kính chào ngài', 'Nguyễn');
print('Trãi');
print('Xiển');

Vui vẻ tý

Như bên trên đã phân tích, khi ta cần thực thi một function cho một ngữ cảnh khác, ta cần sử dụng call, apply hoặc bind, nhưng có một cách vượt mặt để không cần sử dụng nó. Bạn có thể xem ví dụ sau:

var obj = {
  firstName: 'Vô',
  lastName: 'Danh',

  mMethod: function (firstName, lastName) {
    var firstName = firstName || this.firstName;
    var lastName = lastName || this.lastName;
    console.log('Hello ' + firstName + ' ' + lastName);
  },
};

var obj1 = {
  firstName: 'Ông',
  lastName: 'Ké',
};

obj.mMethod.apply(obj1); // Hello Ông Ké

// vượt mặt ở đây
var method = Function.call.bind(obj.mMethod);

method(obj1); // Hello Ông Ké

// vượt mặt trong prototype của object
method = Function.call.bind(Array.prototype.slice);

console.log(method([100, 20, 40], 1)); // [20, 40]

Với đoạn mã trên, ta có thế thấy rằng khi gọi method ta không cần phải gọi call, apply hay bind ra nữa mà chỉ cần đẩy trực tiếp đối tượng cần gọi và tham số vào là đủ. Khá hay ho đấy chứ? gọi call, apply, bind mãi cũng chán, overcome một tý thấy nó tiện hơn hẳn.

Ta có thể làm được như vậy là vì tất cả các function trong JavaScript đều kế thừa từ đối tượng Function.prototype, nên hiển nhiên nó có tất cả các function được định nghĩa từ Function.prototype như call, apply hay bind. Như vậy, ta hoàn toàn có thể gọi được các phương thức kế thừa này từ một function bất kì.

Với ví dụ trên, ta coi obj.mMethod là một đối tượng cần gọi tới phương thức call thì ta hoàn toàn có thể tạo một phương thức method trực tiếp từ phương thức call mà đã được gắn thisVal bằng obj.mMethod: Function.call.bind(obj.mMethod) hoặc Function.prototype.call.bind(obj.mMethod). Hay nói cách khác, phương thức method mới được tạo ra có nội dung giống như phương thức call và đối tượng chứa nó (gọi nó - this) là đối tượng obj.mMethod nên method() ~ obj.mMethod.call().

Kết luận

Bằng việc sử dụng call, apply và bind ta có thể thay đổi được ngữ cảnh thực thi (phạm vi chứa hàm) để sử dụng một hàm với công dụng đa năng hơn như thực thi cho một đối tượng, phạm vi khác khác giúp ta có thể tận dụng tối đa mã nguồn được đã tạo ra, hay tạo shortcut cho hàm, linh hoạt hơn tham số đầu vào. Với call và apply chúng ta sử dụng để thực thi hàm đó luôn khi gọi, còn với bind ta có thể thực thi hàm đó nhiều lần sau khi đã được buộc (bind) với một ngữ cảnh nhất định.

Chú thích [1] đối tượng tựa mảng: Một đối tượng tựa mảng (array-like object) là một đối tượng có các thuộc tính là số tự nhiên và có một thuộc tính bắt buộc là length có giá trị bằng số các thuộc tính là số tự nhiên. Ví dụ: {length: 3, 0: "Tôi", 1: "là", 2: "người Việt"} hoặc {'length': 3, '0': "Tôi", '1': "là", '2': "người Việt"}.

function wait(ms, cb) {
  setTimeout(cb, ms);
}

function main() {
  console.log('sắp rồi...');
  wait(2007, () => {
    console.log('chờ tí...');
    wait(2012, () => {
      console.log('thêm chút nữa thôi...');
      wait(2016, () => {
        console.log('xong rồi đấy!');
      });
    });
  });
}

Vì vậy, với phiên bản ES6 (ES 2016), Promise đã được đưa vào mặc định nhằm giải quyết tình trạng callback hell. Với Promise, mã nguồn của ta sẽ trông gần giống với phong cách đồng bộ, kết quả là trông dễ theo dõi và bảo trì hơn. Tuy nhiên sử dụng Promise lại làm phát sinh vấn đề “khá” tương tự là Promise hell ( lol! JavaScript Heo! ).

function wait(ms) {
  return new Promise((r) => setTimeout(r, ms));
}

function main() {
  console.log('sắp rồi...');
  wait(2007)
    .then(() => {
      console.log('chờ tí...');
      return wait(2007);
    })
    .then(() => {
      console.log('thêm chút nữa thôi...');
      return wait(2012);
    })
    .then(() => {
      console.log('thêm chút nữa thôi...');
      return wait(2016);
    })
    .then(() => {
      console.log('xong rồi đấy!');
    });
}

Để giải quyết vấn đề đó, ở phiên bản ES7 (ES 2017), 1 khái niệm với 2 từ khóa mới được đưa vào là hàm async (async / await). Hàm async cho phép ta viết các thao tác bất đồng bộ với phong cách của các mã đồng bộ. Bằng cách viết như vậy, mã nguồn của ta trông sẽ sáng sủa, dễ đọc hơn và “dễ hiểu hơn”.

function wait(ms) {
  return new Promise((r) => setTimeout(r, ms));
}

async function main() {
  console.log('sắp rồi...');
  await wait(2007);
  console.log('chờ tí...');
  await wait(2012);
  console.log('thêm chút nữa thôi...');
  await wait(2016);
  console.log('xong rồi đấy!');
}

Cách sử dụng

Để sử dụng hàm async, ta cần khai báo từ khóa async ngay trước từ khóa định nghĩa hàm. Tức là, với hàm định nghĩa với từ khóa function ta phải khai báo ngay trước function, với hàm mũi tên (arrow function) ta phải khai báo trước tập tham số đầu vào, với phương thức của lớp Class thì ta phải khai báo ngay trước tên hàm.

// regular function
async function functionName() {
  let ret = await new Google().search('JavaScript');
}

// arrow function
let arr = ['JS', 'node.js'].map(async (val) => {
  return await new Google().search(val);
});

// Class
class Google {
  constructor() {
    this.apiKey = '...';
  }

  async search(keyword) {
    return await this.searchApi(keyword);
  }
}

Với từ khóa async này, ta có thể đợi các Promise (thao tác bất đồng bộ) xử lý trong hàm đó mà không tạm dùng luồng chính bằng từ khóa await như ví dụ trên.

Kết quả trả ra của hàm async luôn là một Promise dù bạn có gọi await - có xử lý bất đồng bộ hay không. Promise này sẽ ở trạng thái thành công với kết quả được trả ra với từ khóa return của hàm async, hoặc trạng thái thất bại với kết quả được đẩy qua từ khóa throw trong hàm async.

Như vậy, bản chất của hàm async chính là Promise. Nếu bạn chưa tìm hiểu về Promise thì nên đọc trước ở bài viết này.

Với Promise, ta có thể xử lý ngoại lệ với catch khá đơn giản. Tuy nhiên cũng không dễ dàng theo dõi và dễ đọc. Nhưng với hàm async, việc này cực kì đơn giản bằng từ khóa try catch hệt như các thao tác đồng bộ.

//
// test.js
//
function wait(ms) {
  return new Promise((r) => setTimeout(r, ms));
}

async function runner() {
  console.log('sắp rồi...');
  await wait(2007);
  console.log('chờ tí...');
  await wait(2012);
  console.log('thêm chút nữa thôi...');
  await wait(2016);
  throw new Error(2016);
}

async function main() {
  try {
    await runner();
    console.log('xong rồi đấy!');
  } catch (e) {
    console.log(`có vấn đề tại ${e}`);
  }
}

// Node v7
// `$ node --harmony-async-await test.js`
// Console: ... có vấn đề tại 2016

Ngon! Rõ ràng là mã nguồn sử dụng async/await trông đơn giản, dễ theo dõi, “dễ hiểu” hơn và giải quyết được tình trạng callback - promise hell. Tuy nhiên, việc sử dụng nó cũng không phải lúc nào cũng đơn giản. Ta cùng nhau xem một số trường hợp dưới đây.

Lưu ý

Quên khai báo từ khóa async

Đương nhiên rồi, không khai báo từ khóa này thì ta không có hàm async được, không sử dụng await được rồi. Thường bạn sẽ nghĩ đơn giản là không thể nào quên được từ khóa này, nhưng tôi nghĩ đôi lúc có thể đấy. Ví dụ như với trường hợp khai báo một hàm trong một hàm async. Hàm khai báo trong hàm async cũng bắt buộc phải được khai báo với từ khóa async nếu như bạn muốn sử dụng như một hàm async.

async function main() {
  await wait(1000)
  let arr = [100, 300, 500].map(val => wait(val))
  arr.forEach(func => await func)
  // ??? error
}

Nhập nhằng từ khóa await

Có 2 tình huống điển hình cho trường hợp này là:

• Quên khai báo khi cần đợi một xử lý bất đồng bộ

  Có gì đáng sợ không? Câu trả lời là có đấy! Nếu bạn không khai báo từ khóa này thì kết quả bạn nhận được sẽ là một Promise chứ không phải là kết quả thực thi của xử lý bất đồng bộ nhé.

  async function now() {
    return Date.now();
  }
  
  async function main() {
    let t = now();
    console.log(t);
    // ??? `t` is a `Promise` instance
  }
  

• Khai báo “thừa” trước một xử lý đồng bộ

  Nếu mà sợ quên thì cứ khai báo bừa đi, đâu có sao? Ừ không sao đâu ngoại trừ 2 vấn đề là không biết cái nào là đồng bộ, cái nào là bất đồng bộ nữa, và hiệu quả đi xuống đấy. Mỗi khi bạn khai báo await thì mặc nhiên sau từ khóa đó là một Promise, nếu không phải là một Promise thì nó sẽ được gói lại vào Promise và được trả ra ngay với phương thức Promise.resolve(value). Rảnh quá ha, muốn lấy 1 + 0 = 1 mà phải đi đường vòng là tính tổng, rồi nhét vào Promise, rồi lại moi ra để sử dụng.

  async function main() {
    // run with await
    console.log('run with await');
    let i = 1000000;
    console.time('await');
    while (i-- > 0) {
      let t = await (1 + 0);
    }
    console.timeEnd('await');
  
    // run without await
    console.log('run without await');
    i = 1000000;
    console.time('normal');
    while (i-- > 0) {
      let t = 1 + 0;
    }
    console.timeEnd('normal');
  }
  

Quên xử lý lỗi

Cũng như với việc quên catch lỗi khi sử dụng Promise, việc quên try catch để bắt lỗi với hàm async cũng có thể xảy ra. Nếu bạn quên không bắt lỗi, thì khi đoạn mã bất đồng của bạn xảy ra lỗi có thể làm chương trình của bạn bị dừng lại.

function wait(ms) {
  if (ms > 2015) throw new Error(ms);
  return new Promise((r) => setTimeout(r, ms));
}

async function main() {
  console.log('sắp rồi...');
  await wait(2007);
  console.log('chờ tí...');
  await wait(2012);
  console.log('thêm chút nữa thôi...');
  await wait(2016);
  console.log('xong rồi đấy!');
}

Mất tính song song

Cái này có vẻ là căng nhất, bạn cứ khai báo await tuần tự đi rồi chương trình của bạn sẽ chậm như con rùa. hahaaa. Vì mỗi lần khai báo await như vậy là bạn cần phải chờ cho xử lý của await kết thúc. Kết quả là bạn có 1 con rùa chạy tuần tự qua từng nấc thang.

function wait(ms) {
  return new Promise((r) => setTimeout(r, ms));
}

async function main() {
  console.time('wait3s');
  await wait(1000);
  await wait(2000);
  console.timeEnd('wait3s');
}

Với đoạn mã trên bạn sẽ mất tổng cộng là 1 + 2 = 3s để thực thi. Vì bạn phải chờ từng hàm wait một. Vậy làm sao để tránh được tình trạng trên? Câu trả lời là cứ cho xử lý bất đồng bộ chạy trước đi rồi lấy kết quả sau. Vì Promise có thể cho phép ta lấy kết quả bất cứ khi nào mà nó ở trạng thái cuối cùng, nên ta có thể chạy nó trước rồi lấy sau cũng không sao cả.

function wait(ms) {
  return new Promise((r) => setTimeout(r, ms));
}

async function main() {
  console.time('wait2s');
  let w1 = wait(1000);
  let w2 = wait(2000);
  await w1;
  await w2;
  console.timeEnd('wait2s');
}

Như đoạn mã này, ta chỉ mất 2s để thực hiện vì đoạn wait của ta được thực thi song song. Ngoài cách await từng Promise như trên ta có thể sử dụng Promise.all để song song hóa các Promise.

function wait(ms) {
  return new Promise((r) => setTimeout(r, ms));
}

async function main() {
  console.time('wait2s');
  await Promise.all([wait(1000), wait(2000)]);
  console.timeEnd('wait2s');
}

Lúc này, có thể bạn đang nghĩ Promise.all và await từng Promise là như nhau, nhưng nó khác nhau chút đấy. Promise.all chỉ ở trạng thái thành công khi mà tất cả các Promise được truyền vào xử lý thành công, còn nó sẽ ở trạng thái lỗi khi một trong các Promise truyền vào bị lỗi. Như vậy, nếu bạn muốn bỏ qua các Promise lỗi thì bạn không thể sử dụng Promise.all được đâu. Lúc đó bắt buộc bạn phải sử dụng await kèm với try catch cho từng Promise của bạn.

function wait(ms) {
  if (ms > 2000) throw new Error(ms);
  return new Promise((r) => setTimeout(r, ms));
}

async function main() {
  const dur = [1000, 2000, 3000, 4000];
  let all = dur.map((ms) => wait(ms));
  try {
    await Promise.all(all);
    console.log('Promise.all - done');
  } catch (e) {
    console.error('Promise.all:', e);
  }

  let each = dur.map((ms) => wait(ms));
  each.forEach(async (func, index) => {
    try {
      await func;
      console.log('each - done:', dur[index]);
    } catch (e) {
      console.error('each:', e);
    }
  });
}

Nền tảng/ trình duyệt hỗ trợ

Thời điểm này (2016/10), các nền tảng và trình duyệt sau đã hỗ trợ hàm async.

• Node.js v7.0 với cờ --harmony-async-await
• Chrome v5.55
• Microsoft Edge v21.10547

Nếu bạn muốn chạy ở các nền tảng/ trình duyệt chưa hỗ trợ thì có thể dùng babel để chuyển đổi:

• Babel async-2-generator plugin

Kết luận

Bản chất của hàm async chính là Promise, vì vậy để sử dụng được nó ta cần phải sử dụng Promise cho việc xử lý các thao tác bất đồng bộ. Bạn không thể nào sài await để đợi các hàm có sử dụng hàm phản hồi (callback) được, mà bắt buộc phải gắn nó với một Promise trước khi sử dụng await.

Mặc dù hàm async có cú pháp rất rõ ràng, ta cũng cần phải lưu ý tránh khai báo thừa thiếu các từ khóa gây lỗi, gây hiểu lầm về lô-gíc chương trình. Và đặc biệt lưu ý tới khả năng làm mất đi tính song song của chương trình.

Với sự tiện dụng của hàm async, ta nên cố gắng sử dụng nó ngay từ bây giờ để giảm thiểu việc bảo trì sau này. Với các nền tảng/ trình duyệt chưa hỗ trợ thì ta có thể chuyển đổi bằng babel. Hiện tại Node v7 vẫn đang sử dụng Chrome v5.54 nên muốn sử dụng được async/await, ta buộc phải chạy với cờ --harmony-async-await và hiệu năng, bộ nhớ được sử dụng vẫn chưa hiệu quả, không khuyến khích cho các sản phẩm thực tế. Tuy nhiên, rất có thể Node v8 sẽ sử dụng phiên bản Chrome v5.55 và cho phép ta thực hiện mặc định các hàm async.

async chúc các bạn await vui vẻ!

Bạn lấy độ dài của mảng thế nào?

Hôm qua ngồi code lúc lấy độ dài mảng bằng thuộc tính length mới thấy khác biệt với phần tử lấy được, làm mình hơi ngạc nhiên một chút. Ngồi đọc lại tài liệu JS, mới thấy dường như nó không có thuộc tính lưu trữ số lượng phần tử hiện hữu (khác undefined) trong nó thì phải? Hoặc ít nhất là mình chưa rõ. Có cao thủ nào chỉ giáo cho thì tốt. Các bạn có thể thử đoạn mã sau thì sẽ thấy rằng thuộc tính length của mảng sẽ bằng tổng của index lớn nhất của mảng với 1.

var arr = [];
arr[10] = 0;
arr[20] = 'index 20';
arr['js'] = 'JavaScript';
console.log(arr.length);

Đoạn mã trên sẽ in ra độ dài của mảng arr là 21, tức là bằng index lớn nhất (20) cộng với 1. Hơi bất ngờ chút vì lúc đầu mình nghĩ nó trả ra là 3 (số phần tử khác undefined) .

Còn index không phải là dạng số tự nhiên thì có ý nghĩa gì không? Câu trả lời là không có ý nghĩa gì với thuộc tính length cả. Các bạn có thể xem trong ví dụ sau thì sẽ thấy độ dài length sẽ không phụ thuộc vào các index không thuộc dạng số tự nhiên.

var arr = [];
arr[-1] = 100;
arr['js'] = 'JavaScript';
arr['me'] = 'Java Lover';
console.log(arr.length);

Đoạn mã này sẽ luôn in ra 0, chứng tỏ các index không số tự nhiên không ảnh hưởng gì tới thuộc tính length.

Vậy câu hỏi đặt ra là làm thế nào để lấy được số phần tử chính xác của một mảng?

Một cách làm đơn giản là duyệt mảng để đếm số lượng các phần tử hiện hữu của mảng đúng không? Thế nhưng mọi chuyện lại không đơn giản như ta nghĩ.

Bạn duyệt mảng thế nào?

Duyệt mảng trong JS cũng rất thú vị. Cách duyệt mảng thông thường với một mảng là lấy length của nó rồi duyệt từ đầu tới cuối như sau.

var arr = [];
arr[10] = 0;
arr[20] = 'index 20';
arr['me'] = 'Java Lover';
var counter = 0;
for (var i = 0, len = arr.length; i < len; i++) {
  console.log(i + ': ' + arr[i]);
  if (typeof arr[i] != 'undefined') counter++;
}
// hoặc như sau
for (var i = arr.length; i > 0; --i) {
  console.log(i + ': ' + arr[i]);
  if (typeof arr[i] != 'undefined') counter++;
}
console.log('The size of array: %d', counter);

Kết quả đoạn mã trên sẽ trả ra các phần từ có index từ 0 ~ 9 và 11 ~ 19 là undefined, và counter sẽ là 2. Như vậy là counter không cho ra kết quả chính xác và với một mảng lớn (1000 phần tử chẳng hạn) ta không thể duyệt theo cách này được. Vậy phải có cách khác, ta thử dùng hàm forEach của Array xem sao.

var arr = [];
arr[10] = 0;
arr[20] = 'index 20';
arr['me'] = 'XXX Lover';
var counter = 0;
arr.forEach(function (ele, i, array) {
  console.log(i + ': ' + ele);
  counter++;
});
console.log('The size of array: %d', counter);

Cách này vẫn không ăn thua, kết quả lại như duyệt theo biến length. Thêm một cách duyệt khác là với lệnh for in như sau.

var arr = [];
arr[10] = 0;
arr[20] = 'index 20';
arr['me'] = 'Java Lover';
var counter = 0;
for (var i in arr) {
  console.log(i + ': ' + arr[i]);
  counter++;
}
console.log('The size of array: %d', counter);

Đoạn này lại cho ra kết quả chính xác với từng phần tử được in ra và kích cỡ mảng trả về là 3.

Từ đây ta có thể thấy một điều là nên cẩn thận với biến length của mảng và nên chú ý cách duyệt mảng sao cho hợp lý. Với các dữ liệu liên tục ta hoàn toàn có thể duyệt theo biến length hay Array.forEach, nhưng dữ liệu cách đoạn và index không là số tự nhiên thì cần theo cách duyệt for in.

Làm sao để biết một biến là mảng?

Các bạn thử chạy đoạn mã sau xem thế nào.

var arr = [];
arr[10] = 0;
arr[20] = 'index 20';
arr['me'] = 'JavaScript Lover';

console.log("Trust me, men, I'm an Array @@");
console.log('Really, I have to check your DNA.');
console.log('JavaScript checker: arr is ' + typeof arr);

??? Mày là Object mà sao lại bảo là Array? Không cháu là mảng mà, bác thử kiểm tra với cái máy này xem.

var arr = [];
arr[10] = 0;
arr[20] = 'index 20';
arr['me'] = 'JavaScript Lover';

console.log(
  'JavaScript checker: Is arr an array ... ' +
    (Object.prototype.toString.apply(arr) === '[object Array]')
);

Ồ, ồ khỉ thật sao lại thế nhỉ? Đấy cháu dòng giống hoàng tộc nên phải ẩn mình thế đấy. Đúng là nhìn gái xinh thì dễ chứ nhìn gái tốt hay xấu phải có mẹo thật.

Để kết thúc bài, dành tặng cho các bạn beginner về NodeJS một đoạn mã nhỏ. Bài toán đặt ra là lấy nội dung 3 trang web (giao thức http) với địa chỉ nhập từ bàn phím theo dạng bất đồng bộ và in ra nội dung các trang đó theo đúng thứ tự đầu vào nhập từ bàn phím. Chắc code này không phải giải thích nhiều các bạn cũng sẽ thấy có mối tương quan với nội dung mình vừa viết phía trên.

var http = require('http');
var bl = require('bl');
var data = [];
var counter = 0;

function printData() {
  for (var i = 0; i < 3; i++) console.log(data[i]);
}

function loadData(index) {
  http.get(process.argv[2 + index], function (resp) {
    resp.pipe(
      bl(function (err, buf) {
        if (err) data[index] = err.toString();
        else data[index] = buf.toString();
        counter++;
        if (counter === 3) printData();
      })
    );
  });
}

for (var i = 0; i < 3; i++) loadData(i);

Bài này tạm thời thế, khi nào gặp vấn đề lại update tiếp. Mong các cao thủ biết được gì thêm về mảng trong JavaScript thì chỉ giáo cho các hạ.

Phong cách: Series này sử dụng phép ẩn dụ “tu tiên / võ hiệp” để kể chuyện lập trình. Đây là lựa chọn chủ đích của tác giả nhằm khiến các khái niệm khô khan trở nên sinh động hơn.

Functional Programming là một con đường khác, một phương pháp tư duy khác trong coding. Ở tầm nhìn trừu tượng hơn, người ta xếp Functional Programming vào nhóm “Declarative”, còn OOP thuộc nhóm “Imperative”.

Từ các bài học ngữ pháp chúng ta đã biết 2 kiểu câu: câu trần thuật (Declarative Sentence), và câu mệnh lệnh (Imperative Sentence).

Lập trình theo lối “Imperative Programming” là sắp xếp một loạt các mệnh lệnh liên tiếp, để máy tính thực thi tuần tự từng bước. Ở đây người ta tập trung vào “how”. Nào, hãy làm thế này, rồi làm thế kia… Một hình thức “cầm tay chỉ việc”.

Ví dụ trên trang web có 4 boxes màu đỏ thế này:

<style>
.box {
  width: 100px;
  height: 100px;
  float: left;
  margin: 10px;
  background-color: red;
}
.hide {
  display: none;
}
</style>
<div class="box hide"></div>
<div class="box hide"></div>
<div class="box hide"></div>
<div class="box hide"></div>

Mấy boxes này đang ẩn, ta cần làm chúng hiện ra bằng cách loại bỏ class “hide” đi.

Các giáo viên tin học đáng kính ở trường xưa thường dạy viết kiểu như thế này:

// tìm hết các tags có class "box':
const els = document.querySelectorAll('.box');
// quét tất cả các tags tìm thấy
for (let i = 0; i < els.length; i++) {
  // với tag thứ i
  let el = els[i];
  // xóa bỏ class "hide" để cho tag hiện lên
  el.classList.remove('hide');
  // nếu còn phần tử phía sau thì tăng i lên 1 đơn vị
  // quay lại với xử lý tag thứ i + 1
}

Họ dùng code hướng dẫn cho máy tính làm từng nhiệm vụ.

Người tu luyện Functional Programming không tư duy theo cách đó.

No for/while

“Declarative Programming” là tập trung vào “what”. Chúng ta chỉ cần định nghĩa những quy tắc đầu vào, đầu ra. Chẳng hạn “nếu input là 1 thì output là 2”. Phần còn lại để máy tính xử lý.

Người tu luyện Functional Programming không cần for loop.

Code như thế này nhìn mới mẻ hơn nhiều:

const getElements = (selector) => {
  return Array.from(document.querySelectorAll(selector));
};

const getRemover = (el) => {
  return (className) => {
    el.classList.remove(className);
    return el;
  };
};

const els = getElements('.box')
  .map(getRemover)
  .map((removeClass) => removeClass('hide'));

console.log(els);

Trước tiên chúng ta tạo ra 1 pure function getElements dùng để lấy các elements trên trang thông qua CSS Selector. Tập hợp này vốn là ArrayLike, ta dùng Array.from chuyển thành Array thực sự để có thể tận dụng các phương thức trong Array prototype.

Ở đây ta định nghĩa input là CSS Selector, output là 1 mảng DOM Elements.

Còn getRemover lại là 1 higher-order function. Có thể gọi nó bằng cách chaining getRemover(DOMElement)(classToRemove). Chúng ta lợi dụng đặc tính của higher-order function, sau 2 lần map thì chạm tới function do getRemover ném lại.

Ở đây ta định nghĩa input là DOM Element, output là function() {nhận input là className và output là DOM Element đã mất đi class đó}.

Code như vậy ta có thể đem logic dùng lại ở nhiều chỗ khác nhau, chỉ cần thay đổi input. Ví dụ loại bỏ class float-left khỏi tất cả các thẻ div.

const els = getElements('div')
  .map(getRemover)
  .map((removeClass) => removeClass('float-left'));

No if/else

Người tu luyện Functional Programming cũng không cần if/else.

Thậm chí họ còn tạo ra cả một chiến dịch Anti-IF!

Có nhiều cách để loại bỏ hoàn toàn if/else ra khỏi chương trình của bạn. Đơn giản nhất là dùng ternary.

Ternary

Trong JavaScript, ternary - tam phân - có tên gọi chính thức là Toán tử Điều kiện - Conditional Operator. Nó là cách viết ngắn gọn của if/else.

Hãy xem đoạn code dài dòng, rẽ nhánh phức tạp như sau:

let title = 'Mr.';
if (person.gender === 'female') {
  if (!person.gotMarried) {
    title = 'Ms.';
  } else {
    title = 'Mrs.';
  }
}

Có thể được viết gọn lại thành:

const title =
  person.gender === 'female' ? (!person.gotMarried ? 'Ms.' : 'Mrs.') : 'Mr.';

Không còn if/else nữa.

Ta cũng vô hình trung loại bỏ được var, let vì không cần gán lại giá trị cho title.

Logical operators

Giả sử có đoạn code như sau:

const sayHello = () => {
  console.log('Hello, bonjour, nihao');
  return true;
};

const doNothing = () => {
  console.log('Do nothing');
  return false;
};

const greet = (hasClient) => {
  if (hasClient) {
    sayHello();
  } else {
    doNothing();
  }
};

greet(true); // => 'Hello, bonjour, nihao'
greet(false); //=> 'Do nothing'

Về mặt logic, hàm greet() kiểm tra điều kiện nếu có khách thì chào, nếu không thì không làm gì cả.

• expr1 && expr2 trả về expr1 nếu expr1 là falsy, ngoài ra nó trả về expr2.

Một điều thú vị ở đây là JavaScript engine luôn ước lượng giá trị biểu thức logic dạng này từ trái sang phải và theo nguyên tắc “đoản mạch” - short-circuit evaluation”. Tiên hữu nào giỏi Vật lý chắc còn nhớ hiện tượng “đoản mạch”, đó là khi dòng điện không chạy qua tải hoặc chỉ chạy qua một phần.

Vì AND chỉ trả về true nếu cả 2 mệnh đề cùng đúng, nên ngay khi bắt gặp expr1 sai, nó lập tức kết luận mệnh đề ghép là Sai và chấm dứt tại đó luôn, không chạy qua nửa bên phải expr2 nữa.

• expr1

  expr2 trả về expr1 nếu expr1 là truthy, ngoài ra nó trả về expr2.

Vì OR trả về true nếu ít nhất 1 mệnh đề đúng, nên ngay khi bắt gặp expr1 đúng, nó lập tức kết luận mệnh đề ghép là Đúng và bỏ qua expr2.

Short-circuit thần thánh!

Các lập trình viên kinh nghiệm thường lợi dụng đặc điểm này để tối ưu hiệu suất chương trình. Họ để các biểu thức tính toán phức tạp ở nửa sau của biểu thức logic. Như vậy, khi chưa rơi vào hoàn cảnh thích hợp, chúng sẽ bị bỏ qua, không cần tốn resource xử lý.

Tới đây, ta đã có thể viết lại hàm greet() một cách bí hiểm như sau:

const greet = (hasClient) => {
  return (hasClient || doNothing()) && sayHello();
};

Bắt đầu phần nằm trong ngoặc đơn bên trái &&. Nếu hasClient là true thì giá trị phần này cũng là true, doNothing() bị bỏ qua.

Vì phần bên trái của && là true nên cuối cùng, giá trị biểu thức quy về phần bên phải &&, tức là sayHello().

Lập luận tương tự cho trường hợp hasClient là false, dòng chảy chương trình lập tức rẽ sang doNothing(). Lúc này giá trị nửa bên trái && là false, do đó không cần quan tâm đến sayHello() nữa.

Viết như trên vừa độc vừa lạ, vừa khử được if/else, mà vẫn hoàn toàn ăn khớp với điều kiện quy ước.

Tuy nhiên, logical operators nếu nhìn không quen thì có vẻ hơi khó hình dung mạch suy diễn của chương trình. Tôi chỉ đưa ra đây để các tin hữu tham khảo. Trong dự án thực tế, vẫn nên dùng ternary cho đỡ hại não đồng đội:

const greet = (hasClient) => {
  return hasClient ? sayHello() : doNothing();
};

Logical functions

Một cách tiếp cận khác thể hiện tinh thần Functional Programming quyết liệt hơn, đó là tạo ra các hàm đặc trách nhiệm vụ xử lý logic. Ví dụ trong Ramda.js và Sanctuary đều có ifElse , unless , when, và hàng chục hàm logic khác.

Hàm greet nếu viết lại với Ramda sẽ trở nên xinh xắn như thế này:

const R = require('ramda');

const greet = R.ifElse(R.identity, sayHello, doNothing);

Đó là vẻ đẹp đầy tính nghệ thuật của Function Composition. Bạn cứ ngắm nhìn nó và đừng nói gì cả! Composition cũng có nghĩa là tác phẩm, như thơ của Paul Verlaine hay nhạc của Beethoven.

No new/this

Có 2 thứ luôn khiến Brendan Eich cảm thấy hài lòng khi kể về lịch sử JavaScript, đó là first-class function và prototype mechanism.

Ngày nay, hầu hết developer đều biết rằng thừa kế trong JavaScript là prototype-based inheritance. Nhưng ở thời kỳ web còn hoang sơ, người ta hay dùng new và các hàm constructors để lập trình OOP trong JavaScript theo kiểu class-based, giống như bên Java vẫn làm.

Classical inheritance

Cổ thư ghi lại rất nhiều ví dụ kiểu này:

function Dog(name) {
  this.name = name;
  this.say = function () {
    console.log('woof-woof, my name is ' + this.name);
  };
}

var rocky = new Dog('Rocky');
rocky.say();

var molly = new Dog('Molly');
molly.say();

Hàm Dog gọi là Function Constructor, các tiền bối chân giới Đại Việt thủa trước chuyển ngữ thành “hàm dựng”. Còn chúng ta thời nay có lẽ cứ nên giữ nguyên văn.

Prototypal inheritance

Sang đầu kỷ thứ 3, ở tông môn Yahoo! có một vị trưởng lão tu vi rất cao thâm tên là Douglas Crockford tung ra bộ kỳ thư “JavaScript: The Good Parts”, trong đó có đoạn nhấn mạnh bản chất prototype trong JavaScript, sự khác biệt giữa classical inheritance và prototypal inheritance. Ông cho rằng từ khóa new mang theo nhiều điểm bất cập, nên khuyến khích dùng Object.create để sao chép nguyên mẫu sang đối tượng kế thừa.

Tư tưởng của Douglas Crockford quả thực mới mẻ. Vào lúc đó, nhiều JavaScript engine còn chưa kịp hỗ trợ Object.create. Cuốn này vừa ra mắt đã gây náo loạn cả tin giới, trở thành sách gối đầu giường của rất nhiều tu sĩ.

Object.create cho phép sao chép các properties hoặc protoype của đối tượng. Hàm Dog có thể được viết lại theo hướng prototypal inheritance như thế này:

function Dog() {}

Dog.prototype.say = function () {
  console.log('woof-woof, my name is ' + this.name);
};

var rocky = Object.create(Dog.prototype);
rocky.name = 'Rocky';

var molly = Object.create(Dog.prototype);
molly.name = 'Molly';

rocky.say();
molly.say();

Không cần new nữa!

Các cường giả sau đó nhanh chóng phát triển thêm nhiều cách tiếp cận prototypal inheritance khác, nổi bật nhất phải kể đến Concatenative inheritance, Prototype delegation và Functional inheritance.

ES6 Class ngày nay chỉ vay mượn syntax của classical OOP để làm interface, còn bên trong nó chính là cơ chế prototypal inheritance.

Object Composition

Nhưng dù sao prototypal inheritance vẫn thuộc về OOP.

Người tu luyện Functional Programming không cần new.

Gần 10 năm sau bom tấn “The Good Parts”, Douglas Crockford lại một lần nữa khiến tin giới chấn động bằng “JavaScript: The Better Parts”. Thời điểm này, ông đã không còn dùng Object.create() nữa, cũng từ bỏ luôn this, for loops, for in, while… Tu vi của ông đã tiến thêm một bước lớn. Trong clip, ông nói về những tính năng mới của ES6 lúc ấy vẫn còn chưa chính thức xuất xưởng. Mấy lão quái kiệt này luôn đi trước thiên hạ vài năm.

const sayName = (state) => {
  return Object.assign(state, {
    say: () => {
      console.log(`woof-woof, my name is ${state.name}`);
    },
  });
};

const createDog = (name) => {
  let state = {
    name,
  };
  return Object.assign(state, sayName(state));
};

const rocky = createDog('Rocky');
rocky.say();
const molly = createDog('Molly');
molly.say();

Phong cách: Series này sử dụng phép ẩn dụ “tu tiên / võ hiệp” để kể chuyện lập trình. Đây là lựa chọn chủ đích của tác giả nhằm khiến các khái niệm khô khan trở nên sinh động hơn.

Như vậy, Functional Programming là nghệ thuật lập trình trong đó ta:

• sử dụng functions để điều khiển workflow
• tuân thủ 2 nguyên tắc immutability và purity

Nói cách khác, chư vị tin hữu muốn tu luyện Functional Programming thì phải giữ đạo tâm trong sáng, ý chí kiên định, hàng ngày chiêm nghiệm, suy diễn, cảm ngộ function, tu vi theo đó sẽ không ngừng thăng tiến.

Nhưng làm thế nào để cảm ngộ “phân sần ý cảnh”? Ta phải nắm bắt, quan sát, tư duy, suy tưởng về function ra sao? Sau đây là những pháp quyết nhập môn.

Higher-order function

Higher-order function là một khái niệm đến từ Toán học. Bất cứ hàm nào tiếp nhận 1 function như tham số, hoặc trả về 1 function như kết quả, thì đều được coi là higher-order function.

Dưới đây là 1 ví dụ, hàm getItem nhận vào hàm by mô tả điều kiện, lại trả về 1 hàm khác. Nó thừa tiêu chuẩn để gọi là higher-order function.

const getItem = (by) => (arr) => by;

// hoặc phiên bản chi tiết
const getItem = (by) => {
  return (arr) => {
    return by(arr);
  };
};

Lập trình phong cách Functional Programming là khiêu vũ với các functions.

Trong Functional Programming, hầu như mọi functions đều là higher-order function, vì chúng đều có thể nhận vào và ném ra các functions.

Nhưng như vậy thì có lợi ích gì? Nó đơn giản cung cấp cho ta một cách khác để lập luận và suy diễn. Chẳng hạn như với hàm getItem trên kia cho phép bạn biến hóa rất nhiều dạng, tùy vào cách bạn thao túng by.

Khi bạn viết getItem, bạn không cần biết sau này sẽ phải kiểm tra điều kiện ra sao, cũng không quan tâm sẽ nhận được đầu vào như thế nào.

Bạn có thể tạo ra hàm tìm số lớn nhất trong 1 mảng toàn số như sau:

// tạo hàm engine lấy max number từ mảng
const maxNumber = (arr) => {
  return Math.max(...arr);
};

// rồi truyền vào getItem để được hàm cần thiết
const getMaxNumber = getItem(maxNumber);

// thử xem sao
getMaxNumber([4, 6, 2, 3, 1, 8, 7, 5]);
// => 8

Thế sao không truyền thẳng cái mảng số kia vào maxNumber cho khỏe? Vì trong thiết kế này ta đang cư xử với maxNumber như plugin. Còn nhiều plugins khác nữa. Ta không gọi trực tiếp plugin mà gọi qua 1 giao diện tổng quát hơn.

Giờ ta lại có dữ liệu 1 nhóm người như sau:

const members = [
  {
    name: 'Alice',
    height: 165,
  },
  {
    name: 'Bob',
    height: 152,
  },
  {
    name: 'Celina',
    height: 178,
  },
  {
    name: 'Dan',
    height: 194,
  },
  {
    name: 'Eric',
    height: 187,
  },
];

Ta muốn tìm người cao nhất trong nhóm thì sao? Hãy thêm 1 plugin khác.

// bạn tạo 1 hàm engine lấy max height từ mảng
const maxHeight = (people) => {
  return people.reduce((prev, current) => {
    return prev.height > current.height ? prev : current;
  });
};

// rồi truyền vào getItem để được hàm cần thiết
const getTallestPerson = getItem(maxHeight);

// thử xem sao
getTallestPerson(members);
// => { name: 'Dan', height: 194 }

Ví dụ trên tuy tầm thường, nhưng có thể là gợi ý tốt để bạn dùng higher-order function thiết kế những chương trình linh hoạt, dễ mở rộng.

Function Composition

Đây là khái niệm Toán học mà tiếng Việt ta gọi là “hàm hợp”, hay “hàm phức hợp”. Mọi thứ trong Functional Programming đều có nguồn gốc Toán học.

Function Composition là sự phối hợp, liên kết nhiều hàm lại với nhau, thành một hàm lớn, nhiều chức năng hơn.

Có 2 kỹ thuật căn bản trong Function Composition là compose và pipe.

Compose

Hãy nhớ lại, trong không gian Functional Programming tồn tại vô số pure functions nhỏ gọn, đơn giản. Đúng triết lý “do one thing and do it well” của UNIX.

Vì mỗi hàm chỉ làm 1 việc, khi muốn thực hiện nhiều hành động lên cùng một input, ta chỉ việc kết hợp các hàm cần thiết lại với nhau.

Bây giờ chúng ta hãy tạm ngừng tu luyện, tạm quên tu vi để nhập phàm, quan sát và cảm ngộ nhân sinh.

Lần này, bạn hóa thành con trai thứ 4 trong gia đình một thôn dân sinh sống dưới chân núi Tản Viên bằng nghề bán thịt…

Một hôm bạn xin được khúc cây lớn ở chỗ ông chú làm kiểm lâm kiêm lâm tặc.

Từ khúc gỗ này, bạn muốn làm ra cái thớt cho nhà dùng.

Là tu sĩ mới nhập môn tu luyện Functional Programming, tuy không có tu vi, nhưng bạn vẫn hình dung được sẽ cần đến các pure functions sau:

• cưa(): nhận vào khúc gỗ, trả về từng khoanh tròn
• sấy(): nhận khoanh gỗ tươi, trả về khoanh gỗ khô
• bào(): nhận vào khoanh gỗ, trả về khoanh gỗ bằng phẳng
• khoan(): nhận vào khoanh gỗ, trả về khoanh gỗ có 2 lỗ (để gắn quai treo/móc lên cho gọn)
• chà(): nhận vào khoanh gỗ, trả về khoanh gỗ trơn láng (dùng giấy nhám, miền ngoài gọi giấy giáp, để đánh cho nhẵn bề mặt)
• móc(): nhận thớt không quai, trả về thớt có quai

Mỗi hàm chỉ làm đúng 1 việc. Không hơn. Không kém. Khi đi qua chừng đó công đoạn, ta sẽ được sản phẩm mong muốn.

Dĩ nhiên chúng ta đang muốn khúc gỗ được sửa đổi nên tạm bỏ qua vấn đề immutability.

Đây là phiên bản mô phỏng:

const cưa = (x) => {
  return `${x} đã cưa`;
};

const sấy = (x) => {
  return `${x} đã sấy`;
};

const bào = (x) => {
  return `${x} đã bào`;
};

const khoan = (x) => {
  return `${x} đã khoan`;
};

const chà = (x) => {
  return `${x} đã chà`;
};

const móc = (x) => {
  return `${x} đã gắn móc`;
};

Để tạo ra 1 cái thớt, ở thời viễn cổ xa xưa, các man sĩ thường code thế này:

var thớt = cưa('khúc gỗ');
thớt = sấy(thớt);
thớt = bào(thớt);
thớt = khoan(thớt);
thớt = chà(thớt);
thớt = móc(thớt);

console.log(thớt);
// => khúc gỗ đã cưa đã sấy đã bào đã khoan đã chà đã gắn móc

5 vạn năm sau, khi đã xuất hiện Toán học, các tộc nhân bộ lạc Giao Chỉ thời đại Hồng Bàng lại thích code như thế này:

var thớt = móc(chà(khoan(bào(sấy(cưa('khúc gỗ'))))));
console.log(thớt);
// => khúc gỗ đã cưa đã sấy đã bào đã khoan đã chà đã gắn móc

Đây chính là Toán học cơ bản. Với y = f(g(x)), ta tính g(x) trước, được bao nhiêu truyền vào f() là ra kết quả. Việc tính toán đi từ ngoặc trong cùng ra ngoài, mắt thường nhìn thấy là từ phải sang trái, từ g đến f.

Lại thêm 5 ngàn năm nữa trôi qua. Lúc này đã có ES6. Một số cường giả Functional Programming sáng tạo ra phương thức compose, như thế này:

const compose = (...fns) => {
  return fns.reduce((f, g) => (x) => f(g(x)));
};

Bạn có thể dùng Babel dịch sang ES2015 cho dễ hiểu.

Ý tưởng của compose là xếp cuốn chiếu các hàm lại với nhau, theo thứ tự từ trái sang phải để tạo ra một hàm mới, mà khi được thực thi, nó sẽ lần lượt gọi các hàm đã truyền vào trước đó theo thứ tự ngược lại, từ phải sang trái.

Tức là nếu y = compose(f, g), thì y(x) = f(g(x)); Nó sẽ tính g(x) trước rồi truyền kết quả cho f; Giả sử g(x) = z thì y(x) = f(z);

Nếu bạn vẫn thấy mơ hồ thì cứ xem cái này là Đạo. Chỉ có thể cảm ngộ, không thể giảng được bằng lời!

Trở lại với cái thớt. Hàm compose tất nhiên là higher-order function. Ta sẽ thử xem nó làm việc ra sao:

const quăng_cho_tao_cái_thớt = compose(móc, chà, khoan, bào, sấy, cưa);
console.log(quăng_cho_tao_cái_thớt.toString());
// => bạn đoán xem log ra thứ gì?

Bây giờ ta có 1 hàm, gọi là quăng_cho_tao_cái_thớt(), kết quả của sự lắp ghép bằng compose tất cả các pure functions ở trên.

Ta biết compose sẽ gọi từ phải sang trái, nên công đoạn nào làm trước thì để bên phải.

Chạy thử 1 phát:

const thớt = quăng_cho_tao_cái_thớt('khúc gỗ');
console.log(thớt);
// => khúc gỗ đã cưa đã sấy đã bào đã khoan đã chà đã gắn móc

Vậy là đủ công đoạn, khúc gỗ đã trở thành một cái thớt tốt.

Nhưng chưa hết. Khi bạn treo cái thớt đó ở nhà, nhiều người quen đến chơi thấy đẹp hỏi mua. Nhiều đến mức bạn quyết định kinh doanh thớt.

Làm thớt kinh doanh thì phải gán nhãn, vậy là bạn tạo ra một pure function mới và dùng compose để làm khuôn sản suất loại thớt commercial này.

Dễ ợt, không ảnh hưởng gì đến loại thớt cho nhà dùng.

const nhãn = (x) => {
  return `${x} đã dán nhãn`;
};

const làm_thớt_để_bán = compose(nhãn, móc, chà, khoan, bào, sấy, cưa);

Hoặc tận dụng lại khuôn mẫu cũ:

const làm_thớt_để_bán = compose(nhãn, quăng_cho_tao_cái_thớt);

Thử xem sao:

const thớt_bán = làm_thớt_để_bán('khúc gỗ');
console.log(thớt_bán);
// => khúc gỗ đã cưa đã sấy đã bào đã khoan đã chà đã móc đã dán nhãn

Để mở rộng thị phần, hướng đến phân khúc giá rẻ, bạn tạo ra dòng sản phẩm thớt tầm trung, dùng chip MediaTek, bỏ qua bước sấy khô và đánh bóng để giảm giá thành. Rất đơn giản:

const làm_thớt_loại_hai = compose(nhãn, móc, khoan, bào, cưa);

Thử xem sao:

const thớt_loại_hai = làm_thớt_loại_hai('khúc gỗ');
console.log(thớt_loại_hai);
// => khúc gỗ đã cưa đã bào đã khoan đã móc đã dán nhãn

Lập trình như vậy phải nói là vô cùng tao nhã, lịch thiệp! Đôi khi tôi cảm thấy phong cách lập trình Functional Programming có sự thanh tịnh đầy chất quý tộc, vừa bình dân lại vừa hàn lâm, đẹp đến mức khó hiểu!

Nếu dùng OOP, có thể chúng ta còn đang loay hoay giữa một đống class Máy Cưa, Máy Bào, Máy Khoan… Hoặc 1 class Máy Làm Thớt khổng lồ có đủ methods cưa, bào, khoan… Rồi còn một mớ properties mà ta phải cân nhắc xem cái nào public, cái nào private. Rồi phải tạo instance, thừa kế qua lại mấy vòng may ra mới làm được cái thớt. Muốn thêm dòng sản phẩm lại càng khó khăn. Phải tạo class Thớtnhà_dùng, extend ra Thớtđểbán, Thớtđể_bán_loại_2, phiền phức không sao kể xiết!

Functional Programming thì chỉ cần mấy hàm đơn giản, rời rạc, dùng compose lắp ráp lại như lắp ráp dây chuyền công nghệ là chế được các kiểu thớt.

Function Composition tựa như một nhà máy hiện đại, mỗi chi tiết linh kiện được xử lý bằng một robot chuyên trách, kết hợp lại với nhau một cách khoa học để tạo ra sản phẩm hoàn thiện.

Pipe

Một biến thể của compose là pipe, vận hành theo chiều ngược lại. Ta có thể implement bằng cách đảo vị trí f và g thế này:

const pipe = (...fns) => {
  return fns.reduce((f, g) => (x) => g(f(x)));
};

Hoặc giữ nguyên code của compose nhưng thay reduce bằng reduceRight:

const pipe = (...fns) => {
  return fns.reduceRight((f, g) => (x) => f(g(x)));
};

Vì pipe tổ hợp các hàm theo chiều ngược lại so với compose nên ta viết:

const làm_thớt_dỏm = pipe(cưa, bào, nhãn);

Thử xem sao:

const thớt_dỏm = làm_thớt_dỏm('khúc gỗ');
console.log(thớt_dỏm);
// => khúc gỗ đã cưa đã bào đã dán nhãn

Dùng pipe có vẻ thuận mắt hơn. Thứ tự các bước cưa, bào… trông khá tự nhiên. Nếu bạn quen với cách suy luận Toán học thì bạn sẽ thích compose. Còn nếu bạn muốn trực quan dễ hiểu thì cứ dùng pipe.

compose và pipe là những thuật pháp nhập môn dễ học, dễ dùng, nhưng không kém uy lực, thư viện Functional Programming nào cũng có. Trong Ramda.js, ngoài compose và pipe, các tác giả còn bổ sung thêm pipeK, pipeP, composeK, composeP.

Khi đã thông thạo, bạn hoàn toàn có thể tạo ra compose theo cách của bạn. Ví dụ composeBinary liên kết các hàm từ giữa sang 2 bên thay vì từ đầu này đến đầu kia, composeRandom liên kết các hàm không theo trật tự cố định… Đó là không gian sáng tạo thuộc về riêng bạn.

Currying function

Thuật ngữ currying và các dạng curry, curried của nó trong khoa học máy tính được Christopher Strachey đặt ra từ năm 1967 để ghi nhớ công lao của Haskell Brooks Curry, một nhà Toán học và Luận lý học người Mỹ.

Currying function là làm cho 1 function trở thành “curried function”.

Cái function ban đầu đó hơi ngốc nghếch, nó cần bạn truyền vào N tham số để tính toán, mà nếu thiếu 1 tham số, nó sẽ không chạy.

Ví dụ hàm sum thế này:

const sum = (a, b, c) => {
  return a + b + c;
};

sum cần 3 tham số để cộng dồn lại, nếu thiếu, sẽ không tính toán ra được.

// có thể ra sân
sum(5, 3, 2); // => 10
sum(4, 4, 2); // => 10
sum(4, 3, 3); // => 10
sum(3, 5, 2); // => 10

// nhưng
sum(4, 5); // => NaN

Đây là thiếu tiền đạo cả đội không chịu ra sân tập! Nhưng cuộc sống đâu phải lúc nào cũng thuận lợi, đầy đủ cho chúng ta? Dù cả mấy tiền đạo đều bị chấn thương, treo giò, trốn tập thì các anh còn lại vẫn phải có trách nhiệm ra sân chứ!

Currying chính là kỹ thuật biến hàm sum ngốc đó trở thành một function vi diệu hơn, nếu bạn gọi nó với 1 tham số, nó sẽ trả về 1 hàm tạm thời, giữ lại tham số đó, chờ khi nào đủ 3 tham số thì mới thực hiện tính toán.

Hình dung bạn tổ chức một buổi party, mời 3 người bạn tham gia. Lúc này đã có mặt 2 người, còn 1 người đến muộn. Bạn quyết định không cần chờ nữa. Bữa tiệc cứ bắt đầu đã, chừng nào người kia đến thì tính tiếp.

Đây là 1 cách implement cho hàm curry:

const curry = (fn) => {
  let totalArguments = fn.length;
  let next = (argumentLength, rest) => {
    if (argumentLength > 0) {
      return (...args) => {
        return next(argumentLength - args.length, [...rest, ...args]);
      };
    }
    return fn(...rest);
  };
  return next(totalArguments, []);
};

Và curry tất nhiên cũng là higher-order function.

Thử dùng với sum xem sao:

const curriedSum = curry(sum);

curriedSum bây giờ là phiên bản curried của hàm sum trước đó.

curriedSum(4, 4, 2); // => 10
curriedSum(4, 3, 3); // => 10
curriedSum(3, 5, 2); // => 10

// và
curriedSum(5, 3); // => [Function]

curriedSum(5, 3) là 1 function. Nó đang chờ đợi tham số cuối cùng xuất hiện. Nếu bây giờ ta gọi nó với 1 tham số thì kết quả sẽ được tính toán ra:

curriedSum(5, 3)(2); // => 10

Nếu ta truyền nhiều hơn số lượng tham số còn thiếu thì sao? Ở đây là 1 tham số cuối cùng. Theo cách implement trên thì nó sẽ bỏ qua các tham số dư thừa. Các phiên bản curry của Ramda.js và Lodash FP cũng hành xử như vậy.

curriedSum(5, 3)(2, 4, 8); // => 10

Một điểm quan trọng nữa là ta có thể phân tách hàm gốc ra từ 1 đến N phần, với N là số lượng tham số của hàm gốc đó. Chẳng hạn, nếu hàm gốc có 3 tham số, ta có thể chia nó ra 1, 2 hoặc 3 phần. Những cách viết sau là tương đương:

curriedSum(3, 5, 2);
curriedSum(3, 5)(2);
curriedSum(3)(5, 2);
curriedSum(3)(5)(2);

curry, cũng như compose và pipe là những kỹ thuật căn bản, ai cũng phải học, phải biết. Mọi ngôn ngữ được thiết kế với tư tưởng Functional Programming như Haskell, Scala, Elm… đều có sẵn các hàm này. Chúng rất tinh tế và được dùng ở khắp nơi.

Chỉ cần thành thạo 3 pháp quyết này thì bạn đã được xem như đệ tử Functional Programming chân chính.

Phong cách: Series này sử dụng phép ẩn dụ “tu tiên / võ hiệp” để kể chuyện lập trình. Đây là lựa chọn chủ đích của tác giả nhằm khiến các khái niệm khô khan trở nên sinh động hơn. Nếu bạn chưa quen, hãy kiên nhẫn — nội dung kỹ thuật vẫn chính xác và đầy đủ.

Lúc bấy giờ, Tin giới Tây phương xuất hiện 2 lão quái Nguyên Anh hậu kỳ đỉnh phong, chỉ thiếu nửa bước cảm ngộ ý cảnh là đột phá tới cảnh giới Hóa Thần. Một người là Đồ Linh tôn giả - tức Alan Turing, nổi danh với pháp môn Turing Machine. Người kia là Khâu Kỳ thượng tiên, Alonzo Church, tung hoành tam giới bằng đạo thuật Lambda Calculus (1).

Turing Machine của Alan Turing và Lambda Calculus của Alonzo Church thực ra là hai cách tiếp cận nguyên lý xử lý tính toán trong computer, thường được giới chuyên môn gọi chung là Luận đề Church - Turing (The Church-Turing Thesis).

Turing Machine đặt cơ sở trên việc nắm giữ state machine và trạng thái tiến trình, còn ý tưởng Lambda Calculus được xây dựng trên các tính chất của hàm toán học. Lấy tu vi của bổn tiên hiện giờ thì chưa lĩnh hội được mấy thứ cao siêu như vậy, nên không dám lạm bàn ở đây. Chỉ biết rằng, 2 thuật pháp kể trên là khởi nguồn của 2 trường phái tu luyện mạnh nhất trong tin giới hiện nay: Object Oriented Programming và Functional Programming.

Có khá nhiều cơ chế lập trình - Programming Paradigm. OOP và Functional Programming chỉ là 2 trong số đó. Trong cuốn “Programming Paradigms for Dummies: What Every Programmer Should Know”, tác giả Peter Van Roy đưa ra mô hình tổng hợp quan hệ giữa các cơ chế lập trình như thế này:

Trong lịch sử công nghệ, có vẻ OOP chiếm ưu thế hơn so với Functional Programming. Bạn cứ thử nhìn xung quanh mình là biết, từ thời tập tành code đã thấy thiên địa tràn ngập quy tắc OOP rồi. Các job description, các buổi interview đều nhắc đến OOP như pháp thuật căn bản. Thảo luận kỹ thuật hầu hết xoay quanh mấy khái niệm Class, Object, Inheritance, rồi cao hơn thì SOLID, Polymorphism, Encapsulation…

Nhưng, trên thế giới, từ thời Lisp đến FP, rồi Haskell, Elixir, chưa bao giờ thiếu vắng những tu tin giả đi theo con đường Functional Programming. Nhất là khoảng sau 2010, không rõ vì sao người ta bắt đầu phàn nàn nhiều hơn về OOP, trích dẫn nhiều hơn luận điểm banana/gorilla của Joe Armstrong (2), theo đó, chủ đề “Functional Programming” bắt đầu nóng dần trở lại.

Tôi biết đến Functional Programming vào khoảng 2015 qua một talk show trên YouTube của “chú Bob”, nhưng không hiểu lắm nên cũng không chú ý.

Phải sang 2016, tôi mới chính thức tìm hiểu sâu về Functional Programming sau khi đọc 2 loạt bài viết “Composing Software” của Eric Elliott và “So You Want to be a Functional Programmer” của Charles Scalfani trên Medium.

Eric Elliott lần lượt giải thích từng concepts của Functional Programming một cách tường tận, dễ hiểu. Còn Charles Scalfani đúng là fan cuồng Functional Programming. Anh trình bày nó dưới dạng một hệ thống triết lý, thế giới quan đặc sắc. Thậm chí, Scalfani còn đề cao Functional Programming như nấc thang tiến hóa trong lịch sử lập trình. Lối viết của anh gây ấn tượng cực mạnh.

Trước đó, Scalfani còn có bài “Goodbye, Object Oriented Programming” gây tranh luận sôi nổi.

Nhưng bạn đọc nên lưu ý, Functional Programming không bài xích OOP. Chúng chỉ là những con đường tu luyện khác nhau, cùng hướng về Đại Đạo. Trong khi viết code, ta hoàn toàn có thể phối hợp nhiều cơ chế lập trình khác nhau, miễn sao đạt đến kết quả Đúng - Nhanh - Ổn - Đẹp.

ReactJS là một ví dụ tiêu biểu, có thể coi nó như 7 phần Functional Programming + 3 phần OOP. Về điểm này, Anjana Vakil có một bài thuyết trình rất hay ở GOTO 2017.

var x = 5;
var y = 2;
while (x < 10) {
  y += x;
  x++;
}

const updateView = (html) => {
  let $view = document.getElementById('panel');
  $view.innerHTML = html;
  localStorage.setItem('panelCache', html);
  return $view;
};

const getDuration = (timestamp) => {
  return Date.now() - timestamp;
};

const add = (a, b) => {
  return a + b;
};