Skip to content
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

Closed
wants to merge 5 commits into from
Closed

Conversation

anso3
Copy link
Collaborator

@anso3 anso3 commented Jan 31, 2022

This pr adds module crud and module crud tests.
This continues pr #1346

@vercel
Copy link

vercel bot commented Jan 31, 2022

@mino323 is attempting to deploy a commit to a Personal Account owned by @garageScript on Vercel.

@garageScript first needs to authorize it.

@codecov
Copy link

codecov bot commented Jan 31, 2022

Codecov Report

Merging #1377 (a4c31a3) into master (c498cab) will not change coverage.
The diff coverage is 100.00%.

Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
graphql/queryResolvers/moduleCrud.ts 100.00% <100.00%> (ø)

@vercel
Copy link

vercel bot commented Jan 31, 2022

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/c0d3/c0d3-app/3QAsjtPGNg5tgC772YUzMrpH6T3u
✅ Preview: https://c0d3-app-git-fork-mino323-ago-c0d3.vercel.app

}

export const addModule = async (_parent: void, args: MutationAddModuleArgs) => {
//isAdminOrThrow(req) will add after, easier for testing
Copy link
Collaborator

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?

Copy link
Contributor

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!

@@ -0,0 +1,35 @@
// import { Context } from '../../@types/helpers'
Copy link
Collaborator

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


export const addModule = async (_parent: void, args: MutationAddModuleArgs) => {
//isAdminOrThrow(req) will add after, easier for testing
// const authorId = ctx.req.user?.id
Copy link
Collaborator

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

) => {
// isAdminOrThrow(req)
const { id } = args
if (!id) throw new Error('Missing parameter')
Copy link
Contributor

@songz songz Feb 1, 2022

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

@anthonykhoa
Copy link
Collaborator

anthonykhoa commented Feb 1, 2022

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({
Copy link
Collaborator

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

Copy link
Collaborator

@anthonykhoa anthonykhoa Feb 1, 2022

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
}

Copy link
Contributor

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 [])

Copy link
Collaborator

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({
Copy link
Collaborator

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

Copy link
Contributor

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 ?

Copy link
Collaborator

@anthonykhoa anthonykhoa Feb 3, 2022

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)}

Copy link
Collaborator

@anthonykhoa anthonykhoa Feb 3, 2022

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.

Copy link
Collaborator

@anthonykhoa anthonykhoa Feb 4, 2022

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 } })
Copy link
Collaborator

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

Copy link
Contributor

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 ?

Copy link
Collaborator

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.

Copy link
Collaborator

@anthonykhoa anthonykhoa Feb 3, 2022

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) {
Copy link
Collaborator

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?

Copy link
Collaborator

@anthonykhoa anthonykhoa Feb 1, 2022

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 () => {
Copy link
Collaborator

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 @@
#
Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Collaborator

@anthonykhoa anthonykhoa Feb 3, 2022

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?

Copy link
Collaborator

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

@anthonykhoa
Copy link
Collaborator

anthonykhoa commented Feb 3, 2022

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

@anso3 anso3 closed this Feb 11, 2022
@anso3 anso3 deleted the ago branch February 16, 2022 13:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants