thắc mắc Tại sao ReactJS lại hot đến vậy ạ?

  • Người tạo chủ đề Người tạo chủ đề Celsius
  • Ngày bắt đầu Ngày bắt đầu
Thím nhận mail final round ghi pv bao lâu vậy? Mình chuẩn bị pv vòng final round bên NAB, thấy mail ghi có 1h thôi, nghe mùi căng thế. :sweat:
Vòng này nói chuyện với 2 Engineering Manager bằng Tiếng Anh. Nội dung: tech, work process (Scrum), behavior. Chỗ working process nên đá qua thằng ChatGPT tý đừng bám theo chỗ đang làm vì nó trả lời có vẻ chuẩn hơn
 
Tui share đến vậy thôi bác, bác biết nhiêu thế là đủ rồi gì nữa, tuỳ vào trình của bản thận, và đặc biệt là có match với interviewer k ấy, cái này t thấy là quan trọng nhất trong các buổi pv :))))
Bác cho em xin ít thông tin về naver round 2 với, round 1 hacker rank, round 2 live code là thuật toán à bác. Có gì cần tập trung vào không. Em cảm ơn
 
Nextjs thấy ít chỗ tuyển thế ae nhỉ, mà thằng Next này cũng thay đổi nhanh nữa giờ lại bản 13 vs app directory
 
biết React là làm được Next rồi thím, học tầm 1 tuần là rành rồi
Bản chất next cũng từ react mà ra, nó chỉ khác ở chỗ là khi nào nên SSR, CSR, ... thôi, chứ dăm ba cái router, image, font,... trong next đọc docs là làm được, k có gì là cao siêu cả.
 
Lục lại dc bài này cũng hài

https://attardi.org/why-we-memo-all-the-things/
Stefano J. Attardi
Engineering Manager at Coinbase lão này ghét kêu team spam useMemo vs useCallback nhiệt tình :shame:

Trình có vẻ kém :shame:
Reactjs mới đổi url nên chưa tìm được link dẫn chứng cho fen.
Nôm na là, trên trang reactjs.org họ nói, việc sử dụng useMemo và useCallback để giảm thiểu việc render và tạo function không cần thiết.
Họ còn khuyến cáo là có thể code mà không cần dùng 2 cái này nhưng việc render của reactjs sẽ render 1 component nhiều lần => không tối ưu và tốn tài nguyên sử lý không cần thiết và bị chậm.
Khi nào các bạn thấy website bị chậm thì hãy cân nhắc xài 2 cái function này để tối ưu hóa và speedup việc render.
2 function trên sẽ hỗ trợ việc store 1 biến hay 1 function vào cache, không mất thời gian tính đi tính lại và render.
 
Reactjs mới đổi url nên chưa tìm được link dẫn chứng cho fen.
Nôm na là, trên trang reactjs.org họ nói, việc sử dụng useMemo và useCallback để giảm thiểu việc render và tạo function không cần thiết.
Họ còn khuyến cáo là có thể code mà không cần dùng 2 cái này nhưng việc render của reactjs sẽ render 1 component nhiều lần => không tối ưu và tốn tài nguyên sử lý không cần thiết và bị chậm.
Khi nào các bạn thấy website bị chậm thì hãy cân nhắc xài 2 cái function này để tối ưu hóa và speedup việc render.
2 function trên sẽ hỗ trợ việc store 1 biến hay 1 function vào cache, không mất thời gian tính đi tính lại và render.
Tôi rành mà chỉ là đang nói đến việc lão EM nhức nách quá kêu nhân viên spam nhiệt liệt luôn. Thât ra lão ra bài này do hồi trước trên twitter cũng tranh cãi nảy lữa việc lúc nào cũng spam hay ko (Tuy nhiên trong đống thread đó thì ko thấy ai skip deps or ignore eslint)

Nói chung tầm cỡ EM mà cũng spam memo với callback nhiệt tình, trình thua mấy anh dev trong F này rồi :shame:
 
Tôi rành mà chỉ là đang nói đến việc lão EM nhức nách quá kêu nhân viên spam nhiệt liệt luôn.

