Frontend Interview: आप React Hydration Mismatches को कैसे Debug और Fix करते हैं?

समस्या और प्रासंगिक संदर्भ

एक Next.js App Router प्रोडक्ट पेज HTML को प्री-रेंडर करता है, फिर पसंदीदा (favorite) बटन और बैक-इन-स्टॉक फ़ॉर्म को इंटरैक्टिव बनाने के लिए ब्राउज़र में JavaScript लोड करता है। प्रोडक्शन मॉनिटरिंग पहली विज़िट्स के एक छोटे हिस्से पर React error #418 रिपोर्ट करती है। प्रभावित उपयोगकर्ताओं को समय या थीम में फ़्लैश दिखाई दे सकता है, फ़ॉर्म लेबल कुछ समय के लिए अपना एसोसिएशन खो सकता है, या पसंदीदा बटन फिर से बन सकता है। लोकल डेवलपमेंट और बाद के क्लाइंट-साइड नेविगेशन आमतौर पर सामान्य दिखते हैं।

एक समीक्षा में उसी Client Component के रेंडर पाथ के अंदर चार जोखिम भरे ऑपरेशन्स मिलते हैं: ब्राउज़र के डिफ़ॉल्ट टाइमज़ोन के साथ समय को फ़ॉर्मेट करना, localStorage से थीम पर ब्रांचिंग करना, Math.random() के साथ फ़ॉर्म ID जेनरेट करना, और रिच टेक्स्ट एमिट करना जो अमान्य नेस्टिंग बना सकता है। प्रोडक्शन के आगे एक CDN लगा है, और कुछ उपयोगकर्ताओं के पास ऐसे ब्राउज़र एक्सटेंशन हैं जो पेजों को बदल देते हैं। बताएं कि पूरे पेज के लिए SSR को अक्षम किए बिना या चेतावनियों को व्यापक रूप से दबाए बिना उस स्टेज की पहचान कैसे करें जो सर्वर स्नैपशॉट को पहले क्लाइंट रेंडर से अलग बनाती है।

KORE1 की 2026 सीनियर फ्रंटएंड इंटरव्यू गाइड उम्मीदवारों से सीधे केवल प्रोडक्शन में होने वाले ऐसे hydration mismatches को डिबग करने के लिए कहती है जिन्हें स्थानीय रूप से रीप्रोड्यूस नहीं किया जा सकता है। MockIF का 2026 React प्रश्न बैंक भी hydration को एक उन्नत आर्किटेक्चर प्रश्न के रूप में सूचीबद्ध करता है। React और Next.js का दस्तावेज़ीकरण identical-output अनुबंध स्थापित करता है और समय, रैंडम मान, ब्राउज़र API, अमान्य नेस्टिंग और बाहरी DOM म्यूटेशन को कारणों के रूप में पहचानता है। इसलिए इस प्रश्न का वर्तमान साक्षात्कारों में सत्यापन योग्य प्रतिनिधित्व है। इसका मुख्य कौशल ब्राउज़र रेंडरिंग और React hydration डिबगिंग है, इसलिए श्रेणी frontend है। इवेंट लूप, कैशिंग, परफ़ॉर्मेंस, keys, और stale closures पर मौजूदा प्रश्न इस अनुबंध को कवर नहीं करते हैं।

साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है

पहला, क्या उम्मीदवार hydration को सटीक रूप से परिभाषित कर सकता है? प्रारंभिक लोड पर, उपयोगकर्ता प्री-रेंडर किया गया HTML देखता है। ब्राउज़र इसे पार्स करता है, और React मौजूदा DOM से कंपोनेंट लॉजिक और इवेंट हैंडलर जोड़ता है। Client Components अभी भी प्रारंभिक HTML प्री-रेंडरिंग में भाग ले सकते हैं; "use client" का अर्थ पहले लोड पर केवल ब्राउज़र में रेंडरिंग नहीं है। अनुबंध सर्वर परिणाम की तुलना क्लाइंट के पहले रेंडर से करता है, न कि किन्हीं दो बाद के रेंडरों से।

दूसरा, क्या उम्मीदवार सबूतों का उपयोग करके विचलन के चार वर्गों को अलग कर सकता है? एप्लिकेशन इनपुट भिन्न हो सकते हैं, जैसे डेटा स्नैपशॉट, वर्तमान समय, या रैंडम मान। निष्पादन वातावरण (execution environments) window, localStorage, भाषा, या टाइमज़ोन के माध्यम से भिन्न हो सकते हैं। ब्राउज़र अमान्य HTML को सुधारकर एक अलग DOM बना सकता है। अंत में, एक CDN, एक्सटेंशन, या स्क्रिप्ट React शुरू होने से पहले नोड्स को म्यूटेट कर सकती है। केवल एक कंपोनेंट स्टैक को देखने से वह पार्सिंग या बाहरी म्यूटेशन छूट सकता है जो पहले हुआ था।

तीसरा, क्या उम्मीदवार प्रत्येक कारण को एक उपयुक्त समाधान से मैप कर सकता है? स्थिर इनपुट को सीरियलाइज़ किया जाना चाहिए और एक स्नैपशॉट के रूप में पुन: उपयोग किया जाना चाहिए। उपयोगकर्ता के वातावरण को कुकी या प्रोफ़ाइल से सर्वर पर हल किया जा सकता है, या hydration के बाद किसी Effect में अपडेट किया जा सकता है। रैंडम DOM ID को useId का उपयोग करना चाहिए। अमान्य नेस्टिंग को ठीक किया जाना चाहिए। SSR केवल एक छोटे थर्ड-पार्टी कंपोनेंट के लिए अक्षम किया जाना चाहिए जिसे वास्तव में प्री-रेंडर नहीं किया जा सकता है।

अंत में, क्या उम्मीदवार यह साबित कर सकता है कि दोष समाप्त हो गया है? एक मजबूत योजना एक प्रोडक्शन बिल्ड, कोल्ड इनिशियल लोड, धीमी JavaScript, लोकेल और टाइमज़ोन संयोजनों, कैश हिट, एक साफ ब्राउज़र और एक एक्सटेंशन-प्रभावित ब्राउज़र को कवर करती है। यह त्रुटियों, DOM पहचान, इंटरैक्शन स्थिति और विज़ुअल फ़्लैशिंग की जाँच करती है। एक शांत कंसोल केवल एक परिणाम है, पूरा सबूत नहीं।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

• क्या त्रुटि केवल प्रारंभिक दस्तावेज़ लोड पर होती है, या क्लाइंट नेविगेशन पर भी होती है? Hydration मौजूदा HTML पर React का पहला टेकओवर है। बाद के नेविगेशन का दोष इसके बजाय स्टेट, कैशिंग या एसिंक्रोनस रेस की ओर इशारा करता है।
• क्या बेमेल (mismatch) टेक्स्ट, एट्रिब्यूट्स, नोड स्ट्रक्चर या पूरे सबट्री में है? प्रोडक्शन त्रुटि संख्या से अनुमान लगाने के बजाय पूरी त्रुटि, कंपोनेंट स्टैक, रूट और डिप्लॉयमेंट वर्ज़न को सुरक्षित रखें।
• क्या सर्वर उपयोगकर्ता के लोकेल, टाइमज़ोन, थीम और एक्सपेरिमेंट बकेट को जानता है? URL, कुकी या प्रोफ़ाइल के माध्यम से उपलब्ध मान सर्वर पर तय किए जाने चाहिए और क्लाइंट को पास किए जाने चाहिए। अज्ञात मानों के लिए एक स्थिर प्लेसहोल्डर या hydration के बाद अपडेट की आवश्यकता होती है।
• क्या पहला क्लाइंट रेंडर उसी सटीक बिज़नेस-डेटा स्नैपशॉट का उपयोग करता है जिसने HTML उत्पन्न किया था? भले ही ब्राउज़र ने hydration से पहले नया डेटा फ़ेच कर लिया हो, प्रारंभिक दृश्य को सीरियलाइज़्ड स्नैपशॉट से शुरू होना चाहिए और केवल hydration के बाद रिफ़्रेश होना चाहिए।
• क्या HTML किसी CDN, ट्रांसलेशन प्रॉक्सी, सिक्योरिटी इंजेक्टर या ऑप्टिमाइज़र से होकर गुजरता है? यह देखने के लिए कि क्या कोई मध्यस्थ व्हाइटस्पेस, एट्रिब्यूट्स, टैग्स या स्क्रिप्ट क्रम को बदलता है, ओरिजिन और एज दोनों प्रतिक्रियाओं को कैप्चर करें।
• क्या त्रुटि किसी एक्सटेंशन, मोबाइल ब्राउज़र या क्षेत्र तक सीमित है? यह तय करता है कि React शुरू होने से तुरंत पहले नेटवर्क प्रतिक्रिया बॉडी की वास्तविक DOM से तुलना करनी है या नहीं।
• क्या इस सबट्री को प्री-रेंडरिंग की आवश्यकता है? SEO, फ़र्स्ट पेंट या बिना-JavaScript पठनीयता के लिए मूल्यवान सामग्री को SSR बनाए रखना चाहिए। ब्राउज़र-ओनली लीफ़ विजेट स्थानीय ssr: false को उचित ठहरा सकता है।
• कौन से विज़ुअल परिवर्तन स्वीकार्य हैं? टू-पास रेंडरिंग hydration अनुबंध को बनाए रख सकती है लेकिन धीमे कनेक्शन पर एक दृश्य परिवर्तन ला सकती है। प्लेसहोल्डर सामग्री, लेआउट स्थिरता और एक्सेसिबिलिटी पर पहले सहमति दें।

30-सेकंड उत्तर रूपरेखा

"Hydration के लिए सर्वर HTML और क्लाइंट के पहले रेंडर को समान संरचना और सामग्री उत्पन्न करने की आवश्यकता होती है। मैं त्रुटि, कंपोनेंट स्टैक, रूट, वर्ज़न, लोकेल और टाइमज़ोन को कैप्चर करूँगा, फिर तीन सबूतों को संरेखित करूँगा: नेटवर्क पर प्राप्त HTML, React के टेकओवर करने से पहले ब्राउज़र द्वारा पार्स किया गया DOM, और पहले क्लाइंट रेंडर के इनपुट। यदि नेटवर्क HTML पहले से ही भिन्न है, तो डेटा स्नैपशॉट और CDN का निरीक्षण करें। यदि यह पार्सिंग के दौरान बदलता है, तो अमान्य नेस्टिंग, एक्सटेंशन और प्रारंभिक स्क्रिप्ट का निरीक्षण करें। यदि React के रेंडर होने पर यह विचलित होता है, तो समय, यादृच्छिकता, ब्राउज़र API और प्रारंभिक डेटा रिफ़्रेश का निरीक्षण करें। मैं एक सीरियलाइज़्ड स्नैपशॉट का पुन: उपयोग करूँगा, लोकेल और timeZone निर्दिष्ट करूँगा, useId का उपयोग करूँगा, और ब्राउज़र स्थिति को कुकी से या hydration के बाद किसी Effect में प्राप्त करूँगा। मैं ssr: false को केवल ब्राउज़र-ओनली लीफ़ के लिए और suppressHydrationWarning को अपरिहार्य एक-स्तरीय टेक्स्ट अंतर के लिए आरक्षित रखूँगा। फिर मैं एनवायरनमेंट मैट्रिक्स में कोल्ड प्रोडक्शन लोड चलाऊँगा और सत्यापित करूँगा कि कोई रिकवरेबल एरर, सबट्री रिप्लेसमेंट, फ़्लैश या इंटरैक्शन बग न हो।"

