แบ่งงานสามฝ่าย

§1สามชั้น สามเจ้าของ

• astro-inkbrush (เอนจิน): CMS ขนาดเล็กที่สุดเท่าที่จำเป็น — แก้ไขบล็อกตรงในหน้าเว็บผ่านเบราว์เซอร์ ประวัติการแก้ไขระดับบล็อกพร้อมย้อนคืน คอมเมนต์ ถาม-ตอบ/เกลาสำนวน/แปลด้วย AI และการนำเข้าจากกล่องขาเข้า มันยังเป็นเจ้าของสิ่งหนึ่งที่ดูเผิน ๆ ไม่น่าใช่ของ CMS: ไวยากรณ์เฉพาะของ Markdown กับตัวตรวจเนื้อหา เหตุผลนั้นแข็งเป็นเหล็ก: ไวยากรณ์ที่ตัวแก้ไขยอมรับ กับไวยากรณ์ที่หน้าเว็บเรนเดอร์ ต้องเป็นชุดเดียวกัน ไม่อย่างนั้น "เซฟในตัวแก้ไขผ่าน แต่เรนเดอร์บนหน้าเพี้ยน" ก็เป็นแค่เรื่องของเวลา กติกาของ parser จึงเขียนครั้งเดียวในเอนจิน แล้วถูกใช้ในสามที่ — การเรนเดอร์ของไซต์ การตรวจตอนเซฟของ CMS และการตรวจใน CI
• astro-inkstone (กระดาษ — แพ็กเกจนี้): ชั้นหน้าตาและไปป์ไลน์ที่ใช้ร่วมกัน — ดีไซน์โทเคนสองระดับในสองบริบท สไตล์ชีตเนื้อหา base.css กับชั้นหนังสือ browse.css คลังคอมโพเนนต์ พรีเซ็ตไปป์ไลน์ siteMarkdown ตัวช่วยจัดหมวดหมู่และลิงก์ย้อนกลับที่สวนแห่งนี้รันอยู่ ซับเซ็ตฟอนต์โค้ด Maple Mono CN และตัววัดชั้นเรนเดอร์ทั้งสอง มัน ไม่ ยุ่งกับเอกลักษณ์ของไซต์: สีแบรนด์ chrome ของเลย์เอาต์ เส้นทาง URL และการดีพลอย ไม่ใช่ธุระของมันเลย
• ไซต์ (อย่างสวนที่คุณกำลังอ่าน): โอเวอร์ไรด์โทเคนระดับที่หนึ่งเพื่อสีประจำตัว เป็นเจ้าของ Sidebar และ chrome นำทางของตัวเอง (โค้ดของไซต์นี้คือคำตอบอ้างอิง) ตัดสินใจว่าเนื้อหาจัดระเบียบอย่างไร เส้นทาง URL หน้าตาเป็นแบบไหน และดีพลอยไปที่ใด

หนึ่งประโยคไว้จำ: เอนจินทำหน้าที่แก้ไข กระดาษดูแลหน้าตา ส่วนไซต์คือตัวคุณ

§2ทำไมเส้นแบ่งอยู่ตรงนี้

ทุกรอยตัดมีข้อจำกัดจริงหนุนหลัง:

ไวยากรณ์เฉพาะเป็นของเอนจิน เพราะตัวตรวจที่ชุดปลั๊กอินไม่ตรงกับของไซต์ แย่ยิ่งกว่าไม่มีตัวตรวจ — ตัวตรวจที่ขาดปลั๊กอินคณิตศาสตร์จะอ่านวงเล็บปีกกาในสูตรผิดเป็นนิพจน์ JSX ตัวที่ไม่มี GFM จะปล่อยเส้นตั้งของตารางผ่านหน้าตาเฉย ไวยากรณ์จึงเขียนครั้งเดียวและถูกใช้ในสามที่ มันเลยไม่มีวันเคลื่อนออกจากกัน

