नकली ट्री: अधिक सरल UI के लिए indentation का उपयोग

 (ratfactor.com)
4 पॉइंट द्वारा GN⁺ 2024-01-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें

नकली ट्री: indentation का उपयोग करके सरल UI

  • UI में जब tree-जैसी सूची चाहिए होती है, तब parent-child संबंध लागू करने के लिए बहुत काम और जटिल data structures की ज़रूरत पड़ती है.
  • Relational database में recursive CTE(Common Table Expressions) का उपयोग करके tree structure data प्राप्त किया जा सकता है.

क्या data को वास्तव में tree structure होना चाहिए?

  • यह विचार करना ज़रूरी है कि items के बीच सच में parent-child संबंध होना चाहिए, या सिर्फ़ ऐसा दिखना भर काफ़ी है.
  • अगर वास्तविक संबंध की ज़रूरत नहीं है, तो id, sort, indent, name fields का उपयोग करके tree को सरल तरीके से store किया जा सकता है.
  • यह तरीका स्क्रीन पर दिखाई देने वाली चीज़ को सीधे व्यक्त करता है, इसलिए सूची को render करने और edit करने वाला interface बनाना कहीं ज़्यादा आसान हो जाता है.

"Namespacing" का उपयोग करने वाला एक और उदाहरण

  • HissScript में अगर item name में dot(.) हो, तो पहले हिस्से को काटकर item को indented दिखाने के ज़रिए namespacing feature लागू किया जाता है.
  • Game editor और player के लिए namespacing महत्वपूर्ण है, लेकिन वास्तव में यह सिर्फ़ एक साधारण name ही है.
  • लोगों को अक्सर असली tree structure से ज़्यादा उसकी appearance की ज़रूरत होती है.

बोनस tree-list

  • असली tree की नकल करते हुए path और information को flat list में store किया जाता है, और depth-first या breadth-first traversal के लिए path को sort किया जाता है.
  • Flat list के साथ काम करना आम तौर पर आसान होता है और यह computer के लिए भी अधिक उपयुक्त है.

भौतिक उपमा

  • जब कोई व्यक्ति अपना निजी scrapbook व्यवस्थित करता है, तो इंसान के लिए समूह कैसे काम करते हैं यह स्पष्ट होता है, लेकिन वास्तव में फ़र्श पर ऐसे संबंधों को लागू करने वाला कोई भौतिक mechanism नहीं होता.

सावधानी: हर स्थिति के लिए एक ही समाधान नहीं होता

  • तकनीक को खास scenario के अनुसार लागू करना चाहिए, और जहाँ वास्तविक tree structure की ज़रूरत हो वहाँ tree का ही उपयोग करना चाहिए.
  • अगर items के बीच वास्तविक संबंध जानना ज़रूरी हो, तो indentation या string के भीतर symbols गिनने जैसी hacky तकनीकों का उपयोग नहीं करना चाहिए.

GN⁺ की राय:

  • यह लेख software development में जटिल tree structures की जगह दृश्य रूप से सरल indentation का उपयोग करके user interface को सरल बनाने का तरीका प्रस्तुत करता है.
  • Developers के लिए यह data structures को सरल बनाकर development time बचाने और maintenance आसान करने की एक प्रभावी strategy देता है.
  • यह लेख इस बात पर ज़ोर देता है कि tree structure हमेशा ज़रूरी नहीं होता; कई बार user के लिए परिचित visual structure ही काफ़ी होता है, और इस तरह developers को user experience बेहतर करने का एक नया नज़रिया देता है.

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

1 टिप्पणियां

 
GN⁺ 2024-01-01
Hacker News राय

  • पहला तरीका, यानी 'adjacency list', को "स्पष्ट रूप से एकमात्र तरीका" माना जाता है।

  • दूसरा तरीका "काफ़ी अधिक सरल तरीका" है, ऐसा तरीका जिसे पहले नहीं देखा गया, और इसमें स्पष्ट कमियाँ हैं, लेकिन कुछ मामलों में यह पर्याप्त रूप से स्पष्ट है।

  • तीसरा तरीका, 'namespacing', को 'materialized path' कहा जाता है।

  • ट्री को दर्शाने का एक और तरीका 'nested sets' है, जो उस समय का काफ़ी प्रसिद्ध तरीका था जब relational database को बहुत गंभीरता से संभाला जाता था।

  • Postgres, 'ltree' नाम का data type और search operators देता है, जिससे ट्री संरचनाओं को स्वाभाविक रूप से संभाला जा सकता है। उदाहरण के लिए, 'ltree' का उपयोग करके table बनाया जा सकता है, data insert किया जा सकता है, और फिर सरल search के ज़रिए ट्री संरचना को query किया जा सकता है।

  • किसी संरचना के भीतर के मान अक्सर प्रदर्शित किए गए ट्री नहीं होते, बल्कि data की hierarchy होते हैं। संभव है कि आप data को traverse करना, relationships दिखाना, या उसे reorder करना चाहें। database के भीतर data structure में visual information को store करना अल्पकालिक दृष्टि जैसा लग सकता है।

  • ट्री-आधारित data से जुड़ी कंपनी शुरू करने का अनुभव रहा है। ट्री संरचना को O(n) समय में indented list में बदलना संभव है। यह interview questions में से एक था, और recursive queries के बिना भी SQL database में ट्री के कुछ हिस्सों को तेज़ी से लाने और render करने के कई तरीके मौजूद हैं।

  • relational database से SQL query का उपयोग करके ट्री संरचना वाला data लाने का एक तरीका recursive CTE(Common Table Expressions) लिखना है। CTE वास्तव में मज़ेदार हैं, और एक बार इनके अभ्यस्त हो जाएँ तो इनसे डरने की ज़रूरत नहीं रहती।

  • अनुभव से पता चलता है कि लोग अक्सर वास्तव में ट्री नहीं चाहते, उन्हें सिर्फ़ ट्री जैसा दिखना चाहिए। HN और Reddit इस मामले में अलग हैं। HN में child comments, parent comment के अगले sibling के रूप में आते हैं, और indentation को parent की indentation से एक बढ़ाकर ट्री का रूप दिया जाता है। वहीं Reddit में child comments वास्तव में parent comment के भीतर nested होते हैं।

  • लेख का मुख्य विचार है कि समस्या के लिए उपयुक्त संरचना का उपयोग किया जाए। लेकिन तर्क की प्रस्तुति में कमी है। database से ट्री लाने के लिए CTE की ज़रूरत नहीं है, और local में ट्री बनाने के लिए flat list लाई जा सकती है। साथ ही, पर्याप्त बड़े ट्री में branch को move करने या depth बदलने पर linear cost लग सकती है।

  • taxonomy या अन्य hierarchy को समझाते समय, local file system का उपयोग करने वाला एक सरल और तेज़ तरीका सीखा। 'mkdir' और 'tree' commands का उपयोग करके output को email, Slack, pastebin आदि में copy-paste करके साझा किया जाता है।

  • अगर सिर्फ़ save/load करना है, तो data को मनचाहे तरीके से serialize करके (जैसे JSON) string के रूप में store करना अधिक सरल समाधान हो सकता है। dot notation का उपयोग, VsCode extension Dendron द्वारा name hierarchy को संभालने के तरीके जैसा है।

  • कुछ साल पहले OpenGL के बारे में भी ऐसा ही एहसास हुआ: hierarchical 3D objects की दुनिया को draw करने की ज़रूरत नहीं होती, सिर्फ़ sorted triangles की list draw करनी होती है। इससे कई optimizations बहुत आसान हो जाती हैं।