चरण-दर-चरण गहन विश्लेषण

चरण 1: कंपोनेंट्स को डिबग करने से पहले इनवेरिएंट बताएं।

मान लें कि सर्वर कंपोनेंट ट्री इनपुट स्नैपशॉट S से HTML उत्पन्न करता है। ब्राउज़र HTML को DOM D में पार्स करता है, और क्लाइंट इनपुट C के साथ अपना पहला रेंडर निष्पादित करता है। सफल hydration के लिए आवश्यक है कि D और क्लाइंट ट्री उन नोड्स, टेक्स्ट और एट्रिब्यूट्स के लिए मेल खाएं जिन पर React निर्भर करता है। लक्ष्य केवल यह साबित करना नहीं है कि दोनों वातावरणों ने समान स्रोत फ़ाइल लोड की है। यह साबित करना है कि S, पार्सिंग और C ने समान परिणाम उत्पन्न किया।

React यह गारंटी नहीं देता है कि प्रत्येक एट्रिब्यूट अंतर को पैच किया जाएगा। कुछ विसंगतियां रिकवरेबल होती हैं और सबट्री को दोबारा बनाने का कारण बनती हैं; सबसे खराब स्थिति में, हैंडलर गलत तत्वों से जुड़ सकते हैं। इसलिए hydration mismatch केवल हानिरहित कंसोल नॉइज़ नहीं है।

चरण 2: एक ऐसा साक्ष्य पैकेज बनाएं जो प्रोडक्शन फ़र्स्ट लोड का प्रतिनिधित्व करता हो।

संवेदनशील मानों को एकत्र किए बिना रूट, डिप्लॉयमेंट वर्ज़न, रिक्वेस्ट ID, कैश स्थिति, लोकेल, टाइमज़ोन, थीम स्रोत, एक्सपेरिमेंट बकेट, User-Agent और पूर्ण कंपोनेंट स्टैक रिकॉर्ड करें। प्रोडक्शन बिल्ड और पूर्ण रीलोड का उपयोग करें। हॉट रीलोड, केवल-डेवलपमेंट व्यवहार और क्लाइंट नेविगेशन प्रोडक्शन कोल्ड स्टार्ट को रीप्रोड्यूस नहीं करते हैं।

एक अनुरोध के लिए, तीन आर्टिफ़ैक्ट्स को सुरक्षित रखें: ओरिजिन या CDN द्वारा लौटाई गई रिस्पॉन्स बॉडी, JavaScript अक्षम होने पर पार्स किया गया DOM, और JavaScript सक्षम होने पर त्रुटि से ठीक पहले और बाद का DOM। यदि रिस्पॉन्स सही है लेकिन Elements ट्री पहले से ही भिन्न है, तो पहले HTML पार्सर सुधार, एक्सटेंशन और प्री-React स्क्रिप्ट का निरीक्षण करें। यदि DOM केवल React शुरू होने पर विचलित होता है, तो फ़र्स्ट-रेंडर इनपुट्स की तुलना करें।

चरण 3: रेंडर पाथ से गैर-नियतता (nondeterminism) को हटाएं।

निम्नलिखित कोड सर्वर और ब्राउज़र को विभिन्न वातावरणों का उपयोग करने की अनुमति देता है और प्रत्येक रेंडर पर एक नया ID उत्पन्न करता है:

"use client"

export function StockNotice({ updatedAt }: { updatedAt: string }) {
  const isBrowser = typeof window !== "undefined"
  const theme = isBrowser ? localStorage.getItem("theme") ?? "light" : "light"
  const inputId = `stock-${Math.random()}`

  return (
    <section data-theme={theme}>
      <time dateTime={updatedAt}>{new Date(updatedAt).toLocaleString()}</time>
      <label htmlFor={inputId}>Back-in-stock alert</label>
      <input id={inputId} />
    </section>
  )
}

