- लोग htmx के बारे में ऐसे बात करते हैं मानो वह SPA की दुनिया में वेब को बचा लेगा
- htmx के निर्माता Carson Gross इस गतिशीलता को मज़ाकिया ढंग से "हेगेलियन द्वंद्ववाद" के रूप में समझाते हैं:
- प्रतिज्ञान (thesis): पारंपरिक MPA
- प्रतिपक्ष (antithesis): SPA
- संश्लेषण (synthesis): hypermedia-आधारित interactive islands से बना application
- लेकिन मुझे इसमें वह बात नहीं दिखी, और मैंने पहले ही "htmx से SPA बनाया" था
- यह एक साधारण ToDo list app का PoC है
- पेज लोड होने के बाद सर्वर से आगे कोई संचार नहीं होता
- सब कुछ लोकल रूप से client पर ही प्रोसेस होता है
- अगर htmx नेटवर्क के ज़रिये hypermedia exchange को मैनेज करने पर केंद्रित है, तो यह कैसे काम करता है?
- एक सरल ट्रिक: "Server-Side" कोड Service Worker में चलता है
Service Worker
- यह web page और internet के बीच proxy की तरह काम करता है
- यह network requests को intercept और modify कर सकता है
- request बदल सकता है, offline के लिए response cache कर सकता है, और request को browser के बाहर भेजे बिना नया response generate कर सकता है
- यही आख़िरी क्षमता इस single-page app का मूल है
- जब htmx network request करता है, Service Worker उसे intercept कर लेता है
- फिर Service Worker business logic चलाता है और नया HTML generate करता है
- htmx उस नए HTML को DOM में swap कर देता है
मौजूदा SPA की तुलना में फायदे
- Service Worker को storage के लिए IndexedDB इस्तेमाल करना पड़ता है
- इससे पेज लोड्स के बीच state बनी रहती है
- आप पेज बंद करके वापस आएँ, तब भी app डेटा याद रखता है
- इस architecture को चुनने पर यह एक तरह का "मुफ़्त" side benefit है
- इसे offline पर भी चलाना आसान है
नुकसान
- developer tools का support कमज़ोर है
console.log कभी-कभी छूट जाता है- Service Worker install हुआ या नहीं, इसकी रिपोर्ट भरोसेमंद नहीं होती
- Firefox में ES modules का support नहीं है
- सारा कोड एक ही फ़ाइल में रखना पड़ता है
- कुल मिलाकर development experience "मज़ेदार" नहीं है
इसके बावजूद htmx SPA ठीक से काम करता है
implementation details
- बेसिक HTML single-page app का एक खाली shell है
<body> टैग htmx का इस्तेमाल करके app के मुख्य हिस्से को सेट करता है
hx-boost="true": htmx को निर्देश देता है कि full-page navigation के बिना link clicks और form submissions के response को Ajax से replace करेhx-push-url="false": htmx को link clicks और form submissions के साथ URL बदलने से रोकता हैhx-get="./ui": पेज लोड होने पर /ui से पेज fetch करके replace करने का निर्देश देता हैhx-target="body": result को <body> element में replace करने का निर्देश देता हैhx-trigger="load": पेज लोड पर यह सब करने का निर्देश देता है
/ui endpoint
- यह app का वास्तविक markup लौटाता है
- इसके बाद htmx links और forms को control करके इसे interactive बनाता है
- Service Worker request routing को Express-style library से संभालता है
setFilter और listTodos IDB Keyval को wrap करने वाले सरल functions हैंApp component filter form, todo list, और add form से बना है
/todos/add endpoint
- todo सेव करने के बाद UI को दोबारा render किया हुआ response लौटाता है
- htmx उस response को DOM में replace कर देता है
Todo component
- यह checkbox, delete button, और todo text से बना है
- checkbox
/todos/${id}/update request trigger करता है
- delete button
/todos/${id} delete request trigger करता है
- todo text की दो states हैं: "normal" और "editing"
- htmx double-click event सुनता है
/ui/todos/${id}?editable=true request करता है- Service Worker
<input> के साथ Todo HTML लौटाता है
- htmx response के HTML से मौजूदा todo item को replace कर देता है
सारांश
- तकनीकी रूप से यह काम करता है
- लेकिन क्या यह अच्छा विचार है? क्या यह सचमुच hypermedia-आधारित app का शिखर है? क्या React छोड़कर हमें इसे इसी तरह बनाना चाहिए?
- पूरी तरह local app में htmx की यह indirection आज़ादी से ज़्यादा बोझ लगती है
- ज़्यादातर apps पूरी तरह local नहीं होते
- मेरे हिसाब से "islands of interactivity" पैटर्न, "server-side" code को Service Worker और असली server में बाँटने से बेहतर है
- यह एक प्रयोगात्मक कोशिश थी, ताकि दिखाया जा सके कि hypermedia से पूरी तरह local single-page app बनाया जा सकता है
अभी कोई टिप्पणी नहीं है.