Accessing graphql context from loader

[andreialecu]

In loaders it is usually necessary to access the graphql execution context.

As per NestJS documentation I attempted to do it like this:

import { CONTEXT } from "@nestjs/graphql";

@Injectable({ scope: Scope.REQUEST })
export class CanEditMatchdayLoader implements NestDataLoader<string, boolean> {
  constructor(
    private readonly matchdayService: MatchdayService,
    @Inject(CONTEXT) private context: any,
  ) {
    console.log(context); // prints undefined
  }

  generateDataLoader(): DataLoader<string, boolean> {
     ...
  }
}

But context appears to be undefined no matter what I do. I assume this is caused by nestjs-dataloader somehow, because the nestjs documentation specifically mentions this use case.

Alternatively, this would also seem to be fixed by #11

[some-user123]

I also require this functionality and would love to see the PR merged.

It seems there is not too much activity in the repo lately 😢

Any ideas for alternatives?

[krislefeber]

Is it null in both the constructor and in generateDataLoader()? It looks like context is not readonly, which could prevent it from being an instance variable. That's a javascript thing, not nestjs

…

On Mon, Mar 1, 2021, 5:46 AM some-user123 ***@***.***> wrote: I also require this functionality and would love to see the PR merged. It seems there is not too much activity in the repo lately 😢 Any ideas for alternatives? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTWSLADLHX3OAAE6V7TJKTTBN47XANCNFSM4NMGMAFA> .

[dimatillck]

for everyone who still wants to fix it: you need to call this.moduleRef.registerRequestByContextId(ctx, contextId); before calling this.moduleRef.resolve().

https://docs.nestjs.com/fundamentals/module-ref#registering-request-provider

[kommander]

It's undefined in both constructor and generateDataLoader. How can we create a DataLoader based on the context? This seems like a common use case.

[bneigher]

+1 looking to use values decoded from request headers into the actual data loader service call

[bneigher]

looks like this PR does the trick.. any way we can get this merged in?
#11