स्थिर मानों को सर्वर पर हल करना और उन सटीक मानों को Client Component के प्रारंभिक इनपुट के रूप में पास करना बेहतर है। यदि लोकेल, टाइमज़ोन और थीम URL, कुकी या प्रोफ़ाइल में उपलब्ध हैं, तो उन्हें सर्वर पर पढ़ें। डेट फ़ॉर्मेटिंग को एक स्पष्ट लोकेल और timeZone प्राप्त होना चाहिए। DOM IDs को useId का उपयोग करना चाहिए, बशर्ते सर्वर और क्लाइंट कंपोनेंट ट्री स्वयं समान रहें:

"use client"

import { useId } from "react"

interface StockNoticeProps {
  updatedAt: string
  updatedLabel: string
  initialTheme: "light" | "dark"
}

export function StockNotice({
  updatedAt,
  updatedLabel,
  initialTheme,
}: StockNoticeProps) {
  const inputId = useId()

  return (
    <section data-theme={initialTheme}>
      <time dateTime={updatedAt}>{updatedLabel}</time>
      <label htmlFor={inputId}>Back-in-stock alert</label>
      <input id={inputId} />
    </section>
  )
}

यदि सर्वर वास्तव में ब्राउज़र के टाइमज़ोन को नहीं जान सकता है, तो दोनों पक्षों पर समान UTC लेबल या निश्चित प्लेसहोल्डर रेंडर करें, फिर hydration के बाद इसे useEffect में बदलें। यह एक रेंडर जोड़ता है, इसलिए जगह आरक्षित करें और धीमे कनेक्शन पर विज़ुअल परिवर्तन का आकलन करें। बिज़नेस डेटा पर भी यही नियम लागू करें: HTML उत्पन्न करने वाले स्नैपशॉट को सीरियलाइज़ करें, पहले क्लाइंट रेंडर के लिए इसका उपयोग करें, और बैकग्राउंड रिफ़्रेश को केवल hydration के बाद दृश्य को अपडेट करने दें।

चरण 4: ब्राउज़र पार्सिंग और बाहरी म्यूटेशन का निरीक्षण करें।

ब्राउज़र अमान्य HTML को उदारतापूर्वक सुधारते हैं। पैराग्राफ के अंदर एक ब्लॉक या किसी अन्य बटन के अंदर एक बटन ऐसा पार्स किया गया DOM उत्पन्न कर सकता है जो React द्वारा एमिट की गई संरचना से भिन्न हो। सिमेंटिक्स और नेस्टिंग को ठीक करें, फिर HTML सत्यापन और DOM निरीक्षण के साथ सत्यापित करें। एक Effect अमान्य संरचना का सुधार नहीं है।

यदि विफलताएं केवल एज-कैश हिट पर होती हैं, तो ओरिजिन और एज रिस्पॉन्स की तुलना करें और HTML को फिर से लिखने वाले ट्रांसफ़ॉर्म को अक्षम करें। यदि वे केवल किसी एक्सटेंशन के साथ होते हैं, तो एक साफ प्रोफ़ाइल में रीप्रोड्यूस करें और पहचानें कि एक्सटेंशन ने React से पहले क्या बदला है। एप्लिकेशन उस प्रभाव को माप सकता है, लेकिन किसी अनियंत्रित एक्सटेंशन के होने के कारण उसे एप्लिकेशन के सभी वास्तविक mismatches को छिपाना नहीं चाहिए। थर्ड-पार्टी स्क्रिप्ट्स का भी इसी तरह विश्लेषण करें: उन्हें एक-एक करके प्रारंभिक पाथ से हटाएं और पहले DOM राइट की पहचान करें।

चरण 5: लागत के अनुसार एस्केप हैच चुनें।

