URL एक state container है

 (alfy.blog)
37 पॉइंट द्वारा GN⁺ 2025-11-03 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • URL की संरचना सिर्फ एक साधारण पता नहीं, बल्कि application state को store और restore करने का माध्यम भी है
  • PrismJS download page की तरह, ऐसे उदाहरण दिखाए गए हैं जहाँ एक ही URL से theme, language और plugin settings पूरी तरह reproduce की जा सकती हैं
  • path, query parameter, fragment जैसे हर component से hierarchical navigation, filtering, client navigation जैसी अलग-अलग state व्यक्त की जा सकती है
  • search filter, pagination, view mode, date range जैसी चीज़ें URL में शामिल करने के लिए उपयुक्त हैं, जबकि sensitive information या अस्थायी UI state इसके लिए उपयुक्त नहीं हैं
  • अच्छी तरह डिज़ाइन किया गया URL shareability, predictability, caching efficiency बढ़ाता है और web application की reliability और user experience को मजबूत करता है

URL की क्षमता

  • URL सिर्फ resource address नहीं है, यह user interface (UI) और state container के रूप में भी काम करता है
    • sharing, bookmark, browser history, deep link आदि में state को अपने-आप preserve करता है
    • 1991 से web के बुनियादी state management mechanism के रूप में काम कर रहा है
  • URL का हर component अलग तरह की state व्यक्त करता है
    • path: hierarchical resource navigation (/users/123/posts)
    • query: filter, option, setting (?theme=dark&lang=en)
    • fragment: document के भीतर location या SPA routing (#features, #/dashboard)
  • Text Fragments फीचर page के भीतर किसी खास text पर सीधे link करना संभव बनाता है

Query parameter patterns

  • delimiter से एक key में कई values रखना (?tags=frontend,react,hooks)
  • nested data को JSON या Base64 में serialize करना (?config=eyJyaWNrIjoicm9sbCJ9==)
  • boolean flag को key की मौजूदगी से दिखाना (?mobile)
  • array notation (bracket notation) में tags[]=frontend&tags[]=react जैसे multi-value expression
    • Node के qs या Express middleware आदि इसे अपने-आप पहचान लेते हैं, लेकिन यह standardize नहीं है
  • सबसे महत्वपूर्ण बात है consistency बनाए रखना

URL के जरिए state व्यक्त करने के उदाहरण

  • PrismJS: URL hash में पूरा theme, language, plugin configuration store करता है
  • GitHub: #L108-L136 से code line range को highlight करता है
  • Google Maps: coordinate, zoom level, map type को URL में शामिल करता है
  • Figma: canvas position, zoom, selected element जैसे work context को URL से share करता है
  • e-commerce sites: filter, sorting, price range को URL में रखकर search state restore करती हैं

Frontend engineering patterns

  • URL में शामिल करने के लिए उपयुक्त state
    • search term, filter, page/sort, view mode, date range, active tab, UI configuration, feature flag
  • URL के लिए अनुपयुक्त state
    • password, token जैसी sensitive information, temporary UI state, unsaved input, large data, high-frequency state
  • निर्णय का मानदंड: क्या किसी दूसरे user को यही URL खोलने पर वही state दिखनी चाहिए?

JavaScript implementation

  • URLSearchParams API से query parameter पढ़े और लिखे जा सकते हैं
  • pushState से नया history entry जोड़ना, replaceState से मौजूदा entry को update करना
  • popstate event से browser back action पर UI restore करना

React implementation

  • React Router का useSearchParams hook URL state को संक्षेप में manage करने देता है
    • parameter पढ़ते या update करते समय URL और UI अपने-आप sync होते हैं

URL state management की best practices

  • default values को URL में शामिल न करें (?theme=dark ही रखें, default value code में handle करें)
  • debouncing से typing के दौरान URL के excessive update को रोकें (lodash.debounce का उपयोग)
  • pushState vs replaceState
    • pushState: filter change, page navigation जैसी undo की जा सकने वाली state
    • replaceState: search input जैसी सूक्ष्म edits

URL को contract की तरह देखना

  • अच्छी तरह डिज़ाइन किया गया URL application और user के बीच explicit contract का काम करता है
    • public/private, client/server, shared/session state की सीमाएँ साफ करता है
  • readable URL इरादा स्पष्ट करते हैं और इंसान व मशीन दोनों के लिए समझने योग्य होते हैं
    • example.com/products/laptop?color=silver&sort=price जैसी संरचना अर्थ स्पष्ट करने में बेहतर है
  • caching efficiency में सुधार
    • एक जैसा URL एक जैसे resource के रूप में माना जाता है, जिससे cache hit rate बढ़ता है
    • query parameter से cache variation को control किया जा सकता है
  • versioning और experiment
    • ?v=2, ?beta=true, ?experiment=new-ui आदि से API version या A/B test को अलग किया जा सकता है

जिन anti-patterns से बचना चाहिए

  • SPA में सिर्फ in-memory state रखना, जिससे refresh पर state खो जाती है
  • sensitive information को URL में डालना (?password=secret123)
  • अस्पष्ट parameter names (?foo=true&bar=2 की जगह ?mobile=true&page=2)
  • जटिल JSON को Base64 में encode करके बहुत लंबा URL बनाना
  • URL length limit पार करना (browser, server, CDN constraints मौजूद हैं)
  • back button को बेअसर करना (replaceState के अत्यधिक उपयोग से)

निष्कर्ष

  • अच्छा URL सिर्फ content की ओर इशारा नहीं करता, बल्कि user और application के बीच संवाद भी व्यक्त करता है
  • URL intent, context, shareability को समेटने वाला सबसे पुराना और elegant state management माध्यम है
  • Redux, MobX, Zustand, Recoil जैसे complex state management tools मौजूद हैं, लेकिन
    URL जैसी बुनियादी क्षमता को न भूलना ही web की असली ताकत है
  • जो app refresh पर state खो देता है, वह web की मूल प्रकृति को खो रहा है

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

2 टिप्पणियां

 
GN⁺ 2025-11-03
Hacker News राय

  • कोड रिव्यू के समय मैं कोशिश करता हूँ कि जितना संभव हो उतना state URL में रखा जाए
    refresh के बाद पूरी तरह किसी दूसरी जगह पहुँच जाना, या share किया हुआ URL किसी अजीब स्क्रीन को दिखाना, यूज़र के नज़रिए से अपमानजनक है
    यह तरीका development की रफ़्तार धीमी करता है, लेकिन टीम के भीतर UX को लेकर समझ बढ़ाता है और यह स्पष्ट करता है कि view में कितना state भरा जा रहा है
    यह चिंता भी रहती है कि URL एक तरह का public API बन जाता है और उससे constraints पैदा होते हैं, लेकिन ज़्यादातर URL थोड़े समय के लिए ही उपयोग होते हैं, इसलिए मुझे यह बहुत बड़ी समस्या नहीं लगती
    ज़रूरत पड़े तो load के समय पुराने URL को नए URL में migrate करने वाले code से इसे संभाला जा सकता है

    • मुझे यह approach पसंद है, लेकिन browser history autocomplete की वजह से कभी-कभी अनचाहा state वापस आ जाता है
      path की जगह query parameters इस्तेमाल करना थोड़ा बेहतर लगता है
    • जिस work webapp का मैं उपयोग करता हूँ, उसमें अपना “back” button बना दिया गया है, इसलिए browser का back पूरी तरह टूट चुका है
      यूज़र के नज़रिए से “back” शब्द browser button से जुड़ा होता है, इसलिए यह भ्रम पैदा करता है
      refresh से state reset हो जाना कम परेशान करता है, क्योंकि “refresh = शुरुआत से फिर” जैसी समझ बनी हुई है
    • अगर page server-rendered है, तो refresh पर scroll position अपने-आप restore हो जाती है
      जब सब कुछ JS से संभालते हैं, तो ऐसी बुनियादी सुविधाएँ हल्के-हल्के टूट जाती हैं
    • मुझे लगता है कि URL design, UX design का हिस्सा है
      लेकिन अब तक 30 से ज़्यादा UX designers के साथ काम करने पर भी मुझे URL के बारे में कभी कोई guideline नहीं मिली
    • web के विकसित होने के साथ refresh के अर्थ भी स्थिति के अनुसार बदल गए हैं
      खासकर mobile पर page को शुरुआती state में लौटाना मुश्किल होता है, इसलिए refresh सबसे तेज़ समाधान बन जाता है
      infinite scroll या complex filter UI में URL में जितना अधिक state होगा, reset करना उतना ही झंझट वाला हो जाता है
      अगर पहले से ही UX को लेकर असंतोष हो, और ऊपर से URL भी साफ़-सुथरा करना पड़े, तो यह यूज़र के लिए दोहरा stress है

  • मुझे लगता है कि digital literacy ऊँची रखने वाले लोगों की भी URL और DNS की समझ कमज़ोर होती है
    phishing के जोखिम को कम करने, URL parameters (?t=_, utm_) के अर्थ को समझने, और share करने से पहले निजी जानकारी हटाने की क्षमता होनी चाहिए
    यह भी समझना चाहिए कि HTTPS का lock icon ‘trust’ का मतलब नहीं होता

    • लेकिन browser डिफ़ॉल्ट रूप से URL को छिपाते या छोटा करके दिखाते हैं, और कंपनियाँ QR code या सिर्फ़ search keywords का प्रचार करती हैं, इसलिए इस बारे में शिक्षित करना मुश्किल है

  • URL को state container की तरह इस्तेमाल करने से आंतरिक संरचना expose हो जाती है, और versioning की ज़रूरत पड़ती है
    अलग-अलग browsers की compatibility या authentication flow में भी समस्याएँ आ सकती हैं
    फिर भी मैं command-line arguments की तरह जितना संभव हो उतना state URL में expose करने की कोशिश करता हूँ
    लेकिन यह एक जानबूझकर किया गया trade-off है, अज्ञान या अनुभव की कमी की वजह से नहीं

  • पुरानी library है, लेकिन अब भी उपयोगी Rison की सिफारिश करता हूँ
    इससे JSON को URL में साफ़-सुथरे तरीके से रखा जा सकता है, और Elastic की Kibana में भी इसका उपयोग होता है
    उदाहरण: http://example.com/service?query=q:'*',start:10,count:10

    • मैं इसी तरह की चीज़ खोज रहा था! पहले मैं खुद कुछ ad-hoc बनाता था, लेकिन यह उससे कहीं ज़्यादा standard और व्यवस्थित तरीका लगता है

  • सिस्टम विकसित होता है तो state structure भी बदलती है, इसलिए URL में state डालने से evolution सीमित हो जाती है
    क्योंकि URL मूल रूप से एक स्थायी string है
    इसके बजाय URL को एक तरह का protocol मानकर state को encode और decode करना मुझे ज़्यादा उचित लगता है
    अगर page simple हो, तो पूरा state URL में रखना भी संभव है

    • लंबे समय तक रहने वाले content (जैसे blog post) में URL state को सुरक्षित रखना उपयोगी है
      लेकिन feed जैसी चीज़ों में यह इस user expectation पर निर्भर करता है कि “refresh करने पर क्या इसे latest state पर लौटना चाहिए?”
    • versioning लागू करने से इस तरह की समस्याओं को कम किया जा सकता है

  • URL length limit browser, server, CDN, और search engine settings के अनुसार अलग-अलग होती है, लेकिन आमतौर पर 2000 characters से कम मानी जाती है
    सवाल यह है कि इस सीमा के भीतर कितना state रखा जा सकता है, या फिर किसी दूसरे approach की ज़रूरत पड़ेगी

    • domain को छोड़कर हर character के लिए 66 विकल्प (uppercase/lowercase, numbers, special characters - . _ ~) होते हैं, इसलिए information density काफ़ी अधिक है

  • draw.io पूरा state URL में रखकर share करने देता है
    diagram data Base64 में encoded होता है, इसलिए सिर्फ़ एक link से पूरा restore संभव है
    हालाँकि मुझे यक़ीन नहीं कि यह ‘state container’ की परिभाषा में पूरी तरह फिट बैठता है या नहीं

  • मैं self-hosted apps में hash routing (#/dashboard) का उपयोग करता हूँ
    इससे server-side URL rewrite (.htaccess आदि) की ज़रूरत नहीं पड़ती, इसलिए यह परफ़ेक्ट न होते हुए भी deployment environment constraints को कम कर देता है

  • नया Microsoft Teams हर स्क्रीन को एक ही URL से संभालता है, इसलिए bookmark करना संभव नहीं है
    किसी खास team या channel को सीधे नहीं खोला जा सकता, जो बहुत असुविधाजनक है

  • HATEOAS का नाम अच्छा नहीं है, इसलिए शायद उसे ज़्यादा ध्यान नहीं मिला, लेकिन आख़िरकार यह web की बुनियादी अवधारणा ही है

    • यूज़र के नज़रिए से links follow करना और forms submit करना ही HATEOAS है
      लेकिन जहाँ server और client दोनों पर पूरा control हो, वहाँ इससे सिर्फ़ अतिरिक्त complexity पैदा होती है
      खासकर अगर client को फिर भी endpoint structure जानना पड़े, तो URL को opaque बनाने के अलावा इससे कुछ हासिल नहीं होता
    • यह विषय वास्तव में HATEOAS से सीधे जुड़ा नहीं है। दोनों URL का उपयोग करते हैं, लेकिन HATEOAS state storage नहीं बल्कि navigation structure के बारे में है
    • मज़ाक में कहें तो, आख़िरकार HATEOAS के लिए “serialized format (cerealization)” वाला नाम ज़्यादा फिट बैठता है
 
ndrgrd 2025-11-03

मैं tab sleep feature का काफ़ी इस्तेमाल करता हूँ, लेकिन जो web apps URL को फिक्स करके एक ही ब्लॉक की तरह चलते हैं, वे sleep mode में जाते ही जानकारी खो देते हैं.

लेकिन ऐसी web pages भी हर बार इतनी भारी होती हैं कि sleep को बंद करके रखना भी मुमकिन नहीं होता.