Read the dev.to Sanity integration write-up, how does it apply to a mature codebase?
I went through the dev.to article on the Sanity integration for A/B testing and personalization before asking here. It is a clean walkthrough, but it starts from a fresh project.
Our codebase has three years of Sanity schemas, a custom fetch layer with its own caching, and GROQ queries scattered across feature folders. Which parts of the article transfer as-is, and which parts quietly assume you are starting from zero? I would rather know the real integration surface before pitching this internally.
1 answer
Did this on a codebase about your age last quarter, so here is the honest split.
The setup itself transfers as-is. npx croct@latest init works in existing projects, it does not care how old your Sanity schemas are. The slot fetching pattern from the article is also unchanged, you fetch a slot where a component renders and pass default content as the fallback.
Where a mature codebase actually differs, and this surprised me positively: your custom fetch layer stays. Nothing about the integration wants to replace how you query Sanity. The GROQ results you already fetch simply become the fallback passed to the slot fetches, caching and all. We did not touch a single schema or query, we only added the slot calls next to the components we wanted to personalize.
The part the article compresses because it starts fresh is deciding which components to map. With three years of schemas you will not map everything, and you should not. Adoption is gradual and component-level, no migration involved, so we started with two high-traffic components, proved the value, and expanded from there. That is also the shape of the internal pitch that worked for us: no rewrite, no schema changes, two components to start.