React मानसिक मॉडल: Dan Abramov-Style सोचने के तरीके

React तब तक मुश्किल लगता है जब तक आपके पास सही मानसिक मॉडल न हो

React शुरुआत में निराशाजनक लग सकता है क्योंकि आप UI के बदलने को देखते हैं, पर हमेशा समझ नहीं पाते कि उसने क्यों बदला। आप एक बटन क्लिक करते हैं, कुछ अपडेट होता है, और पेज का कोई दूसरा हिस्सा आपको चौंका देता है। यह आमतौर पर “React अजीब है” नहीं होता, बल्कि “React क्या कर रहा है, इस पर मेरी तस्वीर धुंधली है।” होता है।

एक मानसिक मॉडल वह सरल कहानी है जो आप खुद को बताते हैं कि कोई चीज़ कैसे काम करती है। अगर कहानी गलत है, तो आप आत्मविश्वास से ऐसे फैसले लेंगे जो उलझन पैदा करेंगे। थर्मोस्टैट के बारे में सोचिए: खराब मॉडल है “मैं 22°C सेट करता हूं, इसलिए कमरा तुरंत 22°C हो जाता है।” बेहतर मॉडल है “मैं लक्ष्य सेट करता हूं, और हीटर समय के साथ ऑन/ऑफ होता है ताकि लक्ष्य पहुंचे।” बेहतर कहानी के साथ व्यवहार रैंडम नहीं लगता।

React भी ठीक ऐसा ही है। कुछ स्पष्ट विचार अपनाने के बाद React predictable हो जाता है: आप वर्तमान डेटा देखकर भरोसे के साथ अनुमान लगा सकते हैं कि स्क्रीन पर क्या दिखेगा।

Dan Abramov ने इस “इसे predictable बनाओ” मानसिकता को लोकप्रिय किया। उद्देश्य नियम याद करना नहीं है। उद्देश्य यह है कि अपने सिर में कुछ छोटी सच्चाइयां रखें ताकि आप trial-and-error की बजाय reasoning से debug कर सकें।

इन विचारों को ध्यान में रखें:

• UI state का नतीजा है, मैन्युअल DOM edits का सेट नहीं।
• Components फंक्शन हैं जो बताती हैं कि UI कैसा होना चाहिए।
• Data नीचे की ओर प्रवाहित होती है; बदलाव events के जरिए ऊपर आते हैं।
• Side effects rendering से अलग होते हैं और उनका एक निर्धारित उद्देश्य होता है।

इनको पकड़े रखें और React जादू नहीं बल्कि एक भरोसेमंद सिस्टम लगने लगेगा।

Components, props, और state: मूल तस्वीर

React तब आसान होता है जब आप “स्क्रीन” की बजाय छोटे टुकड़ों में सोचना शुरू कर देते हैं। एक component UI की एक reusable इकाई है। यह इनपुट लेता है और उन इनपुट्स के लिए UI का एक विवरण लौटाता है।

एक component को शुद्ध विवरण के रूप में मानना मदद करता है: “इस डेटा के साथ, यह दिखाओ।” यह विवरण कई जगह उपयोग किया जा सकता है क्योंकि यह इस बात पर निर्भर नहीं करता कि वह कहाँ रहता है।

Props इनपुट हैं। वे parent component से आते हैं। Props किसी component के “owned” नहीं होते, और component को उन्हें चुपचाप बदलाना नहीं चाहिए। अगर किसी बटन को label="Save" मिलता है, तो बटन का काम वह label रेंडर करना है, न कि उसे बदलने का फैसला करना।

State owned डेटा है। यह वह है जो component समय के साथ याद रखता है। State तब बदलता है जब यूज़र इंटरैक्ट करता है, कोई request खत्म होती है, या आप निर्णय लेते हैं कि कुछ अलग होना चाहिए। Props के उलट, state उस component (या जिसे आपने owner चुना है) का होता है।

मुख्य विचार का साधारण रूप: UI state का फ़ंक्शन है। अगर state कहती है “loading,” तो spinner दिखाओ। अगर state कहती है “error,” तो संदेश दिखाओ। अगर state कहती है “items = 3,” तो तीन rows रेंडर करो। आपका काम UI को state से पढ़ना रखना है, छुपी हुई वैरिएबल्स में नहीं फँसना।

