với người hiểu sâu chứ k phải thợ gõ nha mấy thím
, test thuật toán khá kĩjob React giờ còn nhiều không vậy các bác![]()
Tôi trình gà nhưng chỗ này muốn học hỏi mn 1 chút, ý kiến của tôi cái autofill gợi ý là rất tốt nhưng k nên theo nó 100%. Có những trường hợp nó gợi ý autofill mình điên lf theo nó code sẽ bị render k cần thiết và dẫn đến saiTúm váy auto fix ko làm code hết bug, Chỉ phục vụ việc lười gõ vào array và việc k biết phải điền cái gì vô array. Vấn đề là điền dep vào mà call effect quá nhiều lần (loop) or bóp dé gì đó thì có nghĩa là code chỗ đó có vấn đề. Phân biệt junior với senior thì senior phải hiểu rõ cái dependency array của useEffect.
Tôi hàng ngày vẫn auto fix đỡ type và điền đủ vào array.Chả bao giờ ignore dependcy. Ko bị effect loop hay bóp dé gì cả. Căn bản qua cái thời mà useEffect hành hạ dc tôi![]()
bàn nát rùi có gì lội page thôi. Ko muốn fill đủ mà pass eslint thì qua vuejs nhéTôi trình gà nhưng chỗ này muốn học hỏi mn 1 chút, ý kiến của tôi cái autofill gợi ý là rất tốt nhưng k nên theo nó 100%. Có những trường hợp nó gợi ý autofill mình điên lf theo nó code sẽ bị render k cần thiết và dẫn đến sai



