sanity-config-reducers

โดย sanity-io

เพิ่มและตรวจสอบคุณสมบัติการกำหนดค่า Sanity ที่ถูกรวมลดจากคอนฟิกรากและปลั๊กอิน ใช้เมื่อเพิ่มแฟล็กเบต้า การกำหนดค่าฟีเจอร์ ตัวเลือกเวิร์กสเปซ/แหล่งข้อมูล…

npx skills add https://github.com/sanity-io/sanity --skill sanity-config-reducers

Sanity Config Reducers

Start Here

Use this skill when a config value can be supplied by root config or plugins and needs deterministic merge behavior.

Inspect these files first:

  • packages/sanity/src/core/config/types.ts
  • packages/sanity/src/core/config/configPropertyReducers.ts
  • packages/sanity/src/core/config/prepareConfig.tsx
  • packages/sanity/src/core/config/flattenConfig.ts
  • packages/sanity/src/core/config/resolveDefaultPlugins.ts if the config gates default plugin injection.

Reducer Pattern

Reducers usually:

  1. Call flattenConfig(config, []).
  2. Reduce from an explicit initialValue.
  3. Read the property from each innerConfig.
  4. Ignore undefined.
  5. Accept only the documented type.
  6. Throw with getPrintableType(value) for invalid values.

Config namespaces should usually be objects, even when they initially only contain one flag. This keeps room for future options without changing the public shape. For booleans, prefer feature.enabled and follow this shape:

export const featureEnabledReducer = (opts: {
  config: PluginOptions
  initialValue: boolean
}): boolean => {
  const {config, initialValue} = opts
  const flattenedConfig = flattenConfig(config, [])

  return flattenedConfig.reduce((acc, {config: innerConfig}) => {
    const enabled = innerConfig.feature?.enabled

    if (typeof enabled === 'undefined') return acc
    if (typeof enabled === 'boolean') return enabled

    throw new Error(
      `Expected \`feature.enabled\` to be a boolean, but received ${getPrintableType(enabled)}`,
    )
  }, initialValue)
}

Root config is flattened after plugin config, so root values usually win when a reducer overwrites with the latest defined value.

Types And Exposure

When adding a config property:

  • Declare the public or internal input type in PluginOptions, WorkspaceOptions, or the relevant nested type in types.ts.
  • Prefer extensible object namespaces such as beta.feature.enabled over direct booleans such as beta.feature.
  • If runtime code needs the resolved value, expose it on Source, Workspace, or the relevant prepared object in prepareConfig.tsx.
  • Keep raw config access through source.__internal.options as an implementation detail, not the primary runtime API.

Default Plugin Gates

Default plugin lists are computed before full source resolution. If a config value controls default plugin injection:

  • Compute the reduced value early enough in prepareConfig.tsx, before calling getDefaultPlugins.
  • Thread that reduced value into getDefaultPluginsOptions or the options passed to getDefaultPlugins.
  • Use the same reducer later when exposing the resolved runtime value, so gating and runtime context agree.
  • Add tests for default false/true behavior and invalid values.

Beta Flags

Beta flags live under BetaFeatures in types.ts and resolved runtime values under source.beta.

Prefer a dedicated reducer when:

  • Plugins can set or override the flag.
  • Invalid values should produce helpful errors.
  • The flag gates default plugin injection.

Do not special-case beta flags in components by reading raw config if a resolved value can be exposed instead.

Verification

Add focused config tests for:

  • Default value.
  • Root config value.
  • Plugin-provided value.
  • Root-over-plugin precedence when relevant.
  • Invalid namespace object error message when the top-level config is malformed.
  • Invalid nested property error message, for example when enabled is not the documented type.

Skills เพิ่มเติมจาก sanity-io

