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
fen hỏi j nextjs thì hỏi đi, thấy đi thớt nào cũng hỏi có code nextjs k
tks bác :sweet_kiss:, e đang có mấy thắc mắc như sau ạ:
  1. Khi nào nên dùng ISR, khi nào nên dùng SSR + cache ạ? E search thì thấy cả 2 th này đều tối ưu hiệu suất nhưng sử dụng cơ chế khác nhau.
  2. Có cách nào để get query trong ISR. Ví dụ trong hàm getStaticProps làm sao để lấy giá trị của "sort" với url sau: http://localhost:1234/chon-loc?sort=nameAZ. E có search và nhận được kết quả là với dynamic route kiểu kia thì với ISR là không thể, nên dùng SSR + cache
 
Reactjs cũng hay, cộng đồng nhiều, tuy nhiên đôi khi build rất chậm, đặc biệt khi build với docker, còn có trường hợp server bị treo cmnl. Học react thì kiến thức nhiều vô kể, phải đọc document nhiều vào.
Nếu chán thì có thể sang thằng Vue, nói chung thì FE có mỗi 2 thằng Reactjs và Vuejs là thấy ổn, tất cả những thằng khác điểm lợi cũng có nhưng không thể bằng 2 ông lớn này được.
 
Reactjs cũng hay, cộng đồng nhiều, tuy nhiên đôi khi build rất chậm, đặc biệt khi build với docker, còn có trường hợp server bị treo cmnl. Học react thì kiến thức nhiều vô kể, phải đọc document nhiều vào.
Nếu chán thì có thể sang thằng Vue, nói chung thì FE có mỗi 2 thằng Reactjs và Vuejs là thấy ổn, tất cả những thằng khác điểm lợi cũng có nhưng không thể bằng 2 ông lớn này được.
build chậm 1 phần webpack. Có thể thử chuyển sang xài vite.

Nextjs giờ xài swc rồi build bằng rust nên compile rất nhanh.

Vuejs cũng được, job hơi ít so với reactjs. Về job ở VN thì React > Angular > Vuejs
 
build chậm 1 phần webpack. Có thể thử chuyển sang xài vite.

Nextjs giờ xài swc rồi build bằng rust nên compile rất nhanh.

Vuejs cũng được, job hơi ít so với reactjs. Về job ở VN thì React > Angular > Vuejs
Những dự án cũ, không dùng được swc, hoặc những dự án không dùng đến nó thì build chậm hơn nhiều so với vuejs cùng số lượng package như nhau.
 
tks bác :sweet_kiss:, e đang có mấy thắc mắc như sau ạ:
  1. Khi nào nên dùng ISR, khi nào nên dùng SSR + cache ạ? E search thì thấy cả 2 th này đều tối ưu hiệu suất nhưng sử dụng cơ chế khác nhau.
  2. Có cách nào để get query trong ISR. Ví dụ trong hàm getStaticProps làm sao để lấy giá trị của "sort" với url sau: http://localhost:1234/chon-loc?sort=nameAZ. E có search và nhận được kết quả là với dynamic route kiểu kia thì với ISR là không thể, nên dùng SSR + cache
isr là cache page thôi mà. Thấy data page nào ít đổi có thể xài nó (lưu ý page có get data, chứ page static thì nextjs lúc nào cũng lấy từ cache)

ISR thì xưa cũng hay sài. Ví dụ bữa có làm cái project về news thì kêu nexjs cache lại 5 phút. Có nghĩa là mỗi request lên next thì nó chỉ lấy cái html đã dc render sẵn mọi thứ. Nên speed rất nhanh. Mỗi 5 phút thì request tiếp theo sẽ hit server, call api các kiểu rồi lại cache

Cái số 2 thì nhớ hình như ISR ko work với query string nên chịu thôi. Mà thuong web chậm là do phải query đên DB với external service. Nên SSR + cache api, query cũng là giải pháp.
 
Sửa lần cuối:
Những dự án cũ, không dùng được swc, hoặc những dự án không dùng đến nó thì build chậm hơn nhiều so với vuejs cùng số lượng package như nhau.
Webpack nó chậm đúng rùi. Cái này vuejs có tool build riêng nên phải khác.