Callstack, Event Loop, execution context, hoisting, closure, prototype, this...Bác nào cho e xin list câu hỏi xoáy đáp xoay về js core với, : ((
Gửi từ Đời là bể khổ bằng vozFApp
Bác xem ảnh này ở docs reactbàn nát rùi có gì lội page thôi. Ko muốn fill đủ mà pass eslint thì qua vuejs nhé
bên vue có cái watchers hoạt động giống react useEffect nhưng ko thấy chửi om sòm như eslint rule of hook
Ko phải ngồi useMemo, useCallback
BTW Nói chứ giờ qua vue code rồi ko lẽ tạo thêm thớt vue cho xôm. Thực ra vô hóng cao nhân![]()
Thì nó bảo là change code hạn chế deps. Mấy cái cmt của tui có nói hết rồi. Ráng lục lọi đi. Tôi có chỉ cách optimize hết.Bác xem ảnh này ở docs react
Nó nói rõ thế mà bác, linter có thể sai dẫn đến loopThì nó bảo là change code hạn chế deps. Mấy cái cmt của tui có nói hết rồi. Ráng lục lọi đi. Tôi có chỉ cách optimize hết.
Theo linter ban đầu thì nó là hint thôi. Còn phải xem xét, vs optimize thêm nữa. Newbie mới tâp code thì đừng đua đòi bỏ linter. Làm theo rồi sửa sai, optimize dần thôi. Hồi mới ra hook tôi cũng tự tin cho rằng mình giỏi hơn linter cho đến khi ra bug và code như shit.
Chơi eslint ignore thường hiếm lắm or cần làm trò gì đó khi mình hiểu rõ thôi.
THì ai chả biết nhưng có hiểu vì sao loop ko nữa cơ. Rồi có bỏ deps đó ra chay mà linter ko chửi . Code như thế nào ko loop, ko bug, eslint ko chửi mới gọi là pro. Chứ bạ đâu ignore đó, thì dám bảo mình pro React dc hay koNó nói rõ thế mà bác, linter có thể sai dẫn đến loop

Linter có chửi hay k k phải vấn đề vì thiếu thì nó chửi thôi, cơ bản tôi lúc đầu nghĩ ý của bác là cứ fill theo linter là an toàn nên t mới quoteTHì ai chả biết nhưng có hiểu vì sao loop ko nữa cơ. Rồi có bỏ deps đó ra chay mà linter ko chửi hay ko. Code như thế nào ko loop, eslint ko chửi mới gọi là pro![]()
autofill mà ko biết trade off là gì thì chẳng chếtLinter có chửi hay k k phải vấn đề vì thiếu thì nó chửi thôi, cơ bản tôi lúc đầu nghĩ ý của bác là cứ fill theo linter là an toàn nên t mới quote


Thì vậy nên hy vọng ai vô sau đừng có quote tôi kiểu này nữa. Phải hiểu context tôi đang nói với ai (1 ông newbie ko rõ phải fill cái gì luôn ak) rồi đừng treat tôi là junior, or code lâu năm ngu si nữaLinter có chửi hay k k phải vấn đề vì thiếu thì nó chửi thôi, cơ bản tôi lúc đầu nghĩ ý của bác là cứ fill theo linter là an toàn nên t mới quote

bác check ib e với, tks bácCallstack, Event Loop, execution context, hoisting, closure, prototype, this...
"chắc cũng chịu chết chứ chẳng biết được là có xài Hooks đúng hay không" => trace lại xem nó đến từ đâu thôi constant, object, memo, state, inline... Cái gì cũng làm dc nếu có time. Ko có time thì chịu.autofill mà ko biết trade off là gì thì chẳng chết
review code mà gặp autofill chắc cũng chịu chết chứ chẳng biết được là có xài Hooks đúng hay không
Nói chung là code tốt là code mà giữ chân người dùng, code dở tự động nó sẽ ảnh hưởng tới trải nghiệm người dùng th![]()

Thì vậy nên hy vọng ai vô sau đừng có quote tôi kiểu này nữa. Phải hiểu context tôi đang nói với ai (1 ông newbie ko rõ phải fill cái gì luôn ak)![]()
Lúc đầu quote bác tôi cũng nhận newbie rồi chứ k bảo pro gi cả, nhưng như fence bảo đến loop mới check xem mình sai ở đâu thì k ai đồng ý cả. Nó sẽ không loop mà nó sẽ render không cần thiết. Với cả k ai k biết gì mà lại bạ đâu ignore đó dc, biết mới ignore chứTHì ai chả biết nhưng có hiểu vì sao loop ko nữa cơ. Rồi có bỏ deps đó ra chay mà linter ko chửi . Code như thế nào ko loop, ko bug, eslint ko chửi mới gọi là pro. Chứ bạ đâu ignore đó, thì dám bảo mình pro React dc hay ko![]()
Việc dài hay không là ngay người code phải có trách nhiệm split PR ra đủ nhỏ r."chắc cũng chịu chết chứ chẳng biết được là có xài Hooks đúng hay không" => trace lại xem nó đến từ đâu thôi constant, object, memo, state, inline... Cái gì cũng làm dc nếu có time. Ko có time thì chịu.
Chủ yếu reviewer có tâm hay ko hay dài quá type LGTM => approve![]()

cái render loop nó là một phần dễ thấy nhất của cái vụ xài hooks sai và autofillLúc đầu quote bác tôi cũng nhận newbie rồi chứ k bảo pro gi cả, nhưng như fence bảo đến loop mới check xem mình sai ở đâu thì k ai đồng ý cả. Nó sẽ không loop mà nó sẽ render không cần thiết.

Tôi hóng mãi có ai đem code use case ra cho tôi xem mà có đâu. Thấy bữa có anh thần bài khoe project nào có eslint ignore 1 đống mà cũng ko show codeViệc dài hay không là ngay người code phải có trách nhiệm split PR ra đủ nhỏ r.
Không thể nào đòi hỏi một codebase luôn luôn hoàn hảo nhưng mà cái vụ autofill này cứ lạm dụng r cũng sẽ thấy hậu quả th![]()
Ý nói chung chung với mấy ông thần khác thôiLúc đầu quote bác tôi cũng nhận newbie rồi chứ k bảo pro gi cả, nhưng như fence bảo đến loop mới check xem mình sai ở đâu thì k ai đồng ý cả. Nó sẽ không loop mà nó sẽ render không cần thiết. Với cả k ai k biết gì mà lại bạ đâu ignore đó dc, biết mới ignore chứ
Bữa có 1 2 ông ko đọc từ đầu tới cuối cũng quote 