useEffect उन एनवायरनमेंट डेटा के लिए उपयुक्त है जिन्हें केवल hydration के बाद पढ़ा जा सकता है, लेकिन यह दूसरा रेंडर बनाता है। ssr: false के साथ dynamic एक स्थानीय थर्ड-पार्टी कंपोनेंट के लिए उपयुक्त है जो सर्वर पर निष्पादित नहीं हो सकता है और कोई महत्वपूर्ण SEO या प्रारंभिक सामग्री नहीं रखता है। पूरे पेज को केवल-क्लाइंट रेंडरिंग में बदलना प्री-रेंडरिंग का त्याग करता है और खाली अवधि को बड़ा करता है। suppressHydrationWarning केवल एक उथले (shallow) एस्केप हैच के रूप में काम करता है, और React दबाए गए टेक्स्ट को पैच नहीं करता है। यह एक अपरिहार्य, पृथक अंतर के लिए है, न कि टाइमज़ोन, रैंडम ID, थीम या पुराने डेटा के सुधार के लिए।

चरण 6: फ़ेलियर मैट्रिक्स के साथ सुधार को साबित करें।

कम से कम दो लोकेल, दो टाइमज़ोन, लाइट और डार्क थीम, साइन-इन और अज्ञात स्थितियां, कैश हिट और मिस, सामान्य और विलंबित JavaScript, एक साफ प्रोफ़ाइल और एक ज्ञात एक्सटेंशन को कवर करें। प्रत्येक मामले के लिए पूर्ण रीलोड निष्पादित करें। पुष्टि करें कि कोई रिकवरेबल hydration त्रुटि नहीं होती है, महत्वपूर्ण सबट्री को बदला नहीं गया है, फ़ोकस और इवेंट व्यवहार सही बने रहते हैं, समय और थीम इच्छित बिंदु पर अपडेट होते हैं, और लेआउट स्पष्ट रूप से जंप नहीं करता है।

रेंडर में Date.now, Math.random, अंतर्निहित toLocaleString, window या localStorage, खतरनाक नेस्टिंग और व्यापक suppressHydrationWarning के लिए एक कोड समीक्षा पास जोड़ें। यह उसी वर्ग की गलती के माध्यम से किसी ठीक की गई घटना को वापस आने से रोकता है।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं पहले इस घटना को प्रारंभिक दस्तावेज़ लोड तक सीमित करूँगा। Next.js प्रारंभिक अनुरोध पर Client Components को प्री-रेंडर कर सकता है। ब्राउज़र द्वारा HTML प्राप्त करने के बाद, React को हैंडलर संलग्न करने से पहले समान प्रारंभिक इनपुट से समान ट्री का उत्पादन करना चाहिए। यह कंपोनेंट localStorage पढ़ता है, ब्राउज़र के डिफ़ॉल्ट टाइमज़ोन का उपयोग करता है, और रेंडर के दौरान एक रैंडम ID बनाता है, इसलिए तीनों मान सर्वर से भिन्न हो सकते हैं। React द्वारा इसे देखने से पहले रिच-टेक्स्ट संरचना को ब्राउज़र द्वारा सुधारा भी जा सकता है।

मैं एक वास्तविक घटना लूँगा और उसका पूरा कंपोनेंट स्टैक, डिप्लॉयमेंट, लोकेल, timeZone, थीम स्रोत और कैश स्थिति कैप्चर करूँगा। मैं नेटवर्क रिस्पॉन्स को सुरक्षित रखूँगा और React शुरू होने से पहले DOM के साथ इसकी तुलना करूँगा। यदि रिस्पॉन्स पहले से ही गलत है, तो मैं सर्वर स्नैपशॉट और CDN का निरीक्षण करूँगा। यदि पार्सिंग इसे बदलती है, तो मैं अमान्य नेस्टिंग, एक्सटेंशन और प्रारंभिक स्क्रिप्ट का निरीक्षण करूँगा। यदि यह केवल React शुरू होने पर बदलता है, तो मैं पहले क्लाइंट प्रॉप्स और एनवायरनमेंट शाखाओं की तुलना करूँगा।