Nói chung tầm cỡ EM mà cũng spam memo với callback nhiệt tình, trình thua mấy anh dev trong F này rồi :shame:
Là sao fen, giải thích rõ hơn được không.
Tôi hơi chậm hiểu.
Chậm chút được không ?
Có phải ý fen muốn nói là, nhân viên không hiểu tại sao phải dùng 2 cái này mà vẫn spam vì mệnh lệnh của cấp trên ?
 
Là sao fen, giải thích rõ hơn được không.
Tôi hơi chậm hiểu.
Chậm chút được không ?
À chắc fen ko có lội thớt.

Chứ ban đầu combat nhiệt liệt vụ này trong thớt này. Nói chung tôi cũng theo trường phái khi nào cần thì xài + tuân thủ eslint thôi.

Chứ lão EM này thì hơi căng, chỗ nào function có deps thì auto useCallback, tính toán biến có deps thì auto useMemo luôn. Component thì xài React.memo luôn ko cần biết gì luôn. Túm váy chỗ nào memo dc thì xài luôn khỏi suy nghĩ + cãi nhau.
 
Cám ơn fen nha để mình lội page.
Nghĩ cũng buồn cười RAM trên private desktop thì có hạn mà cố spam cái memory nhiều nhằm giảm vài vòng lặp render. (Thấy không đáng lắm)
Mình có làm ở 1 cty VN, họ code toàn cache in memory. (dictionary là chính, ở mọi app dạng microservice luôn)
Muốn replicas instance là được xN cái memory. (mồm lúc nào cũng bảo thêm RAM, SSD các kiểu, nghe buồn cười)
Có vẻ RAM và SSD quá rẻ nên họ tha hồ vung tiền thay vì nghĩ cách tối ưu sao cho tiết kiệm tiền của doanh nghiệp.
 
Sửa lần cuối:
@Celsius Không có ai vẽ được đường cho em cả. Nếu em chưa biết phải học cái gì thì tốt nhất nên học thử tất cả các cái trên xem mình cảm thấy thoải mái viết code của ngôn ngữ nào nhất. Ngôn ngữ nào càng viết càng thấy thích, cảm thấy cách nó được thiết kế phù hợp với tư duy của mình thì em nên theo lâu dài. Theo được lâu dài thì mới giỏi được. Giỏi rồi chắc chắn sẽ kiếm được việc lương tốt, kể cả khi ngôn ngữ đó không quá phổ biến.

Ví dụ JavaScript là ngôn ngữ dynamically-typed, ban đầu thiết kế để viết code website. Cho nên triết lý thiết kế của nó là đơn giản hóa việc viết code, linh động, tinh gọn. Nhưng nhược điểm là khó scale ở quy mô lớn, dễ có bug, khó bảo trì, khó quản lý chất lượng code. Cho nên gần đây mới xuất hiện TypeScript (statically-typed) xử lý các vấn đề đang tồn tại của JavaScript.

Thường thì những dev thích bài bản, nguyên tắc, khuôn khổ sẽ rất ghét JavaScript và ưa thích những ngôn ngữ dạng statically-typed như Java hay C++. Những dev thích sự linh động, đơn giản, không gò bó thì thường rất thích JavaScript.

Em nên tự tìm hiểu xem mình thuộc kiểu dev nào trước rồi mới có thể chọn được ngôn ngữ phù hợp. Nên nhớ không bao giờ nên chọn theo thị trường hay số đông.
 
Luyện 1 ngôn ngữ lên expert thì mấy cái khác học sẽ nhanh hơn.
Vì đã có cơ sở pháp lý để so sánh và tìm ra điểm khác biệt.
Khi đã biết bản chất của vấn đề thì mọi bài toán ở doanh nghiệp đều giải được hết.
Theo đuổi cái mình giỏi thì thử thách và tiền bạc sẽ theo sau bạn.
 
