Bắt đầu

Bạn đã hiểu RxJS dùng để mô tả dữ liệu thay đổi theo thời gian, nhưng từ mental model đến một pipeline chạy được vẫn còn vài mảnh ghép: cài package thế nào, subscribe ở đâu, đọc timeline ra sao và nhìn vào đâu khi output không đúng.

Nhóm Bắt đầu nối các mảnh đó bằng một vòng học ngắn: thiết lập môi trường, đọc stream, chạy stream rồi quan sát lifecycle của nó. Đích đến không phải là thuộc nhiều operator; bạn cần tự viết và giải thích được một pipeline nhỏ trước khi sang phần chuyên sâu.

Mục lụcCopy Anchor Link

• Sau nhóm này bạn làm được gì
• Nhìn trước một pipeline hoàn chỉnh
  • Code TypeScript
  • Đọc pipeline theo luồng dữ liệu
• Bản đồ năm bài bắt đầu
• Cách học nhóm này
  • Nếu đây là pipeline đầu tiên của bạn
  • Nếu bạn đã từng dùng RxJS
• Checklist hoàn thành
• Những bẫy nên tránh ngay từ đầu
• Đi tiếp sau nhóm Bắt đầu
• Nguồn tham khảo

Sau nhóm này bạn làm được gìCopy Anchor Link

Kết thúc năm bài, bạn nên có thể tự làm những việc sau mà không cần sao chép nguyên một snippet có sẵn:

• cài rxjs vào project TypeScript và kiểm tra import hoạt động;
• nhận ra source, operator, Observable đầu ra và Observer trong một pipeline;
• đọc được next, error, complete cùng chiều thời gian trên marble diagram;
• dùng pipe() để ghép các phép biến đổi mà không sửa source Observable;
• subscribe bằng một Observer có chủ đích, rồi xác định khi nào execution kết thúc;
• dùng log hoặc tap để quan sát pipeline mà không biến debug thành logic nghiệp vụ.

Đây là chuẩn đầu ra thực dụng hơn việc nhớ tên operator. Khi một stream cho kết quả sai, sáu kỹ năng trên giúp bạn khoanh vùng vấn đề trước khi thêm operator mới.

Nhìn trước một pipeline hoàn chỉnhCopy Anchor Link

Ví dụ dưới đây là hình dạng bạn sẽ gặp xuyên suốt nhóm này. Source phát bốn số, filter giữ số chẵn, map đổi chúng thành nhãn, còn Observer nhận các notification cuối pipeline.

Code TypeScriptCopy Anchor Link

import { filter, map, of } from 'rxjs';

const source$ = of(1, 2, 3, 4);

const labels$ = source$.pipe(
  filter((value) => value % 2 === 0),
  map((value) => `item-${value}`),
);

labels$.subscribe({
  next: (value) => console.log('next:', value),
  error: (error: unknown) => console.error('error:', error),
  complete: () => console.log('complete'),
});

Kết quả:

next: item-2
next: item-4
complete

of() phát các giá trị này đồng bộ rồi complete. Observable không mặc định là “tác vụ chạy nền”; timing phụ thuộc source và scheduler được dùng.

Đọc pipeline theo luồng dữ liệuCopy Anchor Link

source$       (1) ── (2) ── (3) ── (4) ── complete
                       │               │
filter số chẵn         (2)             (4)
                       │               │
map thành nhãn     "item-2"        "item-4"
                       │               │
Observer          next(value)      next(value) ── complete

Có thể đọc ví dụ theo bốn bước:

1. of(1, 2, 3, 4) tạo source Observable. Chưa có execution nào chạy ở thời điểm khai báo.
2. pipe(...) trả về labels$, một Observable mới; nó không sửa source$.
3. subscribe(...) bắt đầu execution, nên source mới phát dữ liệu qua từng operator.
4. Source complete sau 4; completion đi qua pipeline và gọi callback complete của Observer.

Hãy tách định nghĩa pipeline khỏi thời điểm chạy pipeline. Đây là khác biệt nhỏ trên code nhưng rất quan trọng khi bạn gặp nhiều subscription, HTTP request hoặc event stream sống lâu.

Bản đồ năm bài bắt đầuCopy Anchor Link

Mỗi bài thêm một kỹ năng vào cùng pipeline, nên thứ tự dưới đây có chủ đích:

Nếu một bài chi tiết vẫn đang được bổ sung, bạn có thể dùng ví dụ trên làm bài thực hành tối thiểu: chạy nó, dự đoán output trước, rồi thay đổi từng phần và giải thích kết quả.

