---
url: https://nsh.dev/hi/docs/goals
description: "Native Shell के लक्ष्य: नेटिव व्यू और इंटरैक्शन, ऐप के स्वामित्व वाला डिज़ाइन, साझा कॉम्पोनेंट, और एक ही इंजन पर Rust और TSX।"
---

# लक्ष्य और डिज़ाइन सिद्धांत

Native Shell iOS, Android, macOS, Windows, Linux और वेब पर नेटिव व्यू और इंटरैक्शन प्रदान करता है। विज़ुअल डिज़ाइन ऐप के अधीन रहता है। एक ही कंपोनेंट मॉडल पूरे ऐप, एम्बेडेड फ़ीचर और डायनामिक रूप से डिलीवर किए गए UI, तीनों के काम आता है।

<a id="native-foundations-app-owned-design"></a>

## नेटिव आधार, ऐप-स्वामित्व वाला डिज़ाइन

NSH हर प्लेटफ़ॉर्म के व्यू, टेक्स्ट और इनपुट इंफ्रास्ट्रक्चर पर बनता है, और इंटरैक्शन को डिवाइस के अनुसार ढालता है: कीबोर्ड नेविगेशन, पॉइंटर और टच इनपुट, टेक्स्ट एडिटिंग, स्क्रॉलिंग और एक्सेसिबिलिटी ([परिचय](https://nsh.dev/translations/hi/docs.md#what-native-means))।

रंग, टाइपोग्राफ़ी, स्पेसिंग, आकार, स्टेट फ़ीडबैक और एनिमेशन ऐप तय करता है। सेटिंग्स स्क्रीन iOS और Android पर ऐप की ब्रांडिंग का पालन कर सकती है, जबकि इनपुट और नेविगेशन हर डिवाइस की परंपराओं के अनुसार चलते हैं। डिज़ाइनर उस विज़ुअल भाषा को स्टाइल और कंपोनेंट पार्ट्स के ज़रिए निखारते हैं।

नेटिव व्यू रेंडरिंग की बुनियाद है। सिस्टम-स्टाइल वाला कंट्रोल एक विशेष विज़ुअल और व्यवहारिक चुनाव है। NSH के सामान्य कंट्रोल साझा व्यवहार और अनुकूलन-योग्य पार्ट्स उपलब्ध कराते हैं, ताकि एप्लिकेशन अपने डिज़ाइन सिस्टम बना सकें।

<a id="native-integration-in-practice"></a>

## व्यवहार में नेटिव इंटीग्रेशन

नेटिव फ़ाउंडेशन में रेंडरिंग, फ़्रेम-ड्रिवन एनिमेशन, इनपुट और एक्सेसिबिलिटी सिमेंटिक्स शामिल हैं। iOS और Android पर [Input](https://nsh.dev/translations/hi/elements/input.md) प्लेटफ़ॉर्म के टेक्स्ट फ़ील्ड का उपयोग करता है: एडिटिंग, सिलेक्शन मेन्यू, इनपुट मेथड और समर्थित ऑटोफ़िल सेवाएँ प्लेटफ़ॉर्म संभालता है। ऐप फ़ील्ड का वर्णन `autoComplete` के ज़रिए करता है, उदाहरण के लिए `current-password` या `postal-code`, और सिस्टम अपनी सेटिंग और सेवाओं के अनुसार उपलब्ध सुझाव देता है ([फ़ॉर्म और कीबोर्ड](https://nsh.dev/translations/hi/docs/forms-and-keyboard.md))। फ़ील्ड को स्टाइल करने के बाद भी यह सिस्टम इंटीग्रेशन बना रहता है।

यह किसी कस्टम रेंडरर के भीतर टेक्स्ट फ़ील्ड को पूरी तरह ड्रॉ करने से आर्किटेक्चर के स्तर पर अलग है: कस्टम रेंडरर को सिस्टम एडिटिंग और एक्सेसिबिलिटी सेवाओं के साथ अपना इंटीग्रेशन खुद देना पड़ता है, जबकि NSH वहाँ प्लेटफ़ॉर्म टेक्स्ट कंट्रोल का उपयोग करता है जहाँ उसका बैकएंड उन्हें उपलब्ध कराता है। हर बैकएंड का दस्तावेज़ अपना इंटीग्रेशन परिभाषित करता है, जिसमें Windows पर NSH का अपना एडिटर और GPUI एम्बेडिंग बैकएंड भी शामिल हैं ([प्लेटफ़ॉर्म](https://nsh.dev/translations/hi/docs/platforms.md))।

[GPUI Kit](https://gpui-kit.com) में कंपोनेंट व्यवहार को विज़ुअल डिज़ाइन से अलग रखने का जो सिद्धांत है, वही NSH की परतों को दिशा देता है। NSH इस सिद्धांत पर प्लेटफ़ॉर्म व्यू और इनपुट इंफ्रास्ट्रक्चर जोड़कर आगे बढ़ता है। इस पूरे मॉडल में नेटिव इंटीग्रेशन और ऐप-स्वामित्व वाला डिज़ाइन साथ-साथ काम करते हैं।

<a id="one-component-model-across-platforms"></a>

## प्लेटफ़ॉर्मों में एक कंपोनेंट मॉडल

स्विच का अर्थ फ़ोन, डेस्कटॉप और वेब पर एक ही है। [`nsh/base`](https://nsh.dev/translations/hi/modules/nsh-base.md) स्टेट, इनपुट हैंडलिंग, फ़ोकस और एक्सेसिबिलिटी प्रदान करता है; ऐप [Switch](https://nsh.dev/translations/hi/elements/switch.md) के ट्रैक, थंब और स्टेट को स्टाइल करता है। बटन, चेकबॉक्स और रेडियो भी इसी सिद्धांत का पालन करते हैं।

| ज़िम्मेदारी | कहाँ रहती है | उदाहरण |
|---|---|---|
| रेंडरिंग, लेआउट, रिएक्टिविटी और एनवायरनमेंट | `nsh-core`, `nsh` और रनटाइम मॉड्यूल | व्यू, टेक्स्ट, सिग्नल, स्टाइल |
| साझा व्यवहार और एक्सेसिबल संरचना | `nsh-base`, TSX में `nsh/base` के रूप में इम्पोर्ट किया जाता है | `Button`, `Checkbox`, `Switch`, `Tabs` |
| विज़ुअल डिज़ाइन और स्टाइल किए गए कंपोनेंट | ऐप या कम्युनिटी लाइब्रेरी | ब्रांडेड कंट्रोल, कार्ड, फ़ॉर्म रो |
| प्लेटफ़ॉर्म-विशिष्ट क्षमताएँ | `nsh/mobile`, `nsh/desktop` | मोबाइल नेविगेशन बार, डेस्कटॉप विंडो कंट्रोल |

सामान्य कंट्रोल का एक ही क्रॉस-प्लेटफ़ॉर्म स्थान `nsh/base` है। प्लेटफ़ॉर्म मॉड्यूल अपने उद्देश्य और प्लेटफ़ॉर्म सिमेंटिक्स के दायरे में सीमित हैं। [`TabBar`](https://nsh.dev/translations/hi/modules/nsh-mobile.md#tabbar) मोबाइल के टॉप-लेवल नेविगेशन के लिए है; [`Tabs`](https://nsh.dev/translations/hi/elements/tabs.md) सभी प्लेटफ़ॉर्मों पर टैब वाली सामग्री बदलता है। दोनों की भूमिकाएँ अलग हैं। `nsh/mobile` केवल उन क्षमताओं को स्वीकार करता है जिनके इंटरैक्शन सिमेंटिक्स मोबाइल-विशिष्ट हैं; किसी सामान्य कंट्रोल के रूप, आकार, टिंट या एनिमेशन के अंतर उसके साझा कंपोनेंट और ऐप की स्टाइलिंग के भीतर आते हैं। साझा भूमिका वाली नोटिफ़िकेशन या टोस्ट को पहले एक क्रॉस-प्लेटफ़ॉर्म कॉन्ट्रैक्ट के आधार पर डिज़ाइन किया जाना चाहिए, और उसकी प्रस्तुति अंदर से ढाली जानी चाहिए।

साझा कंपोनेंट अपना इंटरैक्शन अंदर से ढाल सकता है: मेन्यू डेस्कटॉप पर पॉपअप के रूप में और फ़ोन पर शीट के रूप में खुलता है, जबकि ऐप एक ही API का उपयोग करता है और अपना रूप खुद देता है। नेविगेशन हेडर और अलर्ट जैसी सिस्टम-प्रबंधित प्रस्तुतियाँ अपने दस्तावेज़ित प्लेटफ़ॉर्म प्रस्तुति नियमों का पालन करती हैं। ऐप अपने नेटिव कंपोनेंट और सेवाएँ [एम्बेडिंग इंटरफ़ेस](https://nsh.dev/translations/hi/docs/native-components.md) के ज़रिए उपलब्ध करा सकते हैं।

<a id="the-unstyled-foundation-and-the-component-library-layer"></a>

## अनस्टाइल्ड फ़ाउंडेशन और कंपोनेंट-लाइब्रेरी परत

NSH प्रिमिटिव और अनस्टाइल्ड फ़ाउंडेशन (`nsh-core` और `nsh-base`) का स्वामी है। एप्लिकेशन और थर्ड-पार्टी लाइब्रेरी स्टाइल की गई कंपोनेंट-लाइब्रेरी परत की स्वामी हैं, वही भूमिका जो [GPUI Kit](https://gpui-kit.com) में `gpui-component` निभाता है। इस विभाजन से हर प्रोडक्ट को अपनी विज़ुअल भाषा पर नियंत्रण मिलता है और कंपोनेंट इम्प्लीमेंटेशन के कठिन हिस्से दोबारा इस्तेमाल हो जाते हैं।

इस चुनाव के पीछे का अनुभव [GPUI Kit](https://gpui-kit.com) से आया है। उसके स्टाइल किए गए कंपोनेंट Longbridge Pro पर किए गए काम से विकसित हुए। जैसे-जैसे एप्लिकेशन को अधिकाधिक अलग डिज़ाइनों की ज़रूरत पड़ी, अनुकूलन के दबाव ने उपयोगकर्ताओं को कंपोनेंट फ़ोर्क करने की ओर धकेला। साझा फ़ाउंडेशन को `gpui-base` में निकालने से उन सभी डिज़ाइनों में व्यवहार दोबारा उपयोग-योग्य हो गया। स्टाइल किए गए कंपोनेंट डिज़ाइन संदर्भ के रूप में और उन एप्लिकेशन के लिए उपयोगी बने रहते हैं जिनकी ज़रूरतें उनकी अनुकूलन सतह में समा जाती हैं; फ़ाउंडेशन अन्य एप्लिकेशन को प्रस्तुति पर सीधा नियंत्रण देता है।

NSH इस सीख को शुरुआत से लागू करता है। `nsh/base` जटिल व्यवहार, इंटरैक्शन, रिएक्टिव स्टेट, फ़ोकस, एक्सेसिबिलिटी और अनुकूली प्रस्तुति का स्वामी है, और हर व्यवहार का परीक्षण उसी परत पर होता है जो उसकी स्वामी है। इसमें [Dock](https://nsh.dev/translations/hi/elements/dock.md) जैसी बड़ी संरचनाएँ भी शामिल हैं। एप्लिकेशन उस फ़ाउंडेशन पर स्टाइल, स्टेट, स्लॉट और पार्ट्स के ज़रिए विविध डिज़ाइन बनाते हैं। कंपोनेंट योगदान भी इसी सीमा का पालन करते हैं: विज़ुअल डिफ़ॉल्ट और ब्रांडेड वेरिएंट एप्लिकेशन या थर्ड-पार्टी कंपोनेंट के हैं। दस्तावेज़ित सिस्टम-प्रबंधित प्रस्तुतियाँ और `TextView` के रीडिंग डिफ़ॉल्ट अपने विशिष्ट कॉन्ट्रैक्ट बनाए रखते हैं ([आर्किटेक्चर](https://nsh.dev/translations/hi/docs/architecture.md#three-layers))।

<a id="what-the-gallery-demonstrates"></a>

### Gallery क्या प्रदर्शित करती है

वेबसाइट के डेमो और Gallery स्टाइल किए गए उदाहरण एप्लिकेशन हैं। उनके ग्रेडिएंट, शैडो, गोल कोने, ट्रांज़िशन और मोशन NSH की अनुकूलन क्षमताओं का अभ्यास कराते हैं और सोर्स उदाहरण देते हैं। ये चुनाव डेमो और Gallery के हैं; पुन: उपयोग-योग्य बेस कंपोनेंट उनके नीचे का व्यवहार और पार्ट्स उपलब्ध कराते हैं। एप्लिकेशन इन उदाहरणों को अपना सकते हैं या कोई अलग विज़ुअल भाषा बना सकते हैं।

स्वतंत्र रूप से वितरित स्टाइल की गई लाइब्रेरी ऊपर वर्णित एप्लिकेशन/कम्युनिटी परत में आएगी। Gallery की स्टाइलिंग एक डिज़ाइन दिशा का उदाहरण है; वह किसी विशेष प्रोडक्ट के लिए उपयुक्त है या नहीं, यह उस प्रोडक्ट का डिज़ाइन निर्णय है।

<a id="rust-and-tsx-on-one-engine"></a>

## एक इंजन पर Rust और TSX

Rust ऐप, TSX स्क्रीन और मिश्रित प्रोजेक्ट प्रिमिटिव, बेस कंपोनेंट, सिग्नल और लेआउट साझा करते हैं। Rust कंपाइल किया हुआ एप्लिकेशन लॉजिक और पुन: उपयोग-योग्य नेटिव कंपोनेंट देता है। TSX तेज़ इटरेशन और रन टाइम पर डिलीवर किए जाने वाले मॉड्यूल को सपोर्ट करता है ([Rust के साथ निर्माण](https://nsh.dev/translations/hi/docs/rust.md))।

इंजन बदले हुए सिग्नल पर निर्भर बाइंडिंग को अपडेट करता है और व्यू ऑपरेशन को बैच करता है। टेक्स्ट लेआउट, नेटिव एनिमेशन और इनपुट इंजन और उसके प्लेटफ़ॉर्म बैकएंड के हैं ([आर्किटेक्चर](https://nsh.dev/translations/hi/docs/architecture.md))। प्रदर्शन का मूल्यांकन दोहराए जा सकने वाले एप्लिकेशन वर्कलोड से किया जाता है ([प्रदर्शन](https://nsh.dev/translations/hi/docs/performance.md))।

<a id="embedding-dynamic-delivery-and-ai"></a>

## एम्बेडिंग, डायनामिक डिलीवरी और AI

मौजूदा नेटिव ऐप NSH व्यू को वहाँ रखता है जहाँ फ़ीचर को होना है, और अपने नेटिव कंपोनेंट और होस्ट सेवाएँ उपलब्ध कराता है। स्टैंडअलोन ऐप उसी रनटाइम और कंपोनेंट मॉडल का उपयोग करते हैं ([प्लेटफ़ॉर्म](https://nsh.dev/translations/hi/docs/platforms.md))।

डायनामिक रूप से डिलीवर किए गए TSX मॉड्यूल अपनी स्टेट, लॉजिक और लेआउट के स्वामी होते हैं। साइन किए गए पैकेज तय करते हैं कि होस्ट किन पब्लिशर पर भरोसा करता है; सैंडबॉक्स सीमाएँ और क्षमताएँ तय करती हैं कि मॉड्यूल क्या कर सकते हैं। भरोसा और अनुमतियाँ, दोनों होस्ट चुनता है ([साइन किए गए पैकेज](https://nsh.dev/translations/hi/docs/signed-packages.md), [सैंडबॉक्स और क्षमताएँ](https://nsh.dev/translations/hi/docs/sandbox-and-capabilities.md))।

AI-जनरेटेड UI उसी कॉन्ट्रैक्ट का पालन करता है: घोषित API के विरुद्ध TSX जनरेट करें, उसे जाँचें और टेस्ट करें, मॉड्यूल बनाएँ और साइन करें, फिर होस्ट नीति के तहत उसे सत्यापित करके चलाएँ। जनरेट किए गए डिक्लेरेशन, मॉडल-पठनीय दस्तावेज़ और CLI टेस्ट इस वर्कफ़्लो को निरीक्षण-योग्य और दोहराने-योग्य बनाते हैं ([टेस्टिंग और ट्रेसिंग](https://nsh.dev/translations/hi/docs/testing-and-trace.md))।

<a id="how-these-goals-guide-additions"></a>

## ये लक्ष्य नए जोड़ों को कैसे दिशा देते हैं

1. तय करें कि उपयोगकर्ता का व्यवहार क्या है और क्या वह प्लेटफ़ॉर्मों में साझा है।
2. साझा व्यवहार को मौजूदा प्रिमिटिव या बेस कंपोनेंट में रखें, और ऐप के अनुकूलन के लिए स्टेट और पार्ट्स उपलब्ध कराएँ।
3. प्लेटफ़ॉर्म-विशिष्ट सिमेंटिक्स वाली क्षमताओं को उनके प्लेटफ़ॉर्म मॉड्यूल में रखें, और लागू होने की शर्तें तथा साझा UI के साथ संयोजन को दस्तावेज़ित करें।
4. स्टाइल किए गए कंपोनेंट ऐप या कम्युनिटी लाइब्रेरी में बनाएँ।
5. प्रभावित प्लेटफ़ॉर्मों पर व्यवहार, एक्सेसिबिलिटी, लेआउट और इनपुट सत्यापित करें, और सार्वजनिक कॉन्ट्रैक्ट को दोनों भाषाओं में दस्तावेज़ित करें।

ये सिद्धांत NSH के बढ़ने के साथ विज़ुअल डिज़ाइन को लचीला, साझा कंपोनेंट API को सुसंगत और प्लेटफ़ॉर्म इंटीग्रेशन को स्पष्ट बनाए रखते हैं।