Hi mấy thím, em có 1 case như thế này
Ví dụ feature đó là filter 1 list danh sách thì mình có cần filter trên endpoint rồi gửi BE hay BE gửi 1 list danh sách thô rồi mình filter ở FE cho đỡ tốn request gửi lên server nhỉ? cách nào tối ưu development experience nhất?
 
Hi mấy thím, em có 1 case như thế này
Ví dụ feature đó là filter 1 list danh sách thì mình có cần filter trên endpoint rồi gửi BE hay BE gửi 1 list danh sách thô rồi mình filter ở FE cho đỡ tốn request gửi lên server nhỉ? cách nào tối ưu development experience nhất?
1/ BE xây sẵn api trả dữ liệu theo các fields trên request filter model.
2/ BE chỉ trả về dữ liệu phù hợp với filter trên.
3/ FE chỉ việc nhận dữ liệu và render. (không thao tác filter lại gì hết, việc filter lại sẽ gây thêm lỗi ở FE và tìm lỗi sẽ gây mâu thuẫn không đáng có ở BE và FE)

Không ai làm cái việc trả 1 đống data từ BE để về FE filter rồi render cả.
(Cty nào làm như trên là đang tự đẻ trứng ở hiện tại và tương lai)
Người ta ưu tiên sử lý tính toán ở BE, đưa tính toán về FE sẽ làm máy private desktop bị chậm khi sử lý dữ liệu lớn => trải nghiệm khách hàng giảm => chửi product => mất khách hàng tiềm năng, ...

Việc scale up BE với load-balancing thành nhiều instance sẽ hỗ trợ nhiều FE có thể gửi hàng triệu request 1 giây tới BE mà không bị bottle-neck API.
Có rất nhiều cách để optimize BE và FE, đừng vì sự lười biếng của bản thân mà đẻ trứng ở product, người sau người ta biết sẽ chửi fen đó.

p/s:
Việc deploy thằng FE lên production mất nhiều thời gian hơn là BE. (Khi nào bạn upload Apple store hay Google Play sẽ thấy cái cảnh cực khổ của việc duyệt ứng dụng của flagship)
Tương tự reactjs cũng vậy thôi, đó là việc phải tốn thêm thời gian để test lại hết các tính năng.
 
Sửa lần cuối:
1/ BE xây sẵn api trả dữ liệu theo các fields trên request filter model.
2/ BE chỉ trả về dữ liệu phù hợp với filter trên.
3/ FE chỉ việc nhận dữ liệu và render. (không thao tác filter lại gì hết, việc filter lại sẽ gây thêm lỗi ở FE và tìm lỗi sẽ gây mâu thuẫn không đáng có ở BE và FE)

Không ai làm cái việc trả 1 đống data từ BE để về FE filter rồi render cả.
(Cty nào làm như trên là đang tự đẻ trứng ở hiện tại và tương lai)
Người ta ưu tiên sử lý tính toán ở BE, đưa tính toán về FE sẽ làm máy private desktop bị chậm khi sử lý dữ liệu lớn => trải nghiệm khách hàng giảm => chửi product => mất khách hàng tiềm năng, ...

Việc scale up BE với load-balancing thành nhiều instance sẽ hỗ trợ nhiều FE có thể gửi hàng triệu request 1 giây tới BE mà không bị bottle-neck API.
Có rất nhiều cách để optimize BE và FE, đừng vì sự lười biếng của bản thân mà đẻ trứng ở product, người sau người ta biết sẽ chửi fen đó.

p/s:
Việc deploy thằng FE lên production mất nhiều thời gian hơn là BE. (Khi nào bạn upload Apple store hay Google Play sẽ thấy cái cảnh cực khổ của việc duyệt ứng dụng của flagship)
Tương tự reactjs cũng vậy thôi, đó là việc phải tốn thêm thời gian để test lại hết các tính năng.
cảm ơn thím chia sẻ, cứ nghĩ việc filter đống data đó giúp giảm được 1 số request gửi lên server
 

Thống kê chủ đề

Ngày tạo
Celsius,
Người trả lời cuối
JavaNeverDie002,
Trả lời
690
Lượt xem
97.278
Quay lại
Lên đầu trang