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

binpham17 said:

Lại tinh tướng nữa rồi, thế tôi không thích đọc như cách ông đọc mà vẫn hiểu đó thì sao )))

Click to expand...

perepermin said:

thì a là thằng chém gió. thế thôi

Click to expand...

binpham17 said:

Lại tinh tướng nữa rồi, thế tôi không thích đọc như cách ông đọc mà vẫn hiểu đó thì sao )))

Click to expand...

Lập Trình Viên CRUD quèn said:

Đúng nhưng fen đọc code sẽ thêm 1 bước suy luận, ví dụ thấy chỗ nào changeState fen phải nghĩ "À change state thì component sẽ render lại"

còn tôi đọc code be cứ line-by-line thôi tôi ko phải nghĩ gì cả

Click to expand...

Love U So Much said:

Kiến thức của mấy fw front end bây giờ rất cao, khó hiểu, đọc sách cả năm may ra mới thông nổi.

Tư duy thớt đang là imperative, đáng lẽ phải học thêm async, declarative programming thì lại ì ra chê bai

Động thêm mấy cái như cloud, devopts thì lại khóc với chê thôi

Click to expand...

cc1310 said:

như t code vue chả hạn thì cài extension của vue lên, rồi check theo timline thôi, chưa thấy gì khó

Click to expand...

Lập Trình Viên CRUD quèn said:

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?

Click to expand...

ocvit333 said:

về cơ bản cây dom của frw bọn nó toàn dựa trên sự bất đồng bộ, code lung tung cả lên nhưng thằng nào render ra trước lại phải dựa vào điều kiện của thằng khác, ông thớt bực mình là đúng nếu như thằng viết dùng Js viết, đọc sẽ cực kỳ bực mình, nhưng nếu là TS thì mọi thứ sẽ được giải quyết thôi mà

hồi trước tôi cũng là gà dùng Js code frw, sau chuyển qua ts chưa viết xong đã thấy code nó nhảy ra hộ mình rồi bao khỏe, thằng QA cũng k còn phải chửi nhau với mình nữa, chắc ông thớt cũng tầm Jun hoặc đang là tầng lớp đi dọn cức của mấy thằng mới, code lung tung nên cáu

Click to expand...

docbaovoz said:

cái vụ chưa viết xong đã thấy code nhảy ra hộ mình là sao thế bác

Click to expand...

BruceWaynne said:

Thật ra chủ thớt quen làm BE rồi nhảy sang FE lạ nước lạ cái thôi. Làm nhiều cái nào + đủ lâu ngấm nó thì thấy ok. Bên BE chưa nói gì tới async code thì một số trường hợp cũng khó đọc + debug chứ cũng ko hẳn cứ đọc 1 lèo từ trên xuống là xong. Ví dụ 1 số chỗ xài inheritance + polymorphism hơi sâu quá mà lại có nhiều lớp lang, lớp con thằng thì override thằng thì overload, thằng thì tận dụng hết từ abstract parent nên lúc đọc cũng navigate nhảy lên xuống giữa các class đọc mệt nghỉ. Gặp mấy ông syntax dị dị như Ruby thì cũng mất 1 thời gian để làm quen.

Cơ mà cũng công nhận thời gian đầu mà đụng FE framework như thằng React khá hack não, cảm giác gần như ko kiểm soát được luồng đi của nó thế nào dù biết có life cycle. Chưa kể cách hình dung và đọc 1 component nó cũng có phần khác biệt so với đọc 1 class bên BE. Nó vừa có parameter input và vừa có bắn event output ra ngoài để tương tác với thằng parent gần nhất hoặc parent ở xa nên kiểu luồng data vừa chạy vào bên trong 1 cái abstraction mà vừa chạy ra bên ngoài nhưng vẫn phải đảm bảo cohesion + low-coupling giữa parent-child component, khá nhức đầu đối với beginner hoặc BE mới nhảy vào. Và chỗ này code không cẩn thận thì parent-child nó dính chặt nhau khỏi gỡ vì react hay javascript code kiểu quái gì nó cũng chạy được, gần như ko có ràng buộc, ông nào maintain mấy case này mà project bự thì chết dở luôn.

1 điểm nữa loằng ngoằng và li chi vì thường 1 function trong BE nó xong là sẽ xong. Còn FE thì sẽ bị lôi đầu chạy lại nhiều lần từ rất nhiều yếu tố như watcher, global/local/sub local (context/provider) state change, hook/composable change, parent rerender, ... vì bản chất UI sẽ phải thay đổi liên tục theo user interaction. Li chi hơn nữa là code handle mấy quả UX interaction như blur, keyup keydown, focus, escape, enter, shortcut keys ... các thứ cũng khá vã khó hình dung nếu chỉ đọc code chay bình thường. Mà qua thời gian cứ debug, gắn log từ từ sẽ nắm cách nó đi

Ban đầu mình code BE, nhảy sang code Vue 2 -> chửi, mà code 1 thời gian lại thấy hay nên ưng. Sau qua code React -> chửi, code 1 thời gian hiểu bản chất lại ưng. Về sau có duyên quay lại code Vue nhưng Vue 3, lúc này nó lai học ý tưởng từ React nên cách code khác Vue 2 kha khá, mà cũng chả giống React -> lại chửi Nên quen cái nào thì ít chửi cái đó thôi bác :]]]

Click to expand...

Reishou said:

Vẫn đang phân vân có nên thêm ông chủ thớt vào ignoring hay không Nhiều lúc ngáo đá, thích thể hiện lập topic xàm quá, nhưng cũng là người chịu khó học hỏi nên vẫn không nỡ chửi

Click to expand...

Lập Trình Viên CRUD quèn said:

Thế kinh nghiệm đọc code reactjs là gì vậy bác?

Click to expand...

GeniVN said:

không biết ông thớt hỏi thật hay hỏi đùa, nhưng tôi cũng chia sẻ thật lòng luôn.

Thường thì tôi đọc theo component. Chẳng hạn như button (một trong những cái quan trọng nhất). Button thường hay trigger một cái handler, nhảy vào handler đọc rồi kiểm tra xem nó trigger state transition gì (gọi API về update state). Kiểm tra cái state mà nó mutate là state nào và có những thằng component nào đang dùng nó. Nhảy vào component đấy xem nó dùng state ntn.

Cứ theo flow đó thôi. Còn debug từ component bị lỗi thì dịch ngược lại. Xem component dính lỗi đang dùng state nào, tìm xem state nó được mutate tại đâu rồi xem button nào hay action nào trigger chỗ đó. Cũng đọc line by line được nhưng cứ coi line tách rời nhau, scatter ở từng component, từng file, mỗi một state thay đổi rồi component nào sử dụng state nào thì cứ coi là 1 cái if, if (stateA) { rerenderComponentA }.

Thi thoảng đọc cũng khó hiểu, mất thời gian nhưng là do concept của frontend tận dụng state nhiều nên đành vậy chứ khó blame framework lắm. Thớt thích thì dùng Vue/Svelte cũng hay, syntax tối giản hơn React, ít boilerplate hơn nữa, nhưng về cách hiểu code ntn thì chắc tụi nó cũng na ná nhau đấy, tại toàn state mà.

Có article khá hay trên Viblo: https://vntalking.com/debug-react-trong-vscode.html

Click to expand...