दस्तावेज़मॉडल को समझें
मूल अवधारणाएँ
बाकी दस्तावेज़ों में उपयोग किए जाने वाले शब्द - मार्ग, पृष्ठ, दृश्य, घटक, हैंडलर, समापन बिंदु - प्रत्येक एक पंक्ति में, पृष्ठ के लिंक के साथ जो गहराई तक जाता है। नेक्सी में नए हैं? नेक्सी क्या है? से प्रारंभ करें।
इन दस्तावेज़ों को कैसे पढ़ें
| स्तर | यह जिस प्रश्न का उत्तर देता है | से शुरू करें |
|---|---|---|
| अनुप्रयोग वास्तुकला | कौन सी परत किसी अनुरोध का उत्तर देती है और क्या करने से इंकार करती है | नेक्सी कैसे काम करती है |
| अनुप्रयोग संरचना | कोड कहां रहता है, और फ़ाइल क्या बनती है | परियोजना संरचना |
| प्रस्तुति एवं प्रतिपादन | पाठक क्या देखता है, और HTML कौन बनाता है | दृश्य, प्रतिपादन |
| अनुप्रयोग इंटरैक्शन | पाठक क्या करता है, और प्रतिक्रिया में क्या चलाता है | क्रियाएँ |
स्तरों को उस क्रम में एक बार पढ़ा जाता है। उसके बाद, आपको जिस पृष्ठ की आवश्यकता है वह एक लुकअप है, पाठ्यक्रम नहीं।
अनुप्रयोग वास्तुकला
यह तय करने के तीन तरीके कि कौन सा कोड किसी URL का उत्तर देता है। वे विकल्प हैं, परतें नहीं:
- फ़ाइल-आधारित रूटिंग (FBR):
src/routes/के अंतर्गत एक फ़ाइल एक रूट है। डिफ़ॉल्ट। - मॉड्यूलर राउटर:
src/apps/के अंतर्गत नियंत्रक और मॉड्यूल, नेस्टजेएस-शैली कोडबेस के लिए डेकोरेटर के साथ घोषित। - कस्टम राउटर: एक मौजूदा FastAPI
APIRouterएप्लिकेशन में शामिल है।
विकल्प nexyconfig.py में NexyConfig वर्ग की एक पंक्ति है।
फ़ाइल-आधारित रूटिंग के लिए किसी लाइन की आवश्यकता नहीं है: useRouter के बिना, नेक्सी src/routes/ पढ़ता है।
from nexy.core.models import NexyConfigModel class NexyConfig(NexyConfigModel): pass # file-based: no useRouter, the files of src/routes/ are the routesमॉड्यूलर राउटर src/apps/ का रूट मॉड्यूल है:
from nexy.core.models import NexyConfigModel from src.apps.app_module import AppModule class NexyConfig(NexyConfigModel): useRouter = AppModule # modular: the root module of src/apps/एक कस्टम राउटर एक APIRouter है जो आपके पास पहले से है:
from nexy.core.models import NexyConfigModel from src.legacy import api # an APIRouter you already have class NexyConfig(NexyConfigModel): useRouter = api # custom: your router, included as it isतीनों में से किसी एक को चुनना एक निर्णय है। फ्रंटएंड फ्रेमवर्क चुनना एक अलग, अलग मामला है: देखें राउटर चुनें और व्यूज़।
अनुप्रयोग संरचना
पाँच धारणाएँ जो Next.js से आने वाला एक पाठक आमतौर पर एक में विलीन हो जाती हैं। वे एक ही चीज़ नहीं हैं, और अंतर सबसे अधिक स्पष्ट करता है "मेरा पृष्ठ क्यों प्रस्तुत नहीं कर रहा है" प्रश्न।
| धारणा | यह क्या है | यह क्या नहीं है |
|---|---|---|
| मार्ग | एक यूआरएल पैटर्न, जो फ़ाइल के पथ द्वारा निर्मित होता है | एक फ़ाइल: एक फ़ाइल कई यूआरएल का उत्तर दे सकती है ([slug]) |
| पेज | एक रूट फ़ाइल जो एक दृश्य प्रस्तुत करती है: .nexy, .md, .mdx, .tsx, .vue, .svelte |
एक समापन बिंदु: यह दस्तावेज़ का उत्तर देता है, डेटा का नहीं |
| देखें | किसी पृष्ठ का मुख्य भाग क्या बनता है: Jinja2 और Python, Markdown, या एक ग्राहक घटक | एक मार्ग: एक ही दृश्य कई पृष्ठों पर काम कर सकता है |
| घटक | एक पुन: प्रयोज्य टुकड़ा जिसे एक पृष्ठ आयात करता है | एक मार्ग: सर्वर मोड में एक घटक कभी भी अपने आप परोसा नहीं जाता है |
| रूट हैंडलर | .py रूट फ़ाइल का कार्य, HTTP विधि के नाम पर (GET, POST,…) |
एक पृष्ठ: यह JSON, एक फ़ाइल या एक Response लौटाता है |
| समापन बिंदु | जोड़ी (यूआरएल, विधि) जिसका उत्तर हैंडलर देता है | एक हैंडलर: एक फ़ाइल कई समापन बिंदुओं का उत्तर दे सकती है |
एक वाक्य में: एक पृष्ठ एक रूट फ़ाइल है, एक दृश्य वह है जो इसे प्रस्तुत करता है, एक घटक वह है जिसे एक पृष्ठ पुन: उपयोग करता है, एक हैंडलर एक समापन बिंदु का उत्तर देता है।
एक छोटे प्रोजेक्ट में सभी पाँच:
from "@/components/Like.tsx" import Like slug: prop[str]<h1>{{ slug }}</h1><Like post="{{ slug }}" />अग्रभाग और उसके नीचे का टेम्पलेट पृष्ठ का दृश्य है; Like वह घटक है जिसका वह पुन: उपयोग करता है।
async def GET(): # the endpoint GET /api/posts return {"posts": []} async def POST(): # the endpoint POST /api/posts return {"created": True}मॉड्यूलर राउटर के साथ, एक रूट एक नियंत्रक का पथ है, और एक हैंडलर इसके तरीकों में से एक है, जिसका नाम HTTP क्रिया के नाम पर रखा गया है:
from nexy.decorators import Controller @Controller("/api/posts")class PostsController: async def get(self) -> dict: # the endpoint GET /api/posts return {"posts": []} async def post(self) -> dict: # the endpoint POST /api/posts return {"created": True}from nexy.decorators import Module from .posts_controller import PostsController @Module()class AppModule: controllers = [PostsController]एक पृष्ठ अभी भी src/routes/ की एक फ़ाइल है, या एक दृश्य जो नियंत्रक useViews के साथ लौटाता है।
एक कस्टम राउटर के साथ, एक रूट आपके APIRouter का एक पथ है, और एक हैंडलर वह फ़ंक्शन है जिसे उसका डेकोरेटर पंजीकृत करता है:
from fastapi import APIRouter api = APIRouter() @api.get("/api/posts") # the endpoint GET /api/postsasync def list_posts(): return {"posts": []} @api.post("/api/posts") # the endpoint POST /api/postsasync def create_post(): return {"created": True}पृष्ठ अभी भी src/routes/ की फ़ाइलें हैं: शामिल मार्गों के बगल में एक .nexy पृष्ठ उत्तर है।
दो और शब्द जो हर जगह वापस आते हैं:
- लेआउट: एक
layout.*फ़ाइल जो अपने फ़ोल्डर के नीचे पृष्ठों को लपेटती है; रूट वाला HTML दस्तावेज़ का स्वामी है। लेआउट देखें। - निर्भरता: एक फ़ंक्शन जो एक हैंडलर से पहले चलता है, प्रति रूट या प्रति फ़ोल्डर लागू होता है। निर्भरताएं देखें।
प्रस्तुति एवं प्रतिपादन
दो स्वतंत्र निर्णय, जो अक्सर भ्रमित होते हैं:
- प्रारूप तय करता है कि कौन सी फ़ाइल पृष्ठ प्रस्तुत करती है: दृश्य।
- मोड तय करता है कि HTML कौन बनाता है और कब: रेंडरिंग।
| धारणा | एक पंक्ति |
|---|---|
| सर्वर मोड | सर्वर .nexy और .md पेज प्रस्तुत करता है; घटक द्वीप हैं (मोड) |
| क्लाइंट मोड | useCSR = True: फ्रेमवर्क फ़ाइलें मार्ग हैं, और नेविगेशन ब्राउज़र में होता है |
| एसएसआर, आईएसआर, सीएसआर, द्वीप समूह | सीएसआर को छोड़कर प्रति पृष्ठ चार रेंडरिंग मोड तय किए गए हैं, जो प्रति प्रोजेक्ट है (रेंडरिंग) |
| जलयोजन | ब्राउज़र HTML में एक फ़्रेमवर्क संलग्न कर रहा है, सर्वर पहले ही भेज चुका है (द्वीप) |
| सहारा | वे मान जो माता-पिता किसी घटक को देते हैं, name: prop[type] को .nexy फ़ाइल में घोषित करते हैं (.nexy फ़ाइलें) |
एक द्वीप के साथ एक सर्वर-मोड पृष्ठ: सर्वर पृष्ठ को प्रस्तुत करता है, ब्राउज़र चार्ट को केवल तभी हाइड्रेट करता है जब वह दृश्य में स्क्रॉल करता है।
from "@/components/Chart.tsx" import Chart<h1>Sales</h1><Chart directive="client:visible" />द्वीप दृश्य में चला जाता है, और नियंत्रक दृश्य लौटाता है:
from "@/components/Chart.tsx" import Chart<h1>Sales</h1><Chart directive="client:visible" />from nexy.decorators import Controllerfrom nexy.hooks import useViews @Controller("/sales")class SalesController: async def get(self): return useViews("src/apps/sales_view.nexy")अनुप्रयोग इंटरैक्शन
| धारणा | एक पंक्ति |
|---|---|
| कार्रवाई | एक Python फ़ंक्शन को @Action के रूप में चिह्नित किया गया है, जिसे POST के रूप में कार्य किया जाता है, जिसे किसी फॉर्म से या टाइप किए गए फ़ंक्शन के रूप में कॉल किया जा सकता है (क्रियाएं) |
| प्रपत्र | एक HTML फ़ॉर्म जो किसी क्रिया पर पोस्ट करता है, सत्यापन त्रुटियों के साथ पृष्ठ पर वापस आता है (क्रियाएँ) |
| नेविगेशन | लिंक जो प्रीफ़ेच करते हैं, और हुक जो पथ, क्वेरी, कुकीज़ और सत्र को पढ़ते हैं (हुक) |
| डेटा लाया जा रहा है | उस पृष्ठ या हैंडलर द्वारा किया गया जिसे इसकी आवश्यकता है; Nexy कोई क्लाइंट डेटा परत शिप नहीं करता (हैंडलर) |
एक क्रिया और उस पर पोस्ट करने वाला फ़ॉर्म, जो किसी भी स्क्रिप्ट के लोड होने से पहले काम करता है:
from nexy.decorators import Action @Actionasync def subscribe(email: str) -> bool: return True<form method="post" action="{{ __actions_path['subscribe'] }}"> <input name="email" type="email"> <button type="submit">Subscribe</button></form><form method="post" action="{{ __actions_path['subscribe'] }}"> <input name="email" type="email"> <button type="submit">Subscribe</button></form>नेक्सी क्या नहीं करती
प्रमाणीकरण, प्राधिकरण, डेटाबेस, अंतर्राष्ट्रीयकरण, पृष्ठभूमि नौकरियां, ईमेल, भुगतान और खोज आपके एप्लिकेशन की ज़िम्मेदारी हैं, फ़्रेमवर्क की नहीं। नेक्सी विस्तार बिंदु देता है और बताता है कि प्रत्येक को कहां प्लग करना है: देखें नेक्सी आप पर क्या छोड़ती है।
उदाहरण के लिए, प्रमाणीकरण उस फ़ोल्डर की निर्भरता में प्लग हो जाता है जिसकी वह सुरक्षा करता है। नेक्सी इसे नीचे दिए गए प्रत्येक मार्ग से पहले चलाता है; उपयोगकर्ता कौन है यह आपका निर्णय है:
from nexy import unauthorizedfrom nexy.http import Request def require_login(request: Request) -> None: if not request.session.get("user"): unauthorized(scheme="Bearer") dependencies = [require_login]उदाहरण के लिए, प्रमाणीकरण, नियंत्रक पर लगे एक गार्ड में प्लग हो जाता है जिसकी वह सुरक्षा करता है। नेक्सी इसे क्लास के प्रत्येक हैंडलर से पहले चलाता है; उपयोगकर्ता कौन है यह आपका निर्णय है:
from nexy import unauthorizedfrom nexy.decorators import Controller, UseGuardfrom nexy.http import Request def require_login(request: Request) -> None: if not request.session.get("user"): unauthorized(scheme="Bearer") @Controller("/account")@UseGuard(require_login)class AccountController: async def get(self) -> dict: return {"ok": True}उदाहरण के लिए, प्रमाणीकरण, उस राउटर की निर्भरता में प्लग हो जाता है जिसकी वह सुरक्षा करता है, जैसा कि FastAPI में है; उपयोगकर्ता कौन है यह आपका निर्णय है:
from fastapi import APIRouter, Depends from nexy import unauthorizedfrom nexy.http import Request def require_login(request: Request) -> None: if not request.session.get("user"): unauthorized(scheme="Bearer") api = APIRouter(prefix="/account", dependencies=[Depends(require_login)])इसका कारण अपने आप में अतिसूक्ष्मवाद नहीं है: एक ढांचा जो आपके ओआरएम या आपकी ऑथ लाइब्रेरी को चुनता है, उसने कुछ ऐसा तय किया है जो केवल आपका एप्लिकेशन ही तय कर सकता है।
अगले चरण
- प्रोजेक्ट संरचना: प्रोजेक्ट का प्रत्येक फ़ोल्डर और फ़ाइल
- शब्दावली: वही शब्द, एक वर्णमाला क्रम में
- नेक्सी कैसे काम करती है: परतें, कौन क्या बनाता है, और नेक्सी आप पर क्या छोड़ती है