Adds the challenge set instructions page, including possible user actions (most often, starting the challenge set).
I made a design decision for this PR that I'm open to changing in the future:
Before I had a class for each model. However this came with significant downsides, requiring either:
Always fetching the full object, including any relations, or
Treating all properties as optional if they ever might not be fetched. In this case, typescript type-checking is greatly limited. Each method will have to check to make sure the properties it uses are in the object received. Even then it can only throw a runtime error rather than having compile-time safety. And I haven't found a way to distinguish a property that returns undefined from one that was not retrieved.
I'm not thrilled with either option, so instead I'm using a more functional approach with separate functions for computed properties. So far this is only implemented for ChallengeSet, but the idea is to use this approach across the board.
Adds the challenge set instructions page, including possible user actions (most often, starting the challenge set).
I made a design decision for this PR that I'm open to changing in the future:
Before I had a class for each model. However this came with significant downsides, requiring either:
I'm not thrilled with either option, so instead I'm using a more functional approach with separate functions for computed properties. So far this is only implemented for
ChallengeSet, but the idea is to use this approach across the board.All this said, just today Prisma released client extensions, which might be exactly the solution I was looking forward, including declaring which fields your computed properties depend on.
But for now, this will work.