feat(ledensysteem): add groups and member pages

[Gerbuuun]

Add groups and member pages

🔗 Linked issue

#33 #34

❓ Wat voor soort aanpassing?

• 📖 Documentatie (updates aan JSDoc of README)
• 🐞 Bugfix (een non-breaking change dat een probleem oplost)
• 👌 Enhancement (verbeterd een bestaande functionaliteit: oa. performance)
• ✨ Nieuwe feature (een non-breaking change dat functionaliteit toevoegt)
• ⚠️ Breaking change (fix of feature dat bestaande functionaliteiten verandert)

📚 Beschrijving

📝 Checklist

• Ik heb een issue gelinkt.
• Ik heb de wiki geüpdate gebaseerd op mijn aanpassingen.

[Gerbuuun]

Ik denk dat de basis is gelegd. Ik heb nog wel moeite met types meekrijgen van de api.
Ik kan bijvoorbeeld geen prisma types gebruiken in de pages.
Hierdoor moet ik gebruik maken van unknown en verlies ik dus alle types.
Ook kan Webstorm (ik ook niet trouwens) proteusId vinden in de session user.
@dsluijk hoe zou jij dit aanpakken? Even een yarn typecheck doen en je krijgt te zien wat ik bedoel

[Gerbuuun]

Ok ik ben er dus achter dat VSCode en Webstorm typescript op verschillende manieren interpreteren.
Dus wat in VSCode geen errors geeft, geeft wel errors in Webstorm.
Volgens mij heeft Webstorm moeite met ref types.
Ik heb nu grotendeels shit gefixt maar dit werkt alleen met internal modules import (die je dus met eslint hebt verboden...)
Als laatste: proteusId bestaat nog steeds niet in de session data.
En hoe werken error handlers?

[dsluijk]

proteusId is niet typed, maar die bestaat wel. Het was niet makkelijk om de sessie opnieuw te typen. Ik ben aan het kijken om de sessies iets anders te gaan doen.

[dsluijk]

useRequest heeft error handlers, deze moet je zelf definieren. Elke handler checkt voor een specifieke error condition, en returned een error object op basis daarvan. Deze error is dan weer teruggegeven naar de component met de error ref, volledig typed. Als je false returned uit een error handler, dan wordt de volgende error handler functie gecalled met de error, totdat er een een niet false teruggeeft. Met de errHandler functie kan je ook filteren op het type apiError wat je terugkrijgt, dat hoef je niet die types te checken. Anders kan je gewoon een functie met een parameter geven, maar dan krijg je geen type narrowing per apiError. Dit is handig voor cache-all's. Een voorbeeld is hier te vinden: https://github.com/Proteus-Eretes/mijn-proteus/blob/main/components/Page/Material/TypesCreate.vue#L61

[Gerbuuun]

useFetch brengt helaas weer de null type als union met de returntype van de api route.
Hierdoor gaat de typecheck dus fout.

Ook wanneer je een useRequest een type geeft:

const { error, requesting, send, data } = useRequest<
  Awaited<ReturnType<typeof import("~~/server/api/groups/index.post").default>>
>("/api/groups", {...});

dan worden de errorHandler types unknown.
Dus je kunt of alleen errorHandlers getyped hebben of alleen de return data getyped hebben :(
(totdat nitro update live staat ofc)