State Class trong React: Tại Sao AI "Thích" Pattern Này Hơn Hooks?

AI "nghĩ" như thế nào khi tạo React code?

Nếu bạn đã dùng Cursor hay Claude Code để generate React components, bạn sẽ nhận ra một pattern khá thú vị: AI thường viết code tốt hơn, ít bug hơn khi state được tổ chức theo kiểu class-based thay vì rải rác qua nhiều useState hooks.

Điều này nghe có vẻ ngược với trend hiện tại — hooks đã "giết" class components từ React 16.8. Nhưng khi làm việc với AI assistant, tôi nhận ra rằng class-based state management (không phải class components, mà là Zustand/MobX stores dạng class hoặc plain JavaScript classes) cho AI context tốt hơn nhiều.

Vấn đề với useState khi dùng AI

Trước khi dùng AI, tôi viết component kiểu này — và nó hoàn toàn ổn:

// Trước khi dùng AI: useState rải rác
function ProductForm() {
  const [name, setName] = useState('');
  const [price, setPrice] = useState(0);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const [validation, setValidation] = useState({});

  const handleSubmit = async () => {
    setLoading(true);
    try {
      await submitProduct({ name, price });
    } catch (err) {
      setError(err.message);
    } finally {
      setLoading(false);
    }
  };
}

Khi tôi ask AI "thêm validation cho trường price", AI thường:

• Quên mất setValidation ở trên cùng
• Thêm state mới thay vì dùng state đã có
• Tạo ra inconsistency giữa các state updates

Kết quả: cần sửa 2–3 vòng mới chạy đúng. Đây không phải lỗi của AI — đây là vấn đề về context structure.

Class-based Store: Structured Context cho AI

Với class-based approach kết hợp Zustand + immer:

// Với AI assistant: Class-based store
class ProductFormStore {
  name = '';
  price = 0;
  loading = false;
  error: string | null = null;
  validation: Record<string, string> = {};

  validate() {
    this.validation = {};
    if (!this.name) this.validation.name = 'Tên không được để trống';
    if (this.price <= 0) this.validation.price = 'Giá phải lớn hơn 0';
    return Object.keys(this.validation).length === 0;
  }

  async submit() {
    if (!this.validate()) return;
    this.loading = true;
    this.error = null;
    try {
      await submitProduct({ name: this.name, price: this.price });
    } catch (err: any) {
      this.error = err.message;
    } finally {
      this.loading = false;
    }
  }
}

// Khởi tạo với Zustand + immer
const useProductForm = create(
  immer(() => new ProductFormStore())
);

Bây giờ khi tôi ask AI "thêm validation cho price", AI biết chính xác nơi cần edit vì mọi thứ đều trong một class với clear boundaries. Không cần scan toàn bộ component.

Tại sao AI "thích" pattern này?

Từ kinh nghiệm dùng Cursor và Claude Code hàng ngày, tôi nhận thấy AI xử lý tốt hơn khi:

• State tập trung một chỗ: AI không cần scan toàn bộ component để tìm state liên quan
• Methods rõ ràng: AI biết validate(), submit(), reset() là gì và chúng làm gì
• TypeScript types được define rõ: Class properties có types → AI tạo ra correct types khi extend
• Side effects isolated: API calls nằm trong store, không rải khắp component tree

Kết quả thực tế

Tôi đã refactor một admin dashboard từ 23 useState hooks thành 4 class-based stores với Zustand. Sau đó test với Claude Code bằng cách yêu cầu "thêm bulk delete feature".

Với useState cũ: AI generate được nhưng miss 3 state updates, cần sửa 2 lần nữa mới chạy đúng.

Với class store: AI generate một lần, chạy đúng ngay. Thêm method bulkDelete() vào store, update UI component để gọi store.

Khi nào nên dùng?

• Forms phức tạp với nhiều fields và validation rules
• Feature modules với nhiều state liên quan nhau (ví dụ: shopping cart, multi-step wizard)
• Khi bạn expect AI sẽ frequently modify state logic
• Team codebase — class structure dễ onboard hơn cho cả người và AI

Không phải class stores tốt hơn hooks về mặt React thuần. Mà là chúng tốt hơn cho AI-assisted development vì chúng cung cấp structured context mà AI cần để generate correct code lần đầu tiên.

Hãy thử refactor một form phức tạp sang class-based store rồi dùng AI để add feature. Sự khác biệt sẽ rõ ngay.