tdd
sanity-io
การพัฒนาที่ขับเคลื่อนด้วยการทดสอบด้วยวงจรแดง-เขียว-ปรับปรุง ใช้เมื่อผู้ใช้ต้องการสร้างฟีเจอร์หรือแก้ไขบั๊กโดยใช้ TDD กล่าวถึง "แดง-เขียว-ปรับปรุง" ต้องการ...
performance-optimization
sanity-io
ปรับปรุงประสิทธิภาพการทำงานของแอปพลิเคชัน ใช้เมื่อมีข้อกำหนดด้านประสิทธิภาพ เมื่อสงสัยว่าประสิทธิภาพลดลง หรือเมื่อ Core Web Vitals หรือเวลาโหลด...
content-experimentation-best-practices
sanity-io
แนวทางที่มีโครงสร้างสำหรับการออกแบบ ดำเนินการ และวิเคราะห์การทดสอบเนื้อหาเพื่อปรับปรุงอัตราการแปลงและการมีส่วนร่วม ครอบคลุมกรอบสมมติฐาน การเลือกเมตริก การคำนวณขนาดตัวอย่าง และการทดสอบนัยสำคัญทางสถิติสำหรับการทดสอบแบบ A/B และหลายตัวแปร รวมถึงแหล่งข้อมูลโดยละเอียดเกี่ยวกับค่า p ช่วงความเชื่อมั่น การวิเคราะห์กำลัง และวิธีแบบเบย์สำหรับการตีความผลลัพธ์ มีรูปแบบการบูรณาการ CMS สำหรับจัดการตัวแปรในระดับฟิลด์และการเชื่อมต่อภายนอก...
content-modeling-best-practices
sanity-io
แนวทางการสร้างแบบจำลองเนื้อหาที่มีโครงสร้างสำหรับการออกแบบสคีมา ความสามารถในการนำกลับมาใช้ใหม่ และการส่งมอบเนื้อหาหลายช่องทาง ครอบคลุมหลักการสำคัญ: การจัดการเนื้อหาในฐานะข้อมูลมากกว่าหน้าเว็บ การรักษาแหล่งข้อมูลเดียวที่เชื่อถือได้ การออกแบบสำหรับช่องทางในอนาคต และการปรับปรุงขั้นตอนการทำงานของผู้เขียน รวมถึงกรอบการตัดสินใจสำหรับการอ้างอิงเทียบกับวัตถุที่ฝังตัว การแยกส่วนความรับผิดชอบ และรูปแบบการนำเนื้อหากลับมาใช้ใหม่ ให้คำแนะนำด้านอนุกรมวิธานและการจำแนกประเภทสำหรับแนวทางแบบราบ ลำดับชั้น และแบบแง่มุม ใช้ได้กับ...
portable-text-conversion
sanity-io
แปลงเนื้อหา HTML และ Markdown เป็นบล็อก Portable Text สำหรับ Sanity ใช้เมื่อย้ายเนื้อหาจาก CMS รุ่นเก่า นำเข้า HTML หรือ Markdown เข้าสู่ Sanity…
portable-text-serialization
sanity-io
เรนเดอร์และซีเรียลไลซ์ Portable Text เป็น React, Svelte, Vue, Astro, HTML, Markdown และข้อความธรรมดา ใช้เมื่อต้องการใช้งานการเรนเดอร์ Portable Text ในฟรอนต์เอนด์ใดๆ…
sanity-best-practices
sanity-io
แนวทางปฏิบัติที่ดีที่สุดและคู่มือการผสานรวมที่ครอบคลุมสำหรับการพัฒนา Sanity CMS ในหลากหลายเฟรมเวิร์กและหัวข้อ ครอบคลุมการผสานรวมเฟรมเวิร์กมากกว่า 10 รายการ รวมถึง Next.js, Nuxt, Astro, Remix, SvelteKit และ Angular พร้อมรูปแบบเฉพาะของเฟรมเวิร์กและคำแนะนำในการตั้งค่า รวมถึงคู่มือหัวข้อสำหรับการออกแบบสคีมา การปรับแต่งคิวรี GROQ, Visual Editing, Portable Text, รูปภาพ, TypeGen, การแปลภาษา และการย้ายเนื้อหา มีโครงสร้างอ้างอิงด่วนสำหรับโหลดเฉพาะคู่มือที่เกี่ยวข้องตามประเภทงาน...
sanity-migration
sanity-io
วางแผน ดำเนินการ และตรวจสอบการย้ายข้อมูลจากระบบ CMS และระบบเนื้อหาอื่น ๆ มาสู่ Sanity ใช้เมื่อต้องการย้ายหรือเปลี่ยนแพลตฟอร์มไปยัง Sanity จาก AEM, Adobe Experience Manager, Contentful, Strapi, Webflow, WordPress, Payload, Drupal, ไฟล์ Markdown/MDX/frontmatter, การส่งออก WXR/XML, API ของ CMS, การดัมพ์ฐานข้อมูล, HTML แบบคงที่ หรือเมื่อออกแบบขั้นตอนการทำงานสำหรับการสกัด การแปลง การแปลง Portable Text การย้ายสินทรัพย์ การเปลี่ยนเส้นทาง การตรวจสอบความถูกต้อง และการตัดโอเวอร์
data-analysisdatabasedevelopment