feat(enhancement): Upgrades generated graphql nexus file with more CRUD examples #174
Conversation
mthomps4
changed the title
mthomps4
changed the title
…D examples and proper Input Types
mthomps4
force-pushed
the
mt-update-graphql-template
branch
from
9e79d63
to
52dbd69
Compare
| // export const UserRole = enumType({ | ||
| // name: 'Role', | ||
| // members: Object.values(Role), | ||
| // }); |
There was a problem hiding this comment.
it feels like we might delete this most of the time. I definitely see the value in outlining the Object.values example, but I did want to ask if you think this falls into the "you'll need this often" category.
There was a problem hiding this comment.
Agreed.
It is not an everyday thing, probably something better suited for Docs over a generated file.
Will opt to remove here.
| // Database Specific Fields | ||
| t.nonNull.id('id'); | ||
| t.nonNull.date('createdAt'); | ||
| t.nonNull.date('updatedAt'); | ||
| // Model Specific Fields | ||
| t.nonNull.string('name'); |
There was a problem hiding this comment.
I like the idea of trying to organize some of this. I worry that doing it this way may actually confuse things though. It requires you to ask yourself "is this a database field or a model field". Additionally, the name field that you have here doesn't have a custom resolver so it looks like it would be coming from the database.
Perhaps it would be better not to force the organization and just show an example of a custom resolver for a field?
There was a problem hiding this comment.
Yup, those comments are a bit misleading.
name is in our generated example.
I'll remove the comments and leave it as is.
| t.list.field('<%= plural.toLowerCase() %>', { | ||
| type: '<%= camelized %>', | ||
| t.field('<%= plural.toLowerCase() %>', { | ||
| type: list('<%= camelized %>'), |
There was a problem hiding this comment.
correct me if I'm wrong but I think both of these are equivalent. I feel t.list.field is slightly more straightforward due to the intellisense autocompletion and not requiring an additional import of the list function. thoughts?
There was a problem hiding this comment.
We made this change when troubleshooting the other day.
It is the same...
I'll revert and save an import. 👍🏼
| @@ -25,21 +33,32 @@ export const <%= camelized %>Queries = extendType({ | |||
| type: 'Query', | |||
There was a problem hiding this comment.
while you are here, thoughts on moving this to queryField instead of extendType? Not required, but it does make it a bit more concise.
There was a problem hiding this comment.
Going to leave this one for another ticket.
We'll want to refactor to use query-field and mutation-field throughout in our user module as well to stay consistent.
I'll need to look at that syntax a bit, it looks like each piece would become its own exported queryType.
Description
Upgrades generated graphql nexus file with more CRUD examples and proper Input Types
Changes
GraphQL Nexus template was lacking, had bogus "SOMETHING" and User definitions.
Now generates:
Base Module
Query
thingw/ user logged in guardQuery
list('thing')w/ user logged in guardMutation
createThingw/isAdminguardMutation
updateThingw/IsAdminguardThingWhereInput
ThingWhereUniqueInput
ThingCreateInput
ThingUpdateInput
ThingOrderByInput
Generating a new app works
closes #173