सुधार के लिए, सर्वर कुकी या प्रोफ़ाइल से लोकेल, timeZone और प्रारंभिक थीम को हल करेगा, एक updatedLabel फ़ॉर्मेट करेगा, और इसे ISO समय के साथ पास करेगा। पहला क्लाइंट रेंडर उन मानों का सटीक रूप से उपयोग करेगा। मैं रैंडम ID को useId से बदल दूँगा और HTML सिमेंटिक्स को ठीक करूँगा। सर्वर के लिए अज्ञात ब्राउज़र जानकारी एक स्थिर प्लेसहोल्डर के साथ शुरू होगी और एक Effect में अपडेट होगी। बिज़नेस डेटा सीरियलाइज़्ड सर्वर स्नैपशॉट से शुरू होगा और hydration के बाद बैकग्राउंड में रिफ़्रेश होगा।

मैं SSR को विश्व स्तर पर अक्षम नहीं करूँगा या ठीक करने योग्य चेतावनी को नहीं दबाऊँगा। मैं स्थानीय ssr: false का उपयोग केवल ब्राउज़र-ओनली थर्ड-पार्टी लीफ़ के लिए करूँगा, और केवल एक अपरिहार्य एक-स्तरीय डिस्प्ले अंतर को दबाऊँगा। अंत में, मैं लोकेल, टाइमज़ोन, थीम, कैश, धीमे-नेटवर्क और साफ-ब्राउज़र संयोजनों में प्रोडक्शन कोल्ड लोड का परीक्षण करूँगा, और सत्यापित करूँगा कि कोई त्रुटि #418, सबट्री रिप्लेसमेंट, फ़ोकस हानि, या दृश्य फ़्लैश न हो।"

सामान्य गलतियाँ

• यह मान लेना कि "use client" का अर्थ है कोई सर्वर HTML नहीं है। एक Client Component को प्रारंभिक लोड पर भी प्री-रेंडर किया जा सकता है।
• दो UI रेंडर करने के लिए JSX में typeof window का उपयोग करना। सर्वर ब्रांच और ब्राउज़र का पहला रेंडर स्वाभाविक रूप से भिन्न हो सकते हैं।
• प्रत्येक मान को Effect में ले जाना और समाधान घोषित करना। यह दूसरा रेंडर, खाली सामग्री, लेआउट शिफ़्ट और धीमे नेटवर्क के खराब अनुभव को जोड़ते हुए बेमेल को केवल टाल सकता है।
• व्यापक रूट्स पर suppressHydrationWarning जोड़ना। यह उथला (shallow) है और React को बेमेल टेक्स्ट को पैच करने के लिए बाध्य नहीं करता है।
• प्रोडक्शन त्रुटि देखने के बाद पूरे पेज को ssr: false में बदलना। यह मूल कारण को स्पष्ट किए बिना प्री-रेंडरिंग के मूल्य को समाप्त करता है।
• केवल View Source की तुलना hydration के बाद के DOM से करना। यह React शुरू होने से पहले ब्राउज़र द्वारा पार्स किए गए DOM को छोड़ देता है।
• केवल लोकल डेवलपमेंट और क्लाइंट नेविगेशन का परीक्षण करना। मूल दोष को ट्रिगर करने के लिए एक प्रोडक्शन बिल्ड, पूर्ण रीलोड, एज कैश, टाइमज़ोन या एक्सटेंशन आवश्यक हो सकता है।
• कंसोल शांत होने पर रुक जाना। यह भी सत्यापित करें कि कोई रिप्लेसमेंट, गलत हैंडलर, फ़ोकस हानि, विज़ुअल फ़्लैश, या गलत बिज़नेस डेटा न हो।

फ़ॉलो-अप प्रश्न और उत्तर

हर टाइमस्टैम्प में suppressHydrationWarning क्यों नहीं जोड़ते?