สไตล์เป็นของกระดาษ เพราะเมื่อหลายไซต์ต่างดูแลสไตล์ชีตเนื้อหาของตัวเอง การแก้คอนทราสต์หนึ่งจุดต้องไล่แก้ทีละไซต์ — พลาดไซต์เดียว ตัวอักษรเล็กของไซต์นั้นก็หล่นต่ำกว่า AA แต่ในชั้นที่ใช้ร่วมกัน แก้ครั้งเดียวถึงทุกที่

เอกลักษณ์เป็นของไซต์ เพราะวินาทีที่ชั้นส่วนกลางกลืนสีแบรนด์ของไซต์ใดไซต์หนึ่งเข้าไป ไซต์อื่นทุกไซต์ต้องมาสู้กับมันด้วยการโอเวอร์ไรด์ นี่คือที่มาของโทเคนสองระดับ: ไซต์โอเวอร์ไรด์จานสีดิบระดับที่หนึ่ง (--p-*) แล้วชั้นเชิงความหมายกับชั้นคอมโพเนนต์ตามไปโดยไม่ต้องแตะ — ดู จานสีสองระดับกับธีม

§3กลไกการเลือกดูอยู่ตรงไหน

วินัยเดียวกันนี้ใช้กับสิ่งที่คุณกำลังใช้นำทางอยู่ตอนนี้ด้วย แพ็กเกจส่ง กลไก มาให้ — createTaxonomy (การแก้ค่า kind/domain/แท็ก การสืบทอดจากฮับ มิเรอร์ข้ามภาษา), createBacklinks (ดัชนีลิงก์ย้อนกลับ) และคอมโพเนนต์เชิงแสดงผลอย่างการ์ดบันทึกกับแถวหมวดหมู่บนหน้าแรก ส่วนไซต์เป็นเจ้าของ คำศัพท์และเส้นทาง: kind กับ domain ของสวนนี้อยู่ในไฟล์ทะเบียนของมันเอง และหน้า /kind/…, /domain/…, /tag/… ก็เป็นหน้า Astro ธรรมดาที่ไซต์ผู้ใช้คัดลอกไปดัดแปลงได้ การแบ่งแบบเดิม ยกขึ้นมาอีกชั้น: กลไกอยู่ในแพ็กเกจ ความหมายอยู่ที่ไซต์

§4ไซต์ได้อะไรบ้าง

จากมุมของไซต์ การใช้แพ็กเกจนี้บวกกับเอนจินแลกมาซึ่ง:

• astro-inkstone/styles/tokens.css + base.css + browse.css: โทเคนก่อน ตามด้วยคอลัมน์อ่าน แล้วชั้นหนังสือ — @import สามบรรทัดได้หน้าตาทั้งหมด
• siteMarkdown(...): ไปป์ไลน์ Markdown ทั้งเส้นในบรรทัดเดียว สวิตช์แต่ละตัวอธิบายไว้ใน เริ่มต้นใช้งาน
• คอมโพเนนต์ใต้ astro-inkstone/components/ นำเข้าตามพาธตามที่ต้องใช้
• โรงงานจัดหมวดหมู่กับตัวสร้างลิงก์ย้อนกลับใต้ astro-inkstone/lib/ ผูกกับทะเบียนของไซต์เอง
• ในโหมด WIKI: CMS เต็มรูปแบบของเอนจิน (ลองกับไซต์นี้ได้ด้วย npm run wiki)
• การตรวจสอบห้าด่าน: check-content, check-wikilinks และ check-dist (มากับเอนจิน) กับ ui_probe และ contrast_probe (มากับแพ็กเกจนี้) — ดู ชุดการตรวจสอบ

ทุกเอฟเฟกต์การเรนเดอร์บนทุกหน้าของสวนนี้คือผลผลิตของการแบ่งงานชุดนี้ — บันทึกคือคู่มือ และคู่มือคือเดโม