Nói chung webpack cũng đang rewrite lại. Dự án cũ quá thì chịu thôi.

Còn giờ project mới phang vite thì cũng ok.
 
Đúng rồi fen, cty nào hỏi thuật toán thì tạch thôi, mà số lượng ko nhiều, hầu hết các cty trung bình, vị trí <= senior đều hỏi xoay quanh công nghệ, dự án...chứ có hỏi thuật toán, làm leetcode gì đâu. Đấy không phải là mình không coi trọng thuật toán nhưng mà dân trái ngành thì quan trọng kỹ năng nào có thể code được việc ngay để còn kiếm cơm, khi nào ổn định mới nghĩ tới học nâng cao lên chứ. Mình cỡ 3 năm exp từ lúc chuyển ngành, offer lần gần nhất cao hơn con số trong báo cáo của itviec nhưng cũng không yêu cầu thuật toán khi pv nhé.
thế pv thì hỏi những gì với từng ấy exp bác, share đc không bác
 
Reactjs cũng hay, cộng đồng nhiều, tuy nhiên đôi khi build rất chậm, đặc biệt khi build với docker, còn có trường hợp server bị treo cmnl. Học react thì kiến thức nhiều vô kể, phải đọc document nhiều vào.
Nếu chán thì có thể sang thằng Vue, nói chung thì FE có mỗi 2 thằng Reactjs và Vuejs là thấy ổn, tất cả những thằng khác điểm lợi cũng có nhưng không thể bằng 2 ông lớn này được.
Còn angular thì sao thím?
 
Gặp mấy đồng nghiệp như fence tôi dị ứng cực kì :look_down:
làm việc với React mà ko kiểm soát được callback của hook sẽ gọi lúc nào mà cứ auto fill full deps như thế thì cái app sẽ cực kì tệ.

via theNEXTvoz for iPhone

eg. eslint có rule index k được để làm id, phần lớn sẽ theo rule này, nhưng khi anh biết mình đang dùng là static thì ts-ignore được.


Còn 99% anh dùng sai useEffect nên mới bypass auto fill, những dev có tư duy ánh xạ lifecycle sang useEffect hay có tư tưởng như vậy
 
eg. eslint có rule index k được để làm id, phần lớn sẽ theo rule này, nhưng khi anh biết mình đang dùng là static thì ts-ignore được.


Còn 99% anh dùng sai useEffect nên mới bypass auto fill, những dev có tư duy ánh xạ lifecycle sang useEffect hay có tư tưởng như vậy
vậy ý fence khác gì ý tôi
chẳng phải autofill full deps là bad pratice hay sao :go:

via theNEXTvoz for iPhone
 
Thưa anh người ta làm ra cái rule eslint hook là có lý do nhé. Khi nào anh code mà eslint rule hook ko chửi thì quay lại đây.

Còn tôi fill đủ mà task ko bug, change state props mà effect run đúng. Ko loop or ko run khi ko cần thiết.

Có vẻ react dev trên đây chắc ko ai thèm cài eslint. Nói chứ cực dị dev nào ko cài eslint dac biệt rule of hook
Ai nói fence là ko cài eslint :go:
Autofill full deps mà dám khẳng định một câu không run khi không cần thiết là hay lắm á nha :look_down:

via theNEXTvoz for iPhone
 
Ai nói fence là ko cài eslint :go:
Autofill full deps mà dám khẳng định một câu không run khi không cần thiết là hay lắm á nha :look_down:

via theNEXTvoz for iPhone
Cài eslint nhưng chắc toàn bắn eslint ignore chỗ mấy cái hook chứ gì. Tôi auto fill và có test lại nhé. Đương nhiên project cũ thì tôi làm khúc nào auto fill chỗ đó thôi. Cái eslint fix nó ko có tự auto fill đâu. Mà nhờ mấy ông hiểu nhầm vậy nên tôi mới thấy mấy ông dev react trên đây nó như thế này.

Túm váy fen tự nhận mình thuộc 1% đi ok. Còn mấy ông dev gà mờ xin bám vào document dùm.

Code ko có memo hay inline function, object thì chả run lắm. Đảm bảo mấy fence thế này chả còn thèm dùng useMemo hay useCallback :go:

