React Server Components में 50K lines of code migrate करने से पहले जो बातें पता होतीं तो अच्छा होता

 (mux.com)
1 पॉइंट द्वारा GN⁺ 2023-09-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लेखक ने 50,000 lines of code को React Server Components (RSCs) में migrate करते समय जो अनुभव और सीख हासिल की, उन पर आधारित लेख
  • RSCs ऐसे React components हैं जो client की बजाय server पर चलते हैं, और server-side rendering (SSR) की तुलना में दो बड़े फायदे देते हैं
    • पहला, RSCs developers को यह तय करने देते हैं कि code कहाँ चलेगा, जिससे bundle size कम होता है और hydration के दौरान काम घटता है
    • दूसरा, server components component के भीतर सीधे data fetch करके उसे client तक stream कर सकते हैं, जिससे React में data fetching अधिक आसान और efficient हो जाती है
  • हालांकि, RSCs इस्तेमाल करने में कुछ सीमाएँ भी हैं। CSS-in-JS server components में काम नहीं करता, React Context तक केवल client components से पहुँचा जा सकता है, और code कहाँ execute होगा इसे manage करने की complexity चुनौतीपूर्ण हो सकती है
  • लेखक RSCs को क्रमिक रूप से अपनाने के लिए 3-step approach सुझाते हैं:
    • app के root में "use client" directive जोड़ें
    • rendering tree में इस directive को जितना संभव हो उतना नीचे ले जाएँ
    • performance issues आने पर advanced patterns अपनाएँ
  • अतिरिक्त complexity के बावजूद, लेखक का निष्कर्ष है कि RSCs के फायदे—जैसे छोटा bundle size, तेज execution, और advanced data loading patterns—उन teams के लिए इसकी लागत से अधिक मूल्य दे सकते हैं जिनके लिए performance benefits महत्वपूर्ण हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-09-03
Hacker News की राय
  • लेख 50K कोड लाइनों को React Server Components (RSCs) में माइग्रेट करने की चर्चा करता है।
  • कुछ उपयोगकर्ताओं ने server-side rendering की गति और सरलता का ज़िक्र किया, और बताया कि client को तुरंत देखने योग्य HTML मिलता है।
  • यह सुझाव दिया गया कि RSCs की जगह Rails, Django, Laravel जैसे full-stack या classic web frameworks पर विचार करना अधिक तेज़ और scalable समाधान हो सकता है।
  • कुछ उपयोगकर्ताओं ने आधुनिक frameworks की जटिलता पर चिंता जताई, और कहा कि साधारण कामों के लिए भी बड़े build और compile pipelines की ज़रूरत पड़ती है।
  • उपयोगकर्ताओं ने next.js और उसके नए app directory setup के बारे में अपने अनुभव साझा किए, और यह समझने में कठिनाई बताई कि काम कहाँ हो रहा है (server या client), साथ ही उन मौजूदा React libraries के साथ समस्याएँ भी उजागर कीं जो client-side काम को मानकर चलती हैं।
  • कुछ उपयोगकर्ताओं ने नए next.js app directory paradigm में bugs और खुरदरे हिस्सों की ओर इशारा किया, जिनमें dynamic routes और parallel routes से जुड़ी समस्याएँ शामिल थीं।
  • एक उपयोगकर्ता ने PHP और JavaScript की समानता का ज़िक्र करते हुए कहा कि JavaScript, भले ही उसमें ज़्यादा abbreviations हों और learning curve अधिक कठिन हो, फिर भी समान server-side capabilities देने की दिशा में विकसित हुई है।
  • कुछ उपयोगकर्ताओं ने इस बात पर सवाल उठाया कि उन कामों के लिए React की ज़रूरत क्यों है जिन्हें static site generators या caching वाले CMS जैसे सरल tools से हल किया जा सकता है।
  • उस दौर के लिए एक nostalgia भी दिखी जब server सब कुछ render करता था और CSS व JavaScript rendering के बाद page को बेहतर बनाते थे।
  • कुछ उपयोगकर्ताओं ने यह राय दी कि React आधुनिक, आसान और तेज़ विकल्पों की बराबरी करने की कोशिश में और अधिक जटिल होता जा रहा है।
  • backend में HTML render करने के लिए React के उपयोग पर भी बहस हुई; कुछ उपयोगकर्ताओं ने इसकी आवश्यकता पर सवाल उठाया, जबकि दूसरों ने पारंपरिक server-return तरीकों की तुलना में इसके फ़ायदों का बचाव किया।