-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds module crud and module crud tests #1377
Conversation
@mino323 is attempting to deploy a commit to a Personal Account owned by @garageScript on Vercel. @garageScript first needs to authorize it. |
Codecov Report
@@ Coverage Diff @@
## master #1377 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 146 147 +1
Lines 2450 2462 +12
Branches 638 626 -12
=========================================
+ Hits 2450 2462 +12
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/c0d3/c0d3-app/3QAsjtPGNg5tgC772YUzMrpH6T3u |
graphql/queryResolvers/moduleCrud.ts
Outdated
} | ||
|
||
export const addModule = async (_parent: void, args: MutationAddModuleArgs) => { | ||
//isAdminOrThrow(req) will add after, easier for testing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not understanding this. Why are we not using isAdminOrThrow
, and instead have it commented out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@anthonykhoa is right, dont put testing code into production!
graphql/queryResolvers/moduleCrud.ts
Outdated
@@ -0,0 +1,35 @@ | |||
// import { Context } from '../../@types/helpers' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove this commented out line
graphql/queryResolvers/moduleCrud.ts
Outdated
|
||
export const addModule = async (_parent: void, args: MutationAddModuleArgs) => { | ||
//isAdminOrThrow(req) will add after, easier for testing | ||
// const authorId = ctx.req.user?.id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove this commented line if its unneeded
graphql/queryResolvers/moduleCrud.ts
Outdated
) => { | ||
// isAdminOrThrow(req) | ||
const { id } = args | ||
if (!id) throw new Error('Missing parameter') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question here, if you have marked id
as required: https://github.com/garageScript/c0d3-app/pull/1354/files#diff-0776d3ad89186de849e067b2a7b9a9701408e7b983a6387c50819581ad6f8f9aR63
Do you still need that check? I would think graphql would handle it for you
What are these changes for? What do we need module crud for? I am confused about the context of this PR and why these changes are needed. Is there some other feature you are working on, and you need to make module crud as a step for that feature? Please add context by description, or link some issue |
import prisma from '../../prisma' | ||
|
||
export const modules = async () => { | ||
return prisma.module.findMany({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm findMany
should already return a promise, right? If that's the case, then it is redundant to make this function async
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also we should add error handling
try {
return prisma.module.findMany(...)
} catch(err) {
// SOME LOGGING
// error handling logic
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@anthonykhoa good point about `async.
also your sample code is wrong, try/catch
does not work for promises. You would have to do:
return prisma.module.findMany(...).catch(...)
We could return empty array on errors so we always guarantee returning an array:
return prisma.module.findMany(...).catch( _e => return [])
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah good idea. returning empty array is appropriate for this scenario.
if (!authorId || !content || !name || !lessonId) { | ||
throw new Error('Missing parameters') | ||
} | ||
return await prisma.module.create({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if this results in error? We should wrap this in a try/catch block
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if this returns an error the front end will get an error, which could render a message. What do you suggest we do in the catch
@anthonykhoa ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah i see that makes sense. In this case I think we should log the error then.
Something that tells us creation of module failed, for example MODULE_CREATION_FAILED_ERROR:${JSON.stringify(error)}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't want to return an error to the frontend, I guess we can return some default value like {}
.
But I think we should throw the error. And then we handle the error from the frontend too. If there is an error thrown in this resolver, we can have error notification popup on the screen saying something like Module Creation Failed
. IMO having an error notification popup would be ideal user experience incase module creation fails.
I can imagine a scenario wherein a user tries to create a module, and it fails; the user thinks it could be their internet, or maybe the user thinks their click on the create
button didn't register, so the user clicks on create
again. Having an error notification in this scenario would create potential for less confusion for users who enter a situation where the create module
feature is not working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apollo already provides an onError
option with their useMutation and useQuery hooks.
https://www.apollographql.com/docs/react/data/error-handling/
args: MutationDeleteModuleArgs | ||
) => { | ||
const { id } = args | ||
await prisma.module.delete({ where: { id } }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should wrap this in a try/catch block
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you suggest we do in the catch
block @anthonykhoa ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Log the error. Incase anything goes wrong, logs would be helpful in issue triaging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mino323 See comment thread on the addModule
function for the discussion about error handling
|
||
export const addModule = async (_parent: void, args: MutationAddModuleArgs) => { | ||
const { authorId, content, lessonId, name } = args | ||
if (!authorId || !content || !name || !lessonId) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we only trying to check if all arguments are present, or instead are we checking if the arguments are not the correct value? For example, if I passed the content
value as empty string(''
), is that considered a missing parameter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you are only trying to check if all required arguments are present, you don't have to do that. Graphql takes care of that for you already -- if you marked in the typedefs that arguments are required for this resolver, then the graphql request will already return an error if a person does not include required arguments in their request.
import type { MutationDeleteModuleArgs, MutationAddModuleArgs } from '..' | ||
import prisma from '../../prisma' | ||
|
||
export const modules = async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should use typescript for all functions you declare so that you can define what they return
@@ -1,34 +0,0 @@ | |||
# |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please undo the deletion of this file. We don't want this file to be deleted
} | ||
|
||
export const addModule = async (_parent: void, args: MutationAddModuleArgs) => { | ||
const { authorId, content, lessonId, name } = args |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we shouldn't have authorId
be passed in, it should be retrieved from the cookie.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is authorId the same as userId?
And is it a requirement that the user has to be logged in before making a call to this resolver?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If authorId=userId, then we set in in req.session
already
session.userId = user.id |
Is it a requirement that user MUST be logged in order to do these crud operations for modules? If so, then we should include a check to make sure users are logged in |
This pr adds module crud and module crud tests.
This continues pr #1346