thảo luận Mấy Framework FE như kiểu Angular, ReactJS làm cho coder rất khổ khi debug

Giả sử các thím code Back end Java gì đó khi đọc code từ trên xuống dưới, ví dụ từ dòng 1 tới dòng 10 các thím sẽ hiểu được chính xác logic và flow của code như thế nào. Kiểu làm việc 1 => làm việc 2 => làm việc 3

Nhưng các Framework front end rất hay có trò kiểu như detect change (Khi có 1 cái gì đó thay đổi thì sẽ render / hoặc chạy lại toàn bộ component)

Ví dụ:
  • Khi state của 1 component trong reactjs thay đổi => component sẽ được render (Toàn bộ các đoạn code component sẽ được chạy lại)
  • Angular cũng tương tự, 1 props nào đó thay đổi thì component cx render lại

Không chỉ vậy việc render lại hay không còn phụ thuộc rất nhiều yếu tố a b c x y z (Ví dụ như dependency array của reactjs sẽ có thể thay đổi hành vi render)

=> Dẫn tới việc các thím mở code lên đọc từ trên xuống dưới của FE sẽ đếch hình dung được chắc chắn 100% luồng code sẽ chạy như nào, khi nào thì luồng nào chạy, và các component con còn nhiều khi ảnh hưởng tới component cha và ngược lại

Tóm gọn lại: Cực kì khó xác định logic flow code + xác định chính xác tất cả các case mà component re-render => Khó debug cực kì

//Ví dụ 2


Để tôi ví dụ cho anh

JavaScript:
function A(props) {
    //logic 1 2 3 4
    
    const { data } = useFetch(url) //Chú ý dòng này
}

Giả sử tôi có 1 component như trên có logic 1 2 3 4. Và ở dòng cuối tôi có gọi 1 customer hook tên là 'useFetch' => Nếu trong cái hook 'useFetch' của tôi có gọi hàm setState => Re-render và như thế logic 1 2 3 4 sẽ chạy lại đúng ko???

Nhưng mà code be tôi gặp gần như ko bao giờ có trường hợp đã gọi tới dòng dưới rồi, mà lại có cách thần kì nào mấy dòng trên lại chạy lai từ đầu cả.

Anh công nhận với tôi ko?
 
Last edited:
Giả sử các thím code Back end Java gì đó khi đọc code từ trên xuống dưới, ví dụ từ dòng 1 tới dòng 10 các thím sẽ hiểu được chính xác logic và flow của code như thế nào. Kiểu làm việc 1 => làm việc 2 => làm việc 3

Nhưng các Framework front end rất hay có trò kiểu như detect change (Khi có 1 cái gì đó thay đổi thì sẽ render / hoặc chạy lại toàn bộ component)

Ví dụ:
  • Khi state của 1 component trong reactjs thay đổi => component sẽ được render (Toàn bộ các đoạn code component sẽ được chạy lại)
  • Angular cũng tương tự, 1 props nào đó thay đổi thì component cx render lại

Không chỉ vậy việc render lại hay không còn phụ thuộc rất nhiều yếu tố a b c x y z (Ví dụ như dependency array của reactjs sẽ có thể thay đổi hành vi render)

=> Dẫn tới việc các thím mở code lên đọc từ trên xuống dưới của FE sẽ đếch hình dung được chắc chắn 100% luồng code sẽ chạy như nào, khi nào thì luồng nào chạy, và các component con còn nhiều khi ảnh hưởng tới component cha và ngược lại

Tóm gọn lại: Cực kì khó xác định logic flow code + xác định chính xác tất cả các case mà component re-render => Khó debug cực kì
Vậy fen biết cost để duyệt DOM sẽ thế nào nếu fence ko biết chỗ nào cần re-render hông :go:
Việc fence ko hiểu luồng của một app có thể là do codebase từ trước ko hợp lý chứ nếu như docs của React khuyên thì đọc vô cái là hiểu ngay

via theNEXTvoz for iPhone
 
Vậy fen biết cost để duyệt DOM sẽ thế nào nếu fence ko biết chỗ nào cần re-render hông :go:
Việc fence ko hiểu luồng của một app có thể là do codebase từ trước ko hợp lý chứ nếu như docs của React khuyên thì đọc vô cái là hiểu ngay

via theNEXTvoz for iPhone
đúng là code-base ko hợp lý sẽ gây khó hiểu NHƯNG

cứ cho 1 cái code base của java đi, cho dù nó có ko hợp lý thì nó chỉ khó đọc thôi chứ nhìn line-by-line vẫn xác định được flow.

Đây fen đọc code reactjs fen sẽ rất tốn não suy luận chứ k chỉ nhìn line-by-line
 
Tại sao hàng triệu thằng frontend dev khác trên thế giới này làm đc mà bạn làm k đc? => lỗi k phải do fw, lỗi là bạn gà

Gửi từ Sony G3416 bằng vozFApp
 
vậy do a chưa hiểu cách framework nó hoạt động chứ liên quan gì tới nó


via theNEXTvoz for iPhone
Để tôi ví dụ cho anh

JavaScript:
function A(props) {
    //logic 1 2 3 4
    
    const { data } = useFetch(url) //Chú ý dòng này
}

Giả sử tôi có 1 component như trên có logic 1 2 3 4. Và ở dòng cuối tôi có gọi 1 customer hook tên là 'useFetch' => Nếu trong cái hook 'useFetch' của tôi có gọi hàm setState => Re-render và như thế logic 1 2 3 4 sẽ chạy lại đúng ko???

Nhưng mà code be tôi gặp gần như ko bao giờ có trường hợp đã gọi tới dòng dưới rồi, mà lại có cách thần kì nào mấy dòng trên lại chạy lai từ đầu cả.

Anh công nhận với tôi ko?
 
Để tôi ví dụ cho anh

JavaScript:
function A(props) {
    //logic 1 2 3 4
    
    const { data } = useFetch(url) //Chú ý dòng này
}

Giả sử tôi có 1 component như trên có logic 1 2 3 4. Và ở dòng cuối tôi có gọi 1 customer hook tên là 'useFetch' => Nếu trong cái hook 'useFetch' của tôi có gọi hàm setState => Re-render và như thế logic 1 2 3 4 sẽ chạy lại đúng ko???

Nhưng mà code be tôi gặp gần như ko bao giờ có trường hợp đã gọi tới dòng dưới rồi, mà lại có cách thần kì nào mấy dòng trên lại chạy lai từ đầu cả.

Anh công nhận với tôi ko?
Do a ko hiểu bản chất của React tôi nói thật
việc thằng 1 2 3 4 tạo lại là do bản thân thằng Functional Component là một hàm render, việc a setSate sẽ trigger re-render làm cho thằng state có giá trị mới nhưng nếu ko tạo lại 1 2 3 4 thì nó sẽ ko đọc đc vì một cái gọi là closure.
:go: Còn muốn nó ko tạo lại thì có cả tá API react cung cấp để làm việc này

via theNEXTvoz for iPhone
 
Do a ko hiểu bản chất của React tôi nói thật
việc thằng 1 2 3 4 tạo lại là do bản thân thằng Functional Component là một hàm render, việc a setSate sẽ trigger re-render làm cho thằng state có giá trị mới nhưng nếu ko tạo lại 1 2 3 4 thì nó sẽ ko đọc đc vì một cái gọi là closure.
:go: Còn muốn nó ko tạo lại thì có cả tá API react cung cấp để làm việc này

via theNEXTvoz for iPhone
Thế anh công nhận với tôi nếu nhìn bằng mắt thường đọc code line by line phải phân tích như a vừa nói mới thấy đc luồng code ko ?

Còn anh code be kbh anh gặp case này

Ý tôi muốn nói là khi code be anh sẽ kbh phải phân tích: "dòng code x này có gây ra việc chạy lại từ đầu 1 dòng code nào đã chạy trong cùng 1 hàm ko"
 
Thế anh công nhận với tôi nếu nhìn bằng mắt thường đọc code line by line phải phân tích như a vừa nói mới thấy đc luồng code ko ?

Còn anh code be kbh anh gặp case này
chả liên quan, hai cái hoàn toàn khác nhau phục vụ cho những mục đích khác nhau
Anh có thể xài native DOM api để code chả ai ý kiến gì, hoặc tạo ra 1 tạo ra một framework library riêng mà straightforward nhất có thể để xài
r xem cái nào nó sẽ hiệu quả hơn

via theNEXTvoz for iPhone
 
chả liên quan, hai cái hoàn toàn khác nhau phục vụ cho những mục đích khác nhau
Anh có thể xài native DOM api để code chả ai ý kiến gì, hoặc tạo ra 1 tạo ra một framework library riêng mà straightforward nhất có thể để xài
r xem cái nào nó sẽ hiệu quả hơn

via theNEXTvoz for iPhone
Thì đó cái point tôi chỉ ra là khi đọc code fe sẽ phải suy luận chứ đ thể nào mà straight foward đc :D chứ tôi có bảo tôi tạo ra đc 1 fw xịn hơn đâu
 
Tôi ko hiểu logic 1 2 3 4 của anh là cái gì? Cụ thể hơn được không?
T code front end thì hầu như làm việc với state, state thay đổi thì dĩ nhiên nó re render lại anh ý kiến wtf gì t ko hiểu
ZJqL4rW.png


via theNEXTvoz for iPhone
Logic 1 2 3 4 là hàm gì đó hoặc làm gì đó trong component chẳng hạn
 
Vậy fen biết cost để duyệt DOM sẽ thế nào nếu fence ko biết chỗ nào cần re-render hông :go:
Việc fence ko hiểu luồng của một app có thể là do codebase từ trước ko hợp lý chứ nếu như docs của React khuyên thì đọc vô cái là hiểu ngay

via theNEXTvoz for iPhone
Thực ra DOM nhanh hơn, còn bọn framework kia giúp bạn quản lý lifecycle dễ dàng hơn

Logic 1 2 3 4 là hàm gì đó hoặc làm gì đó trong component chẳng hạn
Logic của thím là gì. React, vue đều có hàm để tránh các trường hợp này. Còn bảo đọc khó hiểu là bởi thím ko hiểu nó.
 
Do thớt chưa hiểu concept của bọn fw trên nên thấy nó khó hiểu ấy chứ.
Hầu hết đều có concept chung là: UI = f(state) tương tự như hàm y = f(x) là hiểu. Hàm f không đổi, nhưng muốn có được y (UI) khi x (state) thay đổi thì bắt buộc phải tính lại hàm f(x).
 
Back
Top