कॉन्सेप्ट अलग करने का एक त्वरित तरीका:

• Component: UI का टुकड़ा (SearchBox, ProfileCard, CheckoutForm)
• Props: जिसे दिखाने के लिए चाहिए (name, price, disabled)
• State: जो याद रखा जाता है (isOpen, query, selectedId)

उदाहरण: एक modal। Parent title और onClose props के रूप में पास कर सकता है। Modal अपना isAnimating state रख सकता है।

यहाँ तक कि अगर आप chat के माध्यम से UI जनरेट कर रहे हैं (उदाहरण के लिए Koder.ai पर), यह separation अभी भी सबसे तेज़ तरीका है शान्त रहने का: पहले props बनाम state तय करें, फिर UI को उस हिसाब से बनने दें।

Rendering और re-rendering: असल में क्या बदलता है

React को अपने दिमाग में रखने का एक उपयोगी तरीका (बहुत Dan Abramov की भावना में) है: rendering एक calculation है, paint job नहीं। React आपके component functions चलाता है यह पता करने के लिए कि current props और state के लिए UI कैसा होना चाहिए। आउटपुट एक UI विवरण है, पिक्सल नहीं।

एक re-render का मतलब बस यह है कि React वह calculation दोहराता है। इसका मतलब यह नहीं कि “पूरे पेज को फिर से बनाया गया।” React नए परिणाम की तुलना पिछले परिणाम से करता है और असली DOM पर सबसे छोटे बदलाव लागू करता है। कई components re-render हो सकते हैं जबकि केवल कुछ DOM nodes ही actually अपडेट होते हैं।

अधिकांश re-renders कुछ सरल कारणों से होते हैं: किसी component का state बदला, उसके props बदले, या parent ने re-render किया और React ने बच्चे से फिर से render करने को कहा। आखिरी वाला लोगों को चौंका देता है, पर यह आम तौर पर ठीक होता है। अगर आप render को “सस्ता और बोरिंग” मानते हैं, तो आपका ऐप समझना आसान रह जाता है।

जो नियम इसको साफ़ रखता है: render को pure बनाओ। एक ही inputs (props + state) मिलने पर, आपका component वही UI विवरण लौटाना चाहिए। render में surprises न रखें।

ठोस उदाहरण: अगर आप render के अंदर Math.random() से ID जनरेट करते हैं, तो re-render पर वह बदल जाएगा और अचानक एक checkbox का focus हट सकता है या list item remount हो सकता है। ID को एक बार बनाइए (state, memo, या component के बाहर) ताकि render स्थिर रहे।

अगर आप एक वाक्य याद रखें: एक re-render का मतलब है “UI क्या होना चाहिए इसकी पुनः गणना,” न कि “सब कुछ फिर से बनाना।”

State updates: बदलाव छोटे और predictable रखें

एक और मददगार मॉडल: state updates requests हैं, तुरन्त असाइनमेंट नहीं। जब आप setCount(count + 1) जैसे setter को कॉल करते हैं, तो आप React से नए वैल्यू के साथ render शेड्यूल करने का अनुरोध कर रहे होते हैं। अगर आप तुरंत state पढ़ते हैं, तो आप शायद अभी भी पुरानी वैल्यू देखेंगे क्योंकि React ने अभी render नहीं किया।

इसीलिए “छोटे और predictable” अपडेट महत्वपूर्ण होते हैं। जब अगली वैल्यू पिछली पर निर्भर हो, तो updater फॉर्म का उपयोग करें: setCount(c => c + 1). यह React के काम करने के तरीके से मेल खाता है: कई अपडेट कतार में लग सकते हैं, फिर क्रम में लागू होते हैं।

Immutable बनना तस्वीर का दूसरा हिस्सा है। ऑब्जेक्ट्स और arrays को जगह पर न बदलें। बदलाव के साथ नया बनाएं। तब React देख सकता है “यह वैल्यू नई है,” और आपका दिमाग ट्रेस कर सकता है कि क्या बदला।

उदाहरण: एक todo आइटम toggle करना। सुरक्षित तरीका है नया array बनाना और उस एक item के लिए नया todo object बनाना। जोखिम भरा तरीका है मौजूद array के अंदर todo.done = !todo.done बदलना।

साथ ही state को न्यूनतम रखें। एक आम जाल वह है जहाँ आप वो वैल्यूज़ स्टोर करते हैं जिन्हें आप कैलकुलेट कर सकते हैं। अगर आपके पास पहले items और filter हैं, तो filteredItems को state में न रखें। इसे render के दौरान कैलकुलेट करें। कम state variables का मतलब कम संभावनाएँ कि वैल्यूज़ sync से बाहर हो जाएं।

क्या state में होना चाहिए इसका एक सरल टेस्ट:

• स्टोर करें अगर यह समय के साथ बदल सकता है और UI को उस पर प्रतिक्रिया करनी चाहिए।
• स्टोर न करें अगर यह अन्य state या props से निकाला जा सकता है।
• एक ही सच को दो जगह दोहराकर न रखें।

अगर आप chat के जरिए UI बना रहे हैं (जिसमें Koder.ai भी शामिल है), तो बदलावों के लिए छोटे पैच मांगें: “एक boolean flag जोड़ो” या “इस list को immutable तरीके से अपडेट करो।” छोटे, स्पष्ट बदलाव generator और आपके React कोड को aligned रखते हैं।

Effects syncing के लिए हैं, बेसिक UI लॉजिक के लिए नहीं

Rendering UI का वर्णन करता है। Effects बाहर की दुनिया के साथ sync करते हैं। “बाहर” का मतलब उन चीज़ों से है जिन्हें React नियंत्रित नहीं करता: network calls, timers, ब्राउज़र APIs, और कभी-कभी imperative DOM काम।

अगर कुछ props और state से कैलकुलेट किया जा सकता है, तो आम तौर पर उसे effect में नहीं होना चाहिए। Effect में रखने से एक दूसरा कदम जुड़ जाता है (render, effect चलना, state सेट करना, फिर फिर से render)। यही extra hop flickers, loops, और “क्यों यह stale है?” जैसी बग्स का स्रोत बनता है।

एक आम उलझन: आपके पास firstName और lastName हैं, और आप fullName को effect से state में रख रहे हैं। पर fullName साइड इफ़ेक्ट नहीं है। यह derivable डेटा है। इसे render के दौरान कैलकुलेट करें और यह हमेशा मेल खाएगा।

एक आदत के रूप में: UI वैल्यूज़ render के दौरान derive करें (या अगर महंगा हो तो useMemo का उपयोग करें), और effects का उपयोग “कुछ करो” वाले कामों के लिए करें, न कि “कुछ पता लगाओ” वाले कामों के लिए।

dependency array एक trigger list है

dependency array को ऐसे समझें: “जब ये वैल्यूज़ बदलें, तब बाहर की दुनिया के साथ पुनः sync करें।” यह प्रदर्शन का ट्रिक नहीं है और न ही warnings न दबाने की जगह।

उदाहरण: अगर आप userId बदलने पर user details fetch करते हैं, तो userId dependency array में होना चाहिए क्योंकि यह sync trigger करता है। अगर effect token भी उपयोग करता है, तो उसे भी शामिल करें, वरना आप पुराने token के साथ fetch कर सकते हैं।

एक अच्छा gut-check: अगर effect हटाने से सिर्फ UI गलत होगा, तो शायद वह असली effect नहीं था। अगर हटाने से timer बंद हो जाएगा, subscription रद्द होगा, या fetch छूट जाएगा, तो संभवतः वह effect था।

Data flow: एक स्रोत सच्चाई कई बिखरे state से बेहतर है

सबसे उपयोगी मानसिक मॉडलों में से एक सरल है: डेटा ट्री के नीचे जाता है, और यूज़र क्रियाएँ ऊपर आती हैं।

एक parent child को वैल्यूज़ पास करता है। बच्चे उसी वैल्यू को दो जगह “own” नहीं करना चाहिए। वे बदलावों का अनुरोध एक फ़ंक्शन कॉल करके करते हैं, और parent तय करता है नई वैल्यू क्या होगी।

जब UI के दो हिस्सों को सहमत होना चाहिए, तो एक जगह चुनकर वैल्यू वहाँ रखें, फिर उसे नीचे पास करें। इसे "lifting state" कहते हैं। यह प्लम्बिंग जैसा लग सकता है, पर यह एक बदतर समस्या रोکتا है: दो state जो अलग हो जाएँ और आपको उन्हें sync रखने के लिए hacks जोड़ने पड़ें।

