-
-
Notifications
You must be signed in to change notification settings - Fork 675
@FieldResolver not... working? #1006
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
Comments
I just created a vanilla project, very minimal & simple, and the issue is still there. Click here to go to the repo or: $ git clone [email protected]:chiefGui/typegraphql-test.git && cd typegraphql-test && yarn && yarn dev Here's the query, once again: query todos {
todos {
_id
text
}
} FWIW, the only relevant folder is Now I wonder:
|
OK, just tested the same implementation using By the way, I've already done this: #96 (comment). I know the problems are slightly different, but just as a safety measure, and as I was expecting, still didn't have success. I wonder, does |
You can call your queries by code, like: TypeGraphQL builds With next or serverless you need to be aware of minifying the bundle which causes issues. |
Closing for a housekeeping purposes 🔒 |
@MichalLytek sorry to comment on a closed issue but can you provide a bit more clarification on what you mean? When i use nextjs and do graphql via sdl, apollo-server-micro, and micro, things work fine, but when i use typegraphql only queries and mutations work, Field Resolvers are never called. Is there something in babel or webpack that might cause this issue? Here is a repo with both running https://github.com/mrkirchner/NextJS-Typegraphql Thanks for any help. |
@MichalLytek would love to hear more about "With next or serverless you need to be aware of minifying the bundle which causes issues." I've been using field resolvers with no problem when compiling with Webpack and Everything else seems to be working fine. Thanks for a great project btw. .swcrc:
|
An update for anyone who is running into this problem where a I had a redundant
And after that everything works great, whether compiling with |
I was also wrestling with this issue. If I remove the In my case I solved it by combining separate resolver classes for the FieldResolver/Resolver (existing code was a bit weird but seemed to work): From @Resolver(() => Prediction)
class PredictionResolver {
@FieldResolver()
async geometry(@Root() p: Prediction): Promise<any> {
return detailsRequest({
placeId: p.place_id,
fields: ["geometry"],
}).then((res) => (res && res.geometry ? res.geometry : null));
}
}
@Resolver()
class AutocompleteResolver {
@Query(() => [Prediction], { nullable: true })
async autocomplete(@Arg("input") input: string): Promise<Prediction> {
return autocompleteRequest({
input,
});
}
} To @Resolver(() => Prediction)
class AutocompleteResolver {
@Authorized(["ROLE_USER"])
@Query(() => [Prediction], { nullable: true })
async autocomplete(@Arg("input") input: string): Promise<Prediction> {
return autocompleteRequest({
input,
types,
radius,
language,
offset,
strictbounds,
});
}
@FieldResolver()
async geometry(@Root() p: Prediction): Promise<Geometry | null> {
return detailsRequest({
placeId: p.place_id,
fields: ["geometry"],
}).then((res) => (res && res.geometry ? res.geometry : null));
}
} Hope this helps someone. |
Uh oh!
There was an error while loading. Please reload this page.
Describe the Bug
Todo
, with a@Field()
calledtext
TodoResolver
, which has a@FieldResolver()
that is never called.To Reproduce
And the query is:
FWIW, the
tsconfig.json
file is this:Expected Behavior
I'd like to see
text
ashello world
when queryingtodos
; I'm currently seeinghi!
.Logs
There are no errors.
Environment:
Additional Context
From all the examples I've seen/read related to
type-graphql
, the code above seems to be correct. This leads me to believe the problem is elsewhere—turns out I have no clue what this "elsewhere" could be.That said, do you have any ideas on how/where should I be looking to find the culprit for the field resolver not be working? Or rather am I misinterpreting how field resolvers are supposed to work?
Thanks in advance,
Gui.
The text was updated successfully, but these errors were encountered: