feat: toggle hardcoded schema versions #5
Conversation
There was a problem hiding this comment.
Thanks for picking this one up !! 💖
One early comment which might help narrow scope of what we actually want to select/visualise - happy to find time to keep chatting through this one, realise there's a few related outstanding issues around it too that we should coordinate on 🙂
| queryKey: ["schemas", version], | ||
| queryFn: () => | ||
| fetchFn( | ||
| `${DIGITAL_PLANNING_DATA_SCHEMAS_JSON_URL}/${version}/schema.json` |
There was a problem hiding this comment.
So something tricky to highlight here - since the latest release (v0.7.1), this URL now accounts for a /schemas subdirectory and each released version may have multiple schemas published within in (eg application.json, prototypeApplication.json, preApplication.json, decision.json and so on).
In my mind, the meaningful things to toggle here are:
- Which schema: Application, PreApplication, PrototypeApplication, so on
- Which version: "latest" or "next" only?
- eg this would have tech benefit of letting us deal with same base URL then and just sort of ignore very early versions, which probably aren't as important to visually document? Main purpose of this viewer in my mind is to share with consumers to help explain what they can recieve now and what changes are queued up! Older version in
/distare nice audit history but no longer in active use for any integrations! - I know we need to smooth out
latest&@nextdist folders though! See Smooth out CI build process for@next&latest/dist branch folders digital-planning-data-schemas#242)
- eg this would have tech benefit of letting us deal with same base URL then and just sort of ignore very early versions, which probably aren't as important to visually document? Main purpose of this viewer in my mind is to share with consumers to help explain what they can recieve now and what changes are queued up! Older version in
There was a problem hiding this comment.
Ok cool! There's some groundwork here which will apply to future work but sounds like next steps are:
- add another toggle for schema type
- fix the smooth out CI build issue
- Change the current version toggle to just include next and latest branches
Let me know if there is anything that should be changed implementation wise for this current PR, otherwise I feel like it could be merged as an incremental step towards the above goals 🥅
There was a problem hiding this comment.
Let me know if there is anything that should be changed implementation wise for this current PR, otherwise I feel like it could be merged as an incremental step towards the above goals 🥅
A bit late to the fair here! Very much agree with the above - the next steps here make sense to pick up once we've had a pass through the schema repo and resolved the publishing issues there 👍
| }} | ||
| value={formik.values.version} | ||
| > | ||
| // TODO: add query to populate with a list of possible versions |
Linked with issue: Support dynamic querying...
Next steps
Next steps are to grab these programatically to populate the dropdown!
I think we should be able to do this with the GH api: GET list releases. It returns an array of items, where one of the item's keys is
tag_name, containing the version strings we are currently using in the dropdown.Screenshots