उदाहरण: एक search box और results list। अगर input अपनी query रखता है और list अपनी query रखती है, तो आप अंततः देखेंगे “input X दिखाता है लेकिन list Y उपयोग करती है।” समाधान है query को एक parent में रखना, उसे दोनों को पास करना, और input को onChangeQuery(newValue) handler देना।

हमीशा lifting ही जवाब नहीं होता। अगर कोई वैल्यू सिर्फ एक component के अंदर मायने रखती है, तो उसे वहीं रखें। जहाँ state इस्तेमाल होती है उसके पास रखना कोड को पढ़ने में आसान बनाता है।

एक व्यावहारिक सीमा:

• Local state: UI-केवल विवरण (dropdown open, कौन सा tab हाइलाइट है)
• Shared state: डेटा जिसे कई components को सहमति से चाहिए (filters, selected item, auth status)

अगर आप unsure हैं कि state उठानी चाहिए या नहीं, तो संकेत देखें: दो components एक ही वैल्यू अलग-अलग दिखाते हैं; एक जगह पर action कुछ दूर के हिस्से को अपडेट करता है; आप props को state में "सिर्फ केस के लिए" कॉपी कर रहे हैं; या आप दो वैल्यूज़ को align रखने के लिए effects जोड़ रहे हैं।

यह मॉडल chat टूल्स जैसे Koder.ai के साथ बनाते समय भी मदद करता है: हर shared state के लिए एक owner पूछें, फिर upward flow वाले handlers जनरेट करें।

कदम दर कदम: पहले state ड्रॉ करके फीचर डिज़ाइन करें

एक फीचर चुनें जो आपके सिर में आराम से फिट हो। एक अच्छा उदाहरण है एक searchable list जहाँ आप किसी आइटम पर क्लिक करके details modal देख सकते हैं।

पहले UI हिस्सों और हो सकने वाले events को स्केच करें। अभी कोड के बारे में मत सोचें। सोचें कि यूज़र क्या कर सकता है और क्या देख सकता है: एक search input है, एक list है, एक selected row highlight है, और एक modal है। events हैं: search में टाइप करना, किसी आइटम पर क्लिक करना, modal खोलना, और modal बंद करना।

अब “state को ड्रॉ करें।” उन कुछ वैल्यूज़ को लिखें जो स्टोर करनी जरूरी हैं, और तय करें कौन उनका owner होगा। एक सरल नियम काम करता है: जिन सब जगहों को उस वैल्यू की जरूरत है उनका सबसे नज़दीकी साझा parent उसे own करे।

इस फीचर के लिए store की गई state छोटी हो सकती है: query (string), selectedId (id या null), और isModalOpen (boolean). List query पढ़कर items रेंडर करती है। Modal selectedId पढ़कर details दिखाता है। अगर list और modal दोनों को selectedId चाहिए, तो उसे parent में रखें, न कि दोनों में।

अगले, derived data और stored data को अलग करें। filtered list derived है: filteredItems = items.filter(...). इसे state में न रखें क्योंकि यह हमेशा items और query से recompute किया जा सकता है। Derived data स्टोर करने से वैल्यूज़ अलग पड़ने लगती हैं।

फिर पूछें: क्या हमें effect चाहिए? अगर items पहले से memory में हैं, तो नहीं। अगर query टाइप करने पर results fetch करनी है तो हाँ। अगर modal बंद करने पर कुछ save करना है तो हाँ। Effects syncing के लिए हैं (fetch, save, subscribe), बेसिक UI wiring के लिए नहीं।

अंत में कुछ edge cases के साथ फ्लो टेस्ट करें:

• तेज़ी से टाइप करें, फिर इनपुट साफ़ करें: क्या list सामान्य हो जाती है?
• किसी आइटम पर क्लिक करें, फिर list search की वजह से बदल जाए: क्या selectedId अभी भी वैध है?
• Modal बंद करें: क्या आप selection रखते हैं या reset करते हैं?
• Server से items refresh हों: अगर selected item गायब हो जाए तो क्या होता है?