Cách học nhóm nàyCopy Anchor Link

Nếu đây là pipeline đầu tiên của bạnCopy Anchor Link

Đi theo thứ tự trong bảng. Sau bài cài đặt, giữ một file playground duy nhất và sửa nó qua từng bài; như vậy bạn quan sát được kiến thức mới thay đổi cùng một execution ra sao, thay vì mỗi lần lại bắt đầu bằng một ví dụ không liên quan.

Sau mỗi thay đổi, làm ba việc: viết output dự đoán, chạy code, rồi giải thích điểm khác nhau. Nếu chỉ chạy đến khi “thấy đúng”, bạn dễ bỏ qua lý do stream complete, error hoặc còn mở.

Nếu bạn đã từng dùng RxJSCopy Anchor Link

Hãy bắt đầu ở chỗ thường làm bạn phải đoán. Nếu code chạy nhưng timeline khó hiểu, đọc Marble diagram. Nếu bạn hay viết subscribe(value => ...) rồi quên error và cleanup, chuyển thẳng đến Subscribe và Observer. Nếu pipeline chỉ khó khi debug, dùng bài playground như checklist quan sát.

Dù đã có kinh nghiệm, hãy chạy lại ví dụ tối thiểu một lần trong chính môi trường của project. Nó tách lỗi setup khỏi lỗi tư duy pipeline, nên bạn không phải debug hai vấn đề cùng lúc.

Checklist hoàn thànhCopy Anchor Link

Đừng đánh dấu nhóm này là xong chỉ vì code đã in ra hai dòng. Hãy tự kiểm tra:

• Tôi chỉ ra được source, từng operator, output Observable và Observer trong ví dụ.
• Tôi giải thích được vì sao 1 và 3 không tới Observer.
• Tôi biết chính xác lời gọi nào bắt đầu execution.
• Tôi phân biệt được complete, error và consumer gọi unsubscribe().
• Tôi có thể vẽ timeline của ví dụ bằng ký hiệu marble đơn giản.
• Tôi biết chèn tap ở đâu để quan sát trước và sau một operator.
• Tôi chạy được ví dụ trong playground mà không cần sửa import theo kiểu nội bộ của package.

Nếu còn vướng một mục, quay lại bài tương ứng trong bảng. Không cần học thêm operator cho đến khi vòng đời của pipeline nhỏ này đã rõ.

Những bẫy nên tránh ngay từ đầuCopy Anchor Link

• Cho rằng tạo Observable là chạy ngay. Nhiều Observable là lazy; ví dụ trên chỉ thực thi khi có subscribe().
• Cho rằng mọi Observable đều bất đồng bộ. of() có thể phát và complete ngay trong cùng call stack. Đừng suy timing chỉ từ kiểu Observable.
• Nhét business logic vào subscribe. Subscriber nên là boundary nhận kết quả hoặc tạo side effect. Phép biến đổi dữ liệu thường dễ đọc, tái sử dụng và test hơn khi nằm trong pipe().
• Dùng tap để thay đổi dữ liệu. tap phù hợp để log hoặc quan sát side effect; dùng map khi output cần giá trị mới.
• Chỉ viết callback next rồi quên đường kết thúc. Một demo ngắn có thể ổn, nhưng code thật cần quyết định rõ error đi đâu và tài nguyên được dọn lúc nào.
• Subscribe lồng nhau để nối hai tác vụ. Cách này sớm làm error handling và teardown bị chia đôi. Khi sang higher-order Observable, hãy chọn flattening operator theo concurrency policy thay vì nested subscribe.

Đi tiếp sau nhóm Bắt đầuCopy Anchor Link

Sau khi hoàn thành checklist, bước hợp lý nhất là đi sâu vào cách Observable tạo execution và cách Subscription dọn tài nguyên. Nếu mental model về lifecycle vẫn chưa chắc, ôn phần nền tảng trước khi học thêm operator.

Nguồn tham khảoCopy Anchor Link

• RxJS — Introduction — vai trò của Observable, Observer, Subscription và operators trong thư viện.
• RxJS — Observable — tính lazy của execution, notification contract và teardown.
• RxJS — Operators — cách pipeable operator nhận một Observable và trả về Observable mới mà không sửa source.
• RxJS — Observer — ba callback next, error, complete và partial Observer.
• RxJS — Subscription — unsubscribe() và việc giải phóng tài nguyên của execution.
• RxJS 7.x — tài liệu trong repository — nguồn versioned cho các guide và ví dụ chính thức.