React 19

 (github.com/facebook)
2 पॉइंट द्वारा GN⁺ 2024-12-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें

19.0.0 (5 दिसंबर 2024)

नई सुविधाएँ

React
  • Actions: startTransition अब asynchronous functions को स्वीकार कर सकता है। इन functions को "Actions" कहा जाता है, और ये background में state को update करते हैं तथा UI को एक साथ commit करते हैं। Actions asynchronous requests जैसे side effects चला सकते हैं, और Transition पूरा होने से पहले काम के पूरा होने का इंतज़ार करते हैं।
  • useActionState: Transition के भीतर Actions को क्रमबद्ध करने और state तक पहुँचने के लिए एक नया hook। यह initial state और reducer को स्वीकार करता है।
  • useOptimistic: Transition के चलने के दौरान state को update करने के लिए एक नया hook। Transition पूरा होने पर state नए value से update हो जाती है।
  • use: rendering के समय resources पढ़ने के लिए एक नया API। यह Promise या Context को स्वीकार करता है, और Promise दिए जाने पर value resolve होने तक suspend करता है।
  • ref को prop के रूप में उपयोग: अब forwardRef की ज़रूरत के बिना ref को prop के रूप में इस्तेमाल किया जा सकता है।
  • Suspense sibling pre-warming: जब कोई component suspend होता है, तो React सबसे नज़दीकी Suspense boundary के fallback को तुरंत commit करता है।
React DOM client
  • <form> action prop: Form Actions अपने-आप forms को manage करते हैं और useFormStatus के साथ integrate होते हैं। सफलता पर form अपने-आप reset हो जाता है।
  • document metadata support: document metadata tags को components से native तरीके से render किया जा सकता है।
  • stylesheet support: Suspense boundary के content को दिखाने से पहले client के <head> में stylesheets insert की जाती हैं।
  • asynchronous script support: component tree में कहीं से भी asynchronous scripts render की जा सकती हैं।
React DOM server
  • prerender और prerenderToNodeStream API जोड़े गए: static site generation के लिए APIs, जिन्हें Node.js streams और web streams जैसे streaming environments में काम करने के लिए डिज़ाइन किया गया है।
React server components
  • RSC features: directives, server components, और server functions अब stable हो गए हैं। server components शामिल करने वाली libraries अब React 19 को peer dependency के रूप में target कर सकती हैं।

Deprecated होने वाली चीज़ें

  • element.ref access: element.props.ref को प्राथमिकता देते हुए element.ref access को deprecated किया गया है।
  • react-test-renderer: React 19 में react-test-renderer deprecation warning log करता है और web usage के लिए concurrent rendering पर switch करता है।

मुख्य बदलाव

React
  • नया JSX transform अनिवार्य: bundle size बेहतर करने और React import किए बिना JSX इस्तेमाल करने के लिए नया JSX transform आवश्यक है।
  • rendering errors दोबारा throw नहीं होते: यदि error को Error Boundary नहीं पकड़ती, तो उसे window.reportError में report किया जाता है।
  • propTypes हटाए गए: propTypes का उपयोग अब चुपचाप ignore किया जाता है। TypeScript पर migration की सिफारिश की जाती है।
  • functions के defaultProps हटाए गए: इसकी जगह ES6 default parameters का उपयोग किया जा सकता है।
  • string refs हटाए गए: string refs के उपयोग को ref callbacks में migrate करना होगा।
React DOM
  • react-dom/test-utils हटाया गया: act को react-dom/test-utils से react में move किया गया है। बाकी utilities हटा दी गई हैं।
  • ReactDOM.render, ReactDOM.hydrate हटाए गए: इन्हें concurrent rendering के लिए ReactDOM.createRoot और ReactDOM.hydrateRoot से replace किया गया है।

उल्लेखनीय बदलाव

React
  • <Context> को provider के रूप में उपयोग: <Context.Provider> की जगह <Context> को provider के रूप में render किया जा सकता है।
  • custom element support: React 19 सभी custom element tests पास करता है।
  • StrictMode changes: useMemo और useCallback पहली rendering के memoization result को reuse करते हैं।
React DOM
  • hydration errors के लिए diff: mismatch होने पर, React 19 mismatched content के differences सहित एक single error log करता है।

TypeScript बदलाव

  • implicit returns निषिद्ध: refs अब केवल cleanup functions स्वीकार करते हैं। implicit return अब error पैदा करेगा।
  • useRef का initial argument आवश्यक: initial argument अब अनिवार्य है।
  • कड़ा ReactElement typing: React elements के props अब any की जगह default रूप से unknown होते हैं।

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

1 टिप्पणियां

 
GN⁺ 2024-12-06
Hacker News की राय

  • मुझे ठीक से समझ नहीं आता कि यहाँ इतने लोग React से नफ़रत क्यों करते हैं
    मैंने अपना करियर Laravel और plain JS से शुरू किया था, लेकिन React इस्तेमाल करने के बाद scalable apps बनाना व्यावहारिक लगा और frontend भी मज़ेदार हो गया
    कंपनी बदलने पर भी React को फिर से पकड़ना आसान होता है, और TypeScript support व बड़े ecosystem की वजह से यह महसूस होता है कि काफ़ी आसानी से कुछ भी बनाया और बढ़ाया जा सकता है
    यह भी समझ नहीं आता कि नई features लोगों को इतना डराती क्यों हैं। अब भी SPA या पुराने तरीक़े से बनाया जा सकता है, और यह कुछ वैसा ही है जैसे NoSQL DB, Spring Boot, या Kotlin आने पर भी अगर इस्तेमाल नहीं करना हो तो न करो
    मुझे लगा था कि Jetpack Compose और SwiftUI भी React से प्रेरित हैं; शायद मैंने यह पहले Android docs में देखा था, लेकिन अब नहीं मिल रहा
    हालाँकि मुझे अभी कई दशकों का अनुभव नहीं है, इसलिए यह नहीं जानता कि पहले बड़े teams के लिए jQuery या plain JS से Airbnb जैसे बड़े web apps बनाना कितना सुखद था। अब तो state management, DOM manipulation, और side effects को plain JS से कैसे संभालें, यह कल्पना करना भी मुश्किल लगता है
    हो सकता है कि किसी दिन मैं भी किसी नए framework की शिकायत करूँ और कहूँ कि React अच्छा था

    • React के प्रति यह विरोध ज़्यादातर उन लोगों से आता दिखता है जिन्होंने शायद इसे वास्तव में ज़्यादा इस्तेमाल ही नहीं किया, इसलिए यह मुझे समझ नहीं आता
      आमतौर पर तर्क यह होता है कि “frontend हमेशा नई और चमकदार चीज़ों के पीछे भागता है और React भी उन्हीं में से एक है”, लेकिन React 2013 से है और 2015 के आसपास से काफ़ी mainstream भी था
      यह भी कहा जाता है कि framework और libraries complexity बढ़ाते हैं, लेकिन जब पूछा जाए कि कौन-सी complexity, तो लगभग कभी ठोस जवाब नहीं मिलता। अगर आप बिना framework के कोई meaningful app बनाते हैं, तो आख़िर में आप अपना ही ऐसा framework बना लेते हैं जिसमें management, testing, और documentation की कमी होती है
      compile और bundling step की भी अक्सर शिकायत होती है, लेकिन अब Expo, Next.js, और Meteor जैसे proven frameworks हैं, इसलिए webpack config या build pipeline ख़ुद लिखने की ज़रूरत लगभग नहीं रह गई है
    • ज़्यादातर websites को शुरू से ही app होने की ज़रूरत नहीं होती। कुछ को होती है, लेकिन उन मामलों में भी आम तौर पर custom build की ज़रूरत पड़ती है
      हर जगह web framework ठूँसने का जो चलन रहा, उसने पिछले 10 सालों में धीमी और आसानी से टूटने वाली sites की भरमार कर दी, और बहुत-सी sites overengineered होने के बावजूद 2008 के user experience से बहुत बेहतर भी नहीं बन पाईं
      कुछ frontend developers के लिए सवाल कुछ भी हो, जवाब React / Node / Vite / Angular / Vue / Nuxt / Next / Bun / Deno / Svelte / SvelteKit वगैरह का कोई combination होता है, और बेहतर होगा कि वह Kubernetes द्वारा नियंत्रित दर्जनों Docker swarms पर चले। “तुम बस अपना résumé online डालना चाहते हो? तो चलो अगले 3 हफ़्ते app के state flow diagram बनाते हैं” जैसी स्थिति हो जाती है
      React को शायद इसलिए ख़ास तौर पर ज़्यादा गालियाँ पड़ रही हैं क्योंकि framework trends के पीछे भागने वाले लोग तो अब अगली चमकदार चीज़ पर जा चुके हैं, और जिन्हें शुरू से ऐसे frameworks पसंद नहीं थे वे अब भी उन्हें नापसंद करते हैं, इसलिए इस पूरे झंझट का बचाव करने वाला कोई नहीं बचा। लगता है बाक़ी frameworks का भी समय आने पर यही हाल होगा
    • मेरे हिसाब से class-era React एक ठीक-ठाक, सामान्य, थोड़ा उबाऊ लेकिन उपयोगी UI framework था। वहीं hooks का इस्तेमाल करना काफ़ी मुश्किल है
      इसका असली काम करने का तरीक़ा बहुत छिपा हुआ है, सहज नहीं लगता, गलती करना आसान है, और low-performance UI भी आसानी से लिखी जा सकती है
      क्या कितनी बार चलेगा, dependency array में क्या डालना है, useCallback और useEffect में क्या डालना है—इन सबके बारे में लगातार सोचना पड़ता है, इसलिए cognitive load ज़्यादा है
      community का एक हिस्सा project के लिए ज़रूरी न होने वाली React dependencies भी सुझाता रहता है, जिससे सिर्फ़ overhead और complexity बढ़ती है
      business logic और UI logic का आपस में घुल-मिल जाना भी आसान है
    • jQuery बड़े और complex apps बनाते समय बुरी तरह टूट जाता था। जिसने सच में वह दौर देखा है, वह शायद उसे याद करके खुश नहीं होगा
      कुछ समय तक SPA की MPA की तुलना में कमियाँ थीं, लेकिन आधुनिक web standards और SPA frameworks में server-side rendering आने के बाद वे समस्याएँ अब लगभग सुलझ चुकी हैं
    • यह कहना सही नहीं है कि “NoSQL DB आने पर किसी ने शिकायत नहीं की थी।” हममें से कई लोगों ने MongoDB कितना ख़राब है, इस बारे में काफ़ी ज़ोर से शिकायत की थी
      https://www.youtube.com/watch?v=b2F-DItXtZs

  • शानदार रिलीज़ है, लेकिन यह भी लगता है कि जो लोग अभी frontend development में शुरुआत कर रहे हैं, उनके लिए थोड़ा बुरा समय है
    “Transition के अंदर Action को क्रमबद्ध करने वाला, action state और pending state तक पहुंच देने वाला नया hook, जो Action को कॉल कर सकने वाला reducer और first render के लिए initial state लेता है, और form action prop को दिए जाने पर form के progressive enhancement को support करने के लिए एक वैकल्पिक string भी लेता है” जैसी व्याख्याएं फीचर तो अच्छी लगती हैं, लेकिन बहुत ज़्यादा लंबी-चौड़ी हैं
    अगर आज वेबसाइट डेवलपमेंट शुरू करना हो, तो कहां से शुरू करें यह समझना मुश्किल लगेगा
    फिर भी React अब भी एक बेहतरीन framework है और यह रिलीज़ भी सुधार ही है। आलोचना सिर्फ React की नहीं, बल्कि frontend development पूरी तरह जिस दिशा में गया है, उसकी ज़्यादा है

    • एक टिप दूं तो, अगर संभव हो तो React को पूरी तरह avoid करने से शुरू करूंगा
      पुराने ढंग के server-side rendering के साथ HTMX जैसी चीज़ का इस्तेमाल करना कहीं बेहतर है
      मैंने React frontend development से 4 साल तक पैसे कमाए हैं और 2005 में अपनी पहली वेबसाइट बनाई थी, और अभी एक client project को React से HTMX में migrate कर रहा हूं, और यह मुझे काफी बेहतर लग रहा है
      bugs भी कम हैं, और hooks को गलत इस्तेमाल करने से पैदा होने वाले traps भी कम हैं
      अगर client-side rendering की ज़रूरत हो तो मैं Solid या Vue चुनूंगा, लेकिन React से बचूंगा। अगर आपके पास विकल्प नहीं है, तो शुभकामनाएं
    • React एक दिलचस्प approach था, लेकिन मुझे लगता है कि शुरुआत से ही कुछ warning signs को नज़रअंदाज़ किया गया था
      unidirectional binding, virtual DOM, rerendering, और diff calculation जैसी बुनियादी धारणाएं शुरू से ही मुझे मूल रूप से तर्कसंगत नहीं लगीं। मतलब browser memory दोगुनी इस्तेमाल करना, और हर interaction पर पूरा rerender और diff calculation करना
      उस समय जवाब था “पहले इसे reliable बनाते हैं, फिर fast बनाएंगे”, लेकिन अब यह fast बनाने के लिए किए गए hacky ढांचों से भरा पड़ा है, और न यह fast है न reliable
      ईमानदार two-way binding frameworks कम-से-कम speed तो देते ही हैं, और reliability अनुभव से आती है। React तो बस उलझाने वाला है। जिन engineers की frontend में पहली एंट्री React से हुई, उनके लिए नया सीखने से ज़्यादा पुराना unlearn करके दोबारा सीखना कहीं मुश्किल होगा, यह सोचकर अफसोस होता है
      VBScript, JS, jQuery, Mootools, Applets, ActionScript, YUI/Ext/Sencha, Backbone, Knockout, Angular 1, Angular 2, React, Vue 1 तक सब झेलने के बाद, मैं कहूंगा कि Flutter आज़माइए। सच में ताज़गीभरा है
      बस Dart समस्या है। अगर Flutter TypeScript होता, तो यह आदर्श के थोड़ा और करीब होता, लेकिन Dart frontend की अंतहीन churn वाली मानसिकता को जिंदा रखता है
    • मुझे तो उल्टा लगता है। जब मैंने React इस्तेमाल करना शुरू किया था, तब चीज़ें हर कुछ हफ्तों में बदलती थीं, और अब documentation और API कहीं ज़्यादा stable और consistent हैं
      web standards भी कुल मिलाकर पहले से कहीं ज़्यादा stable हैं। युवा developers को अब पेज को कई browsers में ठीक दिखाने के लिए सैकड़ों layout tricks सीखने की ज़रूरत नहीं है, और कभी-कभी सिर्फ एक browser के लिए hacks भी कम करने पड़ते हैं
      JavaScript fatigue समझ में आता है, लेकिन मुझे लगता है कि सीखने के लिए यह अब तक के सबसे अच्छे समयों में से एक है
    • मैं ज़्यादातर low-level coding करता रहा हूं और web frontend से मेरा रिश्ता आम तौर पर खराब रहा है, लेकिन कुछ साल पहले एक personal project के लिए React उठाया और काफ़ी हैरान रह गया
      पूरा अनुभव असली proper development जैसा लगा, और पहले की स्थिति की तुलना में यह ताज़ी हवा जैसा था
    • मुझे लगता है शुरुआत आसान है। बस उन optional features का इस्तेमाल मत कीजिए
      99% developers के लिए, app कुछ हद तक बढ़ने तक ऐसी सुविधाओं की ज़रूरत नहीं होगी, और हो सकता है कभी पड़े ही नहीं। React भी उन्हें मजबूर नहीं करता

  • एक समय मुझे React जैसे client-side frameworks पसंद थे, लेकिन आखिरकार समझ आया कि उन्होंने जहां संभव हुआ, वहां complexity बढ़ा दी
    backend, frontend, DevOps stack, हर जगह complexity घुस गई, और इस बंटी हुई complexity को sync में रखने के लिए और layers लगातार जुड़ती रहेंगी

    • छोटे applications से आगे बढ़ते ही frontend frameworks वास्तव में चीज़ों को सरल बनाते हैं
      data या model बदलते ही UI का अपने-आप फिर से render होना सही दिशा है
      details पर बहस हो सकती है, लेकिन हर बार data बदलने पर imperative तरीके से UI को सीधे बदलते रहना codebase या team size, दोनों के लिहाज़ से लंबे समय तक टिकाऊ नहीं है
    • React वही वजह था जिसने मुझे web frontend से दूर कर दिया
      web browser से ऐसे boxes render करवाने के लिए, जिनके लिए वह मूल रूप से बना ही नहीं था, इसने भारी complexity जोड़ दी, और coding paradigm बदलने के नाम पर productivity और tooling ecosystem का भी बड़ा नुकसान हुआ
      इसमें शानदार ideas और implementations थे, लेकिन क्या यह सब उसके लायक था, पता नहीं। कभी-कभी लगता है यह एक तरह का job-security mechanism था
      यह सिर्फ ReactJS की समस्या नहीं है; पूरा JavaScript ecosystem libraries और tools को लेकर पागल हो गया है, लेकिन React में शुरुआत करना खास तौर पर इतना झुंझलाने वाला था कि आखिरकार create react app आया, ताकि कोई वाजिब समय में hello world app बना सके
    • मेरी राय में venture-funded software development असल में होशियार और मज़ा चाहने वाले लोगों के लिए एक welfare program है। ठीक ही है
    • मुझे React पसंद है, लेकिन hooks के आने के बाद v16.8 से React में जो बदलाव हुए हैं, वे technical show-off जैसे लगते हैं
      class component API को hooks में बदलने की वजह समझने की उम्मीद मैंने छोड़ दी है
    • यह भी देखना चाहिए कि complexity कहीं आपने खुद तो नहीं जोड़ी
      आप कोई ज़्यादा simple framework चुन सकते हैं, या server orchestration से बच सकते हैं
      अगर विकल्प नहीं है, तो आप खुद ऐसा project शुरू करने पर भी सोच सकते हैं जो simple stack के साथ efficiency advantage दे सके

  • इस रिलीज़ की सबसे अच्छी बातों में से एक है ref को prop की तरह इस्तेमाल कर पाना। अब forwardRef की ज़रूरत नहीं रही

  • ब्लॉग पोस्ट ज़्यादा आसानी से पढ़ी जा सकती है: https://react.dev/blog/2024/12/05/react-19

    • const error = await updateName(newName); में समझ नहीं आता कि updateName error return क्यों कर रहा है
      JS/TS की तरह बस Error throw क्यों नहीं कर सकते?

  • अब तक 45 टिप्पणियों में अगर “redux” का 7 बार ज़िक्र हुआ है, तो यहाँ मैं Recoil परिवार के प्रतिनिधि के तौर पर Jotai का ज़िक्र करना चाहूँगा। संभव है कि React 19 में भी यह बिना किसी अलग बदलाव के पहले से ही काम करे
    जब frontend की complexity काफ़ी बढ़ जाती है, तो दूसरे state management tools अक्सर ज़रूरत से ज़्यादा रुकावट पैदा करने लगते हैं
    अगर आपको लगने लगा है कि आप React से नफ़रत करने लगे हैं, लेकिन असल में आप अंतहीन action constants की दीवार, prop plumbing, nested provider/context से लड़ाई, और pub-sub की शरण में भागने से थक चुके हैं, तो Jotai जैसी चीज़ एक बार आज़माने लायक है

    • Jotai बनाने वाली टीम ने Zustand और Valtio भी बनाए हैं
      https://github.com/pmndrs/zustand
      https://github.com/pmndrs/valtio
      Jotai में manual boilerplate कुछ ज़्यादा लगता है, और Valtio में proxy “magic” बहुत है, इसलिए मुझे निजी तौर पर पसंद होने पर भी यक़ीन नहीं कि टीम के लिए यह अच्छा विकल्प है
      Zustand boilerplate और magic के बीच का मध्यम रास्ता है, इसलिए मैंने इसे अभी चल रहे एक बड़े project के लिए चुना है
    • समझ नहीं आता state management में इतनी अजीब terminology क्यों है
      कुछ साल पहले जब मैंने React app पर काम शुरू किया था, तब मैंने जितने भी state management packages देखे, वे सब ऐसी terminology से भरे हुए थे, और आज भी स्थिति वैसी ही है
      आखिरकार मैंने उन सबसे हटकर काम पर ध्यान देने के लिए अपना खुद का समाधान बना लिया [1], और यह production environment में ठीक से चल रहा है। अफ़सोस है कि इसी तरह काम करने वाला कोई लोकप्रिय विकल्प नहीं है
      [1] https://github.com/facepunch/react-class-model
    • Jotai के npm docs page(https://www.npmjs.com/package/jotai) को देखकर भी यह साफ़ महसूस नहीं होता कि यह कई context provider या Redux के उपयोग से कैसे बाहर निकालता है
      context hook की अच्छी बात यह है कि वह composable होता है, और cached queries के साथ मिलकर यह काफ़ी maintainable pattern बना सकता है
      जानना चाहूँगा कि Jotai यहाँ कौन-सा व्यावहारिक सुधार देता है
    • मैंने काफ़ी बड़े project में Jotai इस्तेमाल किया है और यह मुझे काफ़ी पसंद आया
      सच में उम्मीद है कि फिर कभी redux या sagas से पाला न पड़े
    • सबको https://starfx.bower.sh आज़माना चाहिए। यह state management और, उससे भी ज़्यादा महत्वपूर्ण, side effect management के लिए एक नया approach है

  • नए जोड़े गए ज़्यादातर features मुझे पसंद नहीं आए
    Actions और useActionState / useOptimistic hooks एक बड़ी complexity trap जैसे लगते हैं। use hook का नाम बहुत कम जानकारी देता है, और यह component के अंदर बनाए गए promise को handle नहीं करता
    इसके पीछे अच्छे कारण ज़रूर होंगे, लेकिन promise को prop के रूप में पास करके use hook से handle करने का तरीका मुझे मौजूदा workaround से भी ज़्यादा complexity पैदा करता हुआ लगता है
    Server Components भी काफ़ी जटिल लगते हैं, और शुक्र है कि अभी मुझे इनके साथ काम नहीं करना पड़ रहा
    hydration error messages का बेहतर होना स्वागतयोग्य है, और provider के रूप में उपयोग वाले बदलाव तथा ref को prop के रूप में इस्तेमाल करने वाले बदलाव अच्छी quality-of-life improvements हैं
    कुल मिलाकर SPA बनाने के लिए मुझे React/Preact पसंद है। MUI जैसी feature-rich component library और Preact Signals जैसे सरल state management solution के साथ SPA बनाना काफ़ी सहज लगता है
    लेकिन यह चिंता है कि complexity धीरे-धीरे अंदर घुसती जा रही है। release notes में नए hooks की व्याख्या पढ़कर ही काफ़ी cognitive load महसूस होता है
    दूसरी ओर React Compiler एक बेहद ज़रूरी tool है। इससे programmer को typical optimizations सीधे component के अंदर लिखनी नहीं पड़ेंगी, और components कम जटिल होंगे
    release और Vite वगैरह के साथ इसके integration का इंतज़ार है, और सुना है कि Preact support भी आने वाला है

  • use API का नाम hooks के सामान्य prefix से अलग कुछ और होना चाहिए
    React hooks सीखना शुरू करने वाला कोई नया व्यक्ति यह देखकर उलझ जाएगा कि use को conditionally call किया जा सकता है, लेकिन सामान्य hooks को नहीं

  • parallel Suspense समस्या को हल करने के लिए release टालना वाकई बहुत अच्छी बात है
    मैंने अभी इसे आज़माया नहीं है, लेकिन उम्मीदें काफ़ी हैं, और कुल मिलाकर यह शानदार release है

  • ताज़ा ख़बर: custom elements का पूरा support है। यानी Web Components।