अगर आप कागज़ पर इनका जवाब दे सकते हैं, तो React कोड आमतौर पर सीधा होता है।

सामान्य गलतियाँ जो मानसिक मॉडल तोड़ देती हैं

ज्यादातर React उलझन syntax के बारे में नहीं होती। यह तब होती है जब आपका कोड आपके सिर में रखी साधारण कहानी से मेल नहीं खाता।

गलती पैटर्न (और आप जो लक्षण देखते हैं)

Derived state स्टोर करना. आप fullName state में रख लेते हैं जबकि यह सिर्फ firstName + lastName है। यह तब तक काम करता है जब तक एक फील्ड बदलता है और दूसरा नहीं, और UI stale दिखाने लगता है।

Effect loops. एक effect data fetch करता है, state सेट करता है, और dependency list उसे फिर से चलाने देती है। लक्षण है बार-बार requests, jittery UI, या state जो सुलझती ही नहीं।

Stale closures. एक click handler पुरानी वैल्यू पढ़ता है (जैसे outdated counter या filter)। लक्षण है “मैंने क्लिक किया, पर उसने कल की वैल्यू इस्तेमाल की।”

Global state हर जगह. हर UI डिटेल को global store में डालने से यह बताना मुश्किल हो जाता है कि किसका मालिक कौन है। लक्षण है कि आप एक चीज बदलते ही तीन screens में अप्रत्याशित बदलाव आते हैं।

Nested objects को mutate करना. आप किसी ऑब्जेक्ट या array को जगह पर बदलते हैं और आश्चर्य करते हैं कि UI अपडेट क्यों नहीं हुआ। लक्षण है “डेटा बदल गया, पर कोई re-render नहीं हुआ।”

यहाँ एक ठोस उदाहरण: एक “search और sort” पैनल। अगर आप filteredItems को state में रखते हैं, तो यह items से अलग पड़ सकता है जब नया data आये। इसके बजाय inputs (search text, sort choice) रखें और filtered list को render में compute करें।

Effects के साथ, उन्हें बाहर की दुनिया के साथ sync के लिए रखें (fetching, subscriptions, timers)। अगर effect बेसिक UI काम कर रहा है, तो अक्सर वह render या event handler में होना चाहिए।

जब आप chat के जरिए कोड जनरेट/एडिट कर रहे हों, ये गलतियाँ जल्दी दिखती हैं क्योंकि परिवर्तन बड़े chunks में आ सकते हैं। एक अच्छी आदत है अनुरोधों को ownership के संदर्भ में framed करना: “इस वैल्यू का source of truth क्या है?” और “क्या हम इसे store कर सकते हैं या compute कर सकते हैं?”

जब state उलझन में लगे तो त्वरित चेकलिस्ट

जब आपका UI अप्रत्याशित लगे, तो समस्या आमतौर पर "बहुत ज्यादा React" नहीं होती। यह अक्सर गलत जगहों पर बहुत ज्यादा state होने की वजह होती है जो वह काम कर रही है जो उसे नहीं करना चाहिए।

किसी और useState को जोड़ने से पहले रुके और पूछें:

• सबसे छोटी वैल्यूज़ कौन-सी हैं जो पूरी तरह बताते हैं कि यूज़र अभी क्या देख रहा है?
• हर वैल्यू कहाँ रहनी चाहिए ताकि जिन हिस्सों को उसे पढ़ना है वे पढ़ सकें, और जिनको नहीं चाहिए वे शांत रहें?
• क्या यह वैल्यू वास्तव में नई जानकारी है, या आप इसे props, URL params, या अन्य state से compute कर सकते हैं?
• क्या आप किसी effect का उपयोग UI कैलकुलेट करने के लिए कर रहे हैं, या केवल React के बाहर कुछ sync करने के लिए (network, timers, browser APIs)?
• अगर एक वैल्यू बदलेगी, तो किन components को re-render होना चाहिए क्योंकि वे उसे पढ़ते हैं, और किन्हें नहीं?

छोटा उदाहरण: search box, filter dropdown, list. अगर आप query और filteredItems दोनों को state में रखते हैं तो अब आपके पास दो sources of truth हैं। इसके बजाय query और filter रखें state में, फिर filteredItems को render में derive करें।

