Fix in-text-citations for detection

[vincerubinetti]

Description

Summarize the changes

Fixes: showing in-text-citations for detection field on locus page

Checklist

• All changes are well summarized
• Check all tests pass
• Check that the website preview looks good
• Update the STRchive version in CITATION.cff, format X.Y.Z. If any major changes, increment Y. If only minor changes, increment Z. If the breaking change (rare), increment X.
• Ask someone to review this PR

[netlify]

✅ Deploy Preview for strchive ready!

Name	Link
🔨 Latest commit	43c38ce
🔍 Latest deploy log	https://app.netlify.com/projects/strchive/deploys/6a430d182796600008f787bb
😎 Deploy Preview	https://deploy-preview-500--strchive.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[vincerubinetti]

In the first commit, I simply add detection to the hard-coded list of fields that support in-text citations. Doing it as a hard-coded list makes it easy to maintain type-safety.

The second commit does some more complex TypeScript magic to automatically pick fields on the locus/curation that its corresponding schema says are in_text_citations, extract citations from them, and consider them the more complex citation object type instead of the original string type, maintaining type-safety throughout. Note that this automatic method is limited to one specific "level" of the locus/curation or schema at a time, so it's not a perfect catch-all. For example if you wanted to automatically extract any citable fields in curation.genetic_evidence_details[], you'd have to call extractAllCitations again at that specific level. It'd be too complex to recursively do all nested fields.

I'll let you decide which method you find to be better.

[hdashnow]

Declaring which fields contain in-text citations in the scheme seems like it would be easier for us to maintain in the future. What if we wanted citations inside the criTRia nested details fields? Would one of these approaches work better than the other for this?

[vincerubinetti]

The only way I can think of to make nested citable fields work in a type-safe way (which is important for avoiding bugs), is to simply parse and render ALL string fields as if they could have citations in them. That is, call extractCitations on every string field, and still make sure to use the <Cited> component when rendering any string field (regardless of whether it actually can have citations or not).

This feels a little heavy handed to me though, I'm thinking we'd want to retain fine-grained control over how each field is displayed instead of forcing them all into one bucket.

I'm leaning towards just keeping the first commit. It's simplest to just keep it hard-coded for now. This means "in_text_citations": true isn't really doing anything on the website, it's just there in the schema for external users. And you'll have to manually call extractCitations on the fields you want it on. But I think that's okay: 1) I'll be around for the foreseeable future to remember to do this, 2) If you ask any AI agent why citations aren't being rendered for a certain field, it should be able to figure it out quickly, 3) We're already hand-picking how we render each field on the locus page anyway (i.e. this field gets comma-joined, this field gets put through <Cited>, etc) so why not hand-pick the extraction logic too.