{"$schema":"https://ui.shadcn.com/schema/registry-item.json","name":"rich-text-section-1-demo-content","title":"Rich Text Section 1 Demo Content","description":"Demo article body content with headings, lists, tables, and code blocks for rich text section previews.","registryDependencies":["@initium/rich-text-section-types"],"files":[{"path":"components/pro-blocks/landing-page/rich-text-sections/rich-text-section-1-demo-content.tsx","content":"import type { RichTextTocItem } from \"./rich-text-section-types\"\n\nexport const RICH_TEXT_SECTION_1_TOC: RichTextTocItem[] = [\n  { label: \"Why teams adopt it\", href: \"#article-why-it-exists\" },\n  { label: \"Not a package (the way you think)\", href: \"#article-not-a-package-the-way-you-think\" },\n  { label: \"Adding your first component\", href: \"#article-adding-a-component\" },\n  { label: \"When it is a good fit\", href: \"#article-closing\" },\n]\n\nexport function RichTextSection1DemoContent() {\n  return (\n    <>\n      <p>\n        <strong>A component-first workflow</strong> is an approach to shipping interfaces in{\" \"}\n        <em>React</em> where the UI code lives in{\" \"}\n        <strong>your repository</strong>, not only inside <code>node_modules</code>\n        . You typically add pieces with the CLI (<code>npm create product@latest</code>),\n        then edit the files like any other feature. The docs, examples, and team conventions live alongside the code. It is{\" \"}\n        <del>just another opaque component library you npm-install once</del>{\" \"}\n        closer to a <em>pattern</em> for owning your components.\n      </p>\n\n      <h2 id=\"article-why-it-exists\">Why teams adopt it</h2>\n      <p>\n        Most teams outgrow cookie-cutter themes but still want accessible,\n        well-structured primitives. A component-first workflow sits on familiar foundations—\n        often{\" \"}\n        <a href=\"https://www.radix-ui.com\" rel=\"noreferrer noopener\" target=\"_blank\">\n          Radix UI\n        </a>{\" \"}\n        for behavior and{\" \"}\n        <a href=\"https://tailwindcss.com\" rel=\"noreferrer noopener\" target=\"_blank\">\n          Tailwind CSS\n        </a>{\" \"}\n        for styling—while avoiding a hard wall between &ldquo;the library&rdquo;\n        and &ldquo;our product code.&rdquo;\n      </p>\n\n      <h2 id=\"article-not-a-package-the-way-you-think\">\n        Not &ldquo;one package to rule them all&rdquo;\n      </h2>\n      <p>\n        You are not importing a monolithic <code>@vendor/ui</code> where every\n        button upgrade is a semver cliff. You copy source into{\" \"}\n        <code>components/ui</code> (or a path you choose), so refactors ride along\n        with your normal review and release process.\n      </p>\n\n      <h3 id=\"article-what-you-get\">What you actually get</h3>\n      <p>\n        Pre-built pieces—dialogs, forms, navigation, data tables, and more—wired\n        to tokens and composition patterns that match how modern Next.js and Vite\n        apps are structured.\n      </p>\n\n      <h4 id=\"article-stack-shape\">How the stack fits together</h4>\n      <p>\n        Think of it as three layers you can explain in a stand-up without\n        hand-waving:\n      </p>\n      <ul aria-label=\"Layers of a typical component setup\">\n        <li>\n          <strong>Primitives</strong> handle focus traps, keyboard interaction,\n          and ARIA roles.\n          <ul>\n            <li>\n              Radix (or similar) supplies the <em>behavior</em>.\n            </li>\n            <li>\n              Your Tailwind theme supplies the <em>look</em>.\n              <ul>\n                <li>\n                  Design tokens map to CSS variables so light and dark modes\n                  stay coherent.\n                </li>\n              </ul>\n            </li>\n          </ul>\n        </li>\n        <li>\n          <strong>Composition</strong> means small pieces combine into flows\n          instead of one giant widget API.\n        </li>\n      </ul>\n\n      <h5 id=\"article-cli-role\">Where the CLI helps</h5>\n      <p>\n        The CLI scaffolds files, pulls registry definitions, and keeps boilerplate\n        consistent—so you spend time on product decisions, not on retyping the\n        same dialog shell for the tenth time.\n      </p>\n\n      <h6 id=\"article-license-note\">Licensing and usage</h6>\n      <p>\n        The project is open source; always read the current license in the repo\n        you are using. Treat third-party primitives the same way you would any\n        other dependency for compliance.\n      </p>\n\n      <blockquote>\n        <p>\n          The goal is not to hide complexity behind a version number—it is to\n          give you a <em>starting point</em> you can read, change, and ship with\n          confidence.\n        </p>\n      </blockquote>\n\n      <blockquote>Copy the code. Own the implementation. Ship the feature.</blockquote>\n\n      <h3 id=\"article-adding-a-component\">Adding your first component</h3>\n      <p>\n        A typical flow looks like this—your exact commands may vary by framework\n        and registry:\n      </p>\n      <ol aria-label=\"Example steps to add a component\">\n        <li>\n          Initialize the project integration (once per app).\n          <ol>\n            <li>\n              Run the init command from the docs for your stack.\n              <ol>\n                <li>Confirm Tailwind and paths in the generated config.</li>\n                <li>\n                  Commit the new config and base styles with the rest of your\n                  setup PR.\n                </li>\n              </ol>\n            </li>\n            <li>Verify the dev server still builds and styles resolve.</li>\n          </ol>\n        </li>\n        <li>\n          Add a component by name; open the new file and adjust tokens or\n          structure to match your design system.\n        </li>\n      </ol>\n\n      <p>Three ideas teams repeat when they talk about component systems in production:</p>\n      <ul aria-label=\"Common themes when adopting a component system\">\n        <li>\n          <h4 id=\"article-pillar-accessibility\">Accessibility by default</h4>\n          <p>\n            Focus management and keyboard paths come from battle-tested\n            primitives, which reduces the chance of shipping a custom modal that\n            traps users.\n          </p>\n        </li>\n        <li>\n          <h4 id=\"article-pillar-customization\">Customization without forks</h4>\n          <p>\n            Because the code is local, you refactor a button the same way you\n            refactor any other module—no waiting on upstream releases for a\n            one-line token tweak.\n          </p>\n        </li>\n        <li>\n          <h4 id=\"article-pillar-ownership\">Ownership of the surface area</h4>\n          <p>\n            Your bundle and your bugs are yours to profile and fix; the trade-off\n            is you maintain what you adopt.\n          </p>\n        </li>\n      </ul>\n\n      <h3 id=\"article-table-cli\">\n        Example: fictional install counts after a sprint\n      </h3>\n      <p>\n        Tables are rare in essays but common in docs. Here is a compact\n        illustration with <strong>caption</strong>, <strong>thead</strong>,{\" \"}\n        <strong>tbody</strong>, and <strong>tfoot</strong>—numbers are for\n        layout testing only.\n      </p>\n      <table id=\"specimen-table\">\n        <caption>\n          Components added by a team during a two-week spike (illustrative)\n        </caption>\n        <thead>\n          <tr>\n            <th scope=\"col\">Component</th>\n            <th scope=\"col\">Files touched</th>\n            <th scope=\"col\">Follow-up tasks</th>\n            <th scope=\"col\">Status</th>\n          </tr>\n        </thead>\n        <tbody>\n          <tr>\n            <td>Button</td>\n            <td>\n              <p>3</p>\n            </td>\n            <td>Token review</td>\n            <td>Shipped</td>\n          </tr>\n          <tr>\n            <td>Dialog</td>\n            <td>5</td>\n            <td>\n              <p>Focus trap QA</p>\n            </td>\n            <td>In review</td>\n          </tr>\n        </tbody>\n        <tfoot>\n          <tr>\n            <th scope=\"row\">Lesson</th>\n            <td colSpan={3}>\n              Small, reviewable PRs beat landing a dozen unfamiliar abstractions\n              on Friday afternoon.\n            </td>\n          </tr>\n        </tfoot>\n      </table>\n\n      <h3 id=\"article-closing\">When it is a good fit</h3>\n      <p>\n        If your team wants <strong>control</strong>, clear file ownership, and\n        patterns that match React plus Tailwind ecosystems, this workflow is worth\n        evaluating. If you need a fully centralized design program with zero local\n        variance, a stricter kit might feel more familiar—there is no single\n        winner for every org.\n      </p>\n      <p>\n        <strong>Takeaway:</strong> treat reusable patterns as{\" \"}\n        <em>accelerated scaffolding</em>, not magic. The quality of your product\n        still comes from product sense, testing, and the constraints you encode in\n        your tokens—so retire the myth that{\" \"}\n        <del>a download fixes design discipline</del> tooling replaces critique\n        and iteration.\n      </p>\n    </>\n  )\n}\n","type":"registry:component"}],"meta":{"tags":["rich text","article","typeset","long form","content"]},"categories":["rich-text-sections"],"type":"registry:component"}