यह तब महत्वपूर्ण है जब आप chat tools से जल्दी बना रहे हों। गति अच्छी है, पर लगातार पूछते रहें: “क्या हमने state जोड़ा, या गलती से derived वैल्यू जोड़ दी?” अगर derived है, तो वह state हटाकर उसे compute करें।

उदाहरण: तेज़ी से UI पर iterate करें बिना predictability खोए

एक छोटी टीम admin UI बना रही है: orders की एक तालिका, कुछ filters, और एक dialog order edit के लिए। पहले request अस्पष्ट होता है: “Filters जोड़ो और एक edit popup।” यह सरल लगता है, पर अक्सर यह बेतरतीब state फैलाने में बदल जाता है।

इसे concrete बनाइए: request को state और events में अनुवादित करें। “Filters” कहने के बजाय state का नाम दें: query, status, dateRange. “Edit popup” कहने के बजाय event नाम दें: “user clicks Edit on a row.” फिर तय करें कौन-सा state किसका owner है (page, table, या dialog) और क्या derive हो सकता है (जैसे filtered list)।

उदाहरण prompts जो मॉडल को कायम रखते हैं (ये chat-based builders जैसे Koder.ai में भी अच्छे हैं):

• “Create an OrdersPage that owns filters and selectedOrderId. OrdersTable is controlled by filters and calls onEdit(orderId).”
• “Derive visibleOrders from orders and filters. Do not store visibleOrders in state.”
• “Add an EditOrderDialog that receives order and open. When saved, call onSave(updatedOrder) and close.”
• “If data is fetched, keep it in one place. Use an effect only to sync filters to the URL, not to compute filtered rows.”

UI generate या update होने के बाद, एक त्वरित समीक्षा करें: हर state वैल्यू का एक owner हो, derived वैल्यूज़ स्टोर न हों, effects सिर्फ बाहर की दुनिया के साथ sync करें (URL, network, storage), और events नीचे props के रूप में जाएँ और ऊपर callbacks के रूप में आएँ।

जब state predictable होता है, iteration सुरक्षित लगता है। आप table layout बदल सकते हैं, नया filter जोड़ सकते हैं, या dialog fields को tweak कर सकते हैं बिना यह अनुमान लगाए कि कौन-सा छुपा state टूट जाएगा।

अगला कदम: chat से तेज़ बनाएं, पर React मॉडल रखें

गति तभी उपयोगी है जब ऐप समझना आसान रहे। सबसे सरल सुरक्षा यह है कि इन मानसिक मॉडलों को एक चेकलिस्ट की तरह अपनाएं जो आप कोड लिखने (या जनरेट करने) से पहले लगाते हैं।

हर फीचर को एक ही तरीके से शुरू करें: उन state को लिखें जो चाहिए, वे कौन से events बदल सकते हैं, और कौन उनका owner है। अगर आप स्पष्ट तौर पर नहीं कह सकते, “यह component यह state own करता है, और ये events इसे अपडेट करते हैं,” तो आप संभवतः बिखरी state और अप्रत्याशित re-renders के साथ खत्म होंगे।

अगर आप chat के जरिए बना रहे हैं, तो planning mode से शुरू करें। components, state shape, और transitions को साधारण भाषा में समझाइए फिर कोड के लिए कहिए। उदाहरण: “A filter panel updates query state; the results list derives from query; selecting an item sets selectedId; closing clears it.” जब यह साफ़ पढ़ता है, UI जनरेट करना यांत्रिक कदम बन जाता है।

अगर आप Koder.ai (koder.ai) का उपयोग कर रहे हैं React code जनरेट करने के लिए, तो एक छोटी sanity pass करना फायदेमंद है: हर state वैल्यू का एक स्पष्ट owner, UI state से derive हो, effects सिर्फ syncing के लिए, और किसी भी सच का डुप्लीकेट न हो।

फिर छोटे कदमों में iterate करें। अगर आप state structure बदलना चाहते हैं (उदाहरण के लिए कई booleans से एक single status field में), तो पहले एक snapshot लें, प्रयोग करें, और अगर mental model खराब हुआ तो rollback करें। और जब deeper review या handoff की जरूरत हो, तो source code export करना आसान बनाता है यह देखने के लिए कि क्या state shape अभी भी UI की कहानी बता रहा है।