According to the React docs, you must include all values from the component scope that change their values between re-renders.
Screen Shot 2023-04-09 at 11.31.13.png
 
Sửa lần cuối:
isr là cache page thôi mà. Thấy data page nào ít đổi có thể xài nó (lưu ý page có get data, chứ page static thì nextjs lúc nào cũng lấy từ cache)

ISR thì xưa cũng hay sài. Ví dụ bữa có làm cái project về news thì kêu nexjs cache lại 5 phút. Có nghĩa là mỗi request lên next thì nó chỉ lấy cái html đã dc render sẵn mọi thứ. Nên speed rất nhanh. Mỗi 5 phút thì request tiếp theo sẽ hit server, call api các kiểu rồi lại cache

Cái số 2 thì nhớ hình như ISR ko work với query string nên chịu thôi. Mà thuong web chậm là do phải query đên DB với external service. Nên SSR + cache api, query cũng là giải pháp.
Cái vụ Cache thì nếu ko xài next isr thì mình chuyển qua react query cũng đc đúng ko bác, chức năng y chang và 1 số project required ko xài next😁
 
Cái vụ Cache thì nếu ko xài next isr thì mình chuyển qua react query cũng đc đúng ko bác, chức năng y chang và 1 số project required ko xài next😁
react query dưới client-side mà. Trên server đâu có xài react query dc.

Dù sao dưới client side cũng phải config này nọ nó mới cache ko hit api. còn bt nó vẫn call api suốt. Chỉ dơn giản là mặc định nếu có trong cache thì nó đem ra xài và fetch dưới background, fetch xong thì lôi ra update. Trừ phi config force chỉ xài cache trong bao lâu thôi.
 
isr là cache page thôi mà. Thấy data page nào ít đổi có thể xài nó (lưu ý page có get data, chứ page static thì nextjs lúc nào cũng lấy từ cache)

ISR thì xưa cũng hay sài. Ví dụ bữa có làm cái project về news thì kêu nexjs cache lại 5 phút. Có nghĩa là mỗi request lên next thì nó chỉ lấy cái html đã dc render sẵn mọi thứ. Nên speed rất nhanh. Mỗi 5 phút thì request tiếp theo sẽ hit server, call api các kiểu rồi lại cache

Cái số 2 thì nhớ hình như ISR ko work với query string nên chịu thôi. Mà thuong web chậm là do phải query đên DB với external service. Nên SSR + cache api, query cũng là giải pháp.
tks bác, còn vấn đề này k lquan lắm nhưng cũng liên quan đến react e xin hỏi luôn. Tại sao bây giờ nhiều người nói dùng SWR/React-query có thể thay thế th Redux ạ? Điều này có thực sự đúng, nếu vậy khi có 1 data (có liên quan đến api) muốn share nhiều component thì ở mỗi component đó ta dùng swr/react-query gọi lại api là được vì th swr/react-query có cache đúng k ạ?
 
react query dưới client-side mà. Trên server đâu có xài react query dc.

Dù sao dưới client side cũng phải config này nọ nó mới cache ko hit api. còn bt nó vẫn call api suốt. Chỉ dơn giản là mặc định nếu có trong cache thì nó đem ra xài và fetch dưới background, fetch xong thì lôi ra update. Trừ phi config force chỉ xài cache trong bao lâu thôi.
à vậy mình nhớ nhầm quá useSWR cũng của thằng Vercel
 
à vậy mình nhớ nhầm quá useSWR cũng của thằng Vercel
SWR cũng tương tự react query cũng xài ở client side thôi.

Nextjs get data ở sv rồi truyền xuống client. react query hay swr cũng chỉ lấy data dể tạo ra initdata thôi khi page mới load, sau đó ko có config gì thì fetch lại dưới background
 
react query dưới client-side mà. Trên server đâu có xài react query dc.

Dù sao dưới client side cũng phải config này nọ nó mới cache ko hit api. còn bt nó vẫn call api suốt. Chỉ dơn giản là mặc định nếu có trong cache thì nó đem ra xài và fetch dưới background, fetch xong thì lôi ra update. Trừ phi config force chỉ xài cache trong bao lâu thôi.
React query có support server-side https://tanstack.com/query/v4/docs/react/guides/ssr
 

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.274
Quay lại
Lên đầu trang