Centralize types provided by Kanae

[No767]

Summary

Previously, we had hand-written types and interfaces that would represent the proper schema defined within our OpenAPI schema for Kanae. This was fine but caused a lot of issues - where to actually put them. Types would end up in src/routes/dashboard/events.tsx but get used in src/routes/dashboard/manage/events.tsx, etc. Although I already had a system down for it (types used for dashboard/events.tsx gets stored in there to get used in dashboard/manage/events.tsx instead), this gets confusing very quickly. So, we have a source of truth to our types. Via @hey-api/openapi-ts, we take our OpenAPI schema for Kanae, generate some types, and use them. The types now are defined based off our OpenAPI schema, which actually report the correct types.

The idea behind this is that in Kanae's repo, we have scripts that generate the openapi schema, and this is ran on a release workflow. Then, once the release gets published, we'll dispatch this info (alongside the info like the new tag to use), run a curl request to obtain the versioned OpenAPI schema, run the openapi-ts tool and then push out a PR that has the changes generated. So, effectively, our types are now properly versioned, and end-to-end typed.

I checked and this doesn't change the logic of our code - it compiles and builds just fine.

Note

The @hey-api/openapi-ts tool produces types that use KanaePages, such as KanaePages[FullEvents] being converted to KanaePagesFullEvents. Don't use these are they don't properly reflect the actual generics of it. That's why a separate src/types/pages.ts exists. So what @hey-api/openapi-ts would produce KanaePagesFullEvents, instead KanaePages<FullEvents> should be used instead.

Note

I didn't bother with our Ory types. Doing it would produce a ton of code that would be wasteful and we already have a very constrained and locked-down types and interfaces for it.

Types of changes

What types of changes does your code introduce to the UC Merced's ACM Chapter Website?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (Updates to README.md, the documentation, etc)
• Other (if none of the other choices apply)

Checklist

Put an x in the boxes that apply

• If code changes were made then they have been tested.
• All workflows pass with my new changes
• This PR does not address a duplicate issue or PR

[netlify]

✅ Deploy Preview for ucmacm ready!

Name	Link
🔨 Latest commit	c149231
🔍 Latest deploy log	https://app.netlify.com/projects/ucmacm/deploys/6a7c3b27547ee00008d3129c
😎 Deploy Preview	https://deploy-preview-849--ucmacm.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 78 Accessibility: 97 Best Practices: 92 SEO: 83 PWA: 100 View the detailed breakdown and full score reports

---

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

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.1% Duplication on New Code

See analysis details on SonarQube Cloud