यह एक-स्तरीय एस्केप हैच है, और React आपके लिए दबाए गए टेक्स्ट को पैच नहीं करता है। यदि टाइमस्टैम्प भिन्न होता है क्योंकि दो वातावरण अलग-अलग डिफ़ॉल्ट टाइमज़ोन का उपयोग करते हैं, तो एक स्पष्ट लोकेल और timeZone या एक साझा फ़ॉर्मेटेड मान कारण को ठीक करता है। सप्रेशन का उपयोग केवल तभी करें जब प्रोडक्ट जानबूझकर hydration के बाद भिन्न मान स्वीकार करता हो और अंतर को वास्तव में हटाया नहीं जा सकता हो। विज़ुअल व्यवहार और सहायक तकनीक (assistive technology) क्या पढ़ती है, दोनों को सत्यापित करें।

आप useEffect और ssr: false के बीच चयन कैसे करते हैं?

यदि कंपोनेंट में एक स्थिर शेल और मूल्यवान प्री-रेंडर की गई सामग्री है, लेकिन एक लेबल ब्राउज़र की जानकारी पर निर्भर करता है, तो SSR रखें और hydration के बाद उस छोटे हिस्से को अपडेट करें। यदि कोई संपूर्ण लीफ़ कंपोनेंट किसी थर्ड-पार्टी लाइब्रेरी पर निर्भर करता है जो सर्वर पर नहीं चल सकती है, जिसका कोई उपयोगी प्री-रेंडर किया गया आउटपुट नहीं है, और एक स्थिर आकार की लोडिंग स्थिति प्रदान कर सकता है, तो स्थानीय रूप से SSR को अक्षम करें। यह निर्णय सामग्री के मूल्य, निर्भरता सीमाओं और विज़ुअल लागत का पालन करता है, न कि उस विकल्प का जो चेतावनी को सबसे तेज़ी से गायब कर दे।

जब दोनों वातावरण समान React कोड चलाते हैं तो अमान्य HTML hydration को कैसे तोड़ सकता है?

सर्वर एक स्ट्रिंग भेजता है, और ब्राउज़र HTML पार्सिंग नियमों के अनुसार DOM का निर्माण और सुधार करता है। अमान्य नेस्टिंग स्वचालित रूप से बंद हो सकती है, स्थानांतरित हो सकती है या हटाई जा सकती है। इसलिए React मूल स्ट्रिंग द्वारा वर्णित ट्री के बजाय एक सुधारे गए ट्री को संभालता है। रिस्पॉन्स बॉडी की तुलना प्री-React DOM से करें, फिर सिमेंटिक्स को सही करें और HTML को मान्य करें।

जब केवल प्रोडक्शन में होने वाली विफलता रुक-रुक कर होती है तो आप ऑब्जर्वेबिलिटी कैसे जोड़ते हैं?

सैंपलिंग और प्राइवेसी फ़िल्टरिंग के साथ पूरी रिकवरेबल एरर या कोड, कंपोनेंट स्टैक, रूट, डिप्लॉयमेंट वर्ज़न, लोकेल, timeZone, थीम स्रोत, कैश स्थिति और ब्राउज़र प्रकार एकत्र करें। महत्वपूर्ण फ़र्स्ट-रेंडर इनपुट्स के लिए एक गैर-प्रतिवर्ती डाइजेस्ट या वर्ज़न रिकॉर्ड करें ताकि मानों को लॉग किए बिना सर्वर और क्लाइंट स्नैपशॉट की तुलना की जा सके। रूट, वर्ज़न और एनवायरनमेंट द्वारा मीट्रिक को स्लाइस करें। मरम्मत के बाद, पुष्टि करें कि त्रुटि दर शून्य तक पहुँचती है और सबट्री रिप्लेसमेंट, इंटरैक्शन और विज़ुअल मेट्रिक्स में कोई गिरावट नहीं आती है।