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

apollo-angular prevents Zone from becoming stable #2251

Closed
diesieben07 opened this issue Apr 30, 2024 · 6 comments · Fixed by #2252
Closed

apollo-angular prevents Zone from becoming stable #2251

diesieben07 opened this issue Apr 30, 2024 · 6 comments · Fixed by #2252

Comments

@diesieben07
Copy link

diesieben07 commented Apr 30, 2024

Describe the bug

When apollo-angular is used with Angular SSR and a GraphQL query is made from an APP_INITIALIZER then Angular hydration is delayed by about 10 seconds.
This happens, because ApolloClient uses setTimeout when constructed to suggest you to use its devtools. This setTimeout prevents Zone from becoming stable, delaying hydration.

To Reproduce
Use apollo-angular from within an APP_INITIALIZER in an Angular App using Angular 17 SSR. Observe the "Angular hydrated ..." message being delayed.

Expected behavior

apollo-angular should not delay hydration / ApplicationRef#isStable.

Environment:

├── @angular/[email protected]
├── @angular/[email protected]
├── @apollo/[email protected]
├── [email protected]
├── [email protected]
└── [email protected]

Additional context

To fix this, the call to the ApolloClient constructor should be wrapped in zone.runOutsideAngular. I have worked around this problem like so:

export function provideGraphql(): EnvironmentProviders {
    return makeEnvironmentProviders([
        {
            provide: Apollo,
            useFactory: () => {
                // Apollo must be created outside the Angular Zone, because ApolloClient starts a `setTimeout` for its
                // devtools connection
                // this setTimeout prevents NgZone from becoming stable
                const zone = inject(NgZone);
                const options = inject(APOLLO_OPTIONS, { optional: true }) ?? undefined;
                const namedOptions = inject(APOLLO_NAMED_OPTIONS, { optional: true }) ?? undefined;
                const flags = inject(APOLLO_FLAGS, { optional: true }) ?? undefined;
                // Note the following line:
                return zone.runOutsideAngular(() => new Apollo(zone, options, namedOptions, flags));
            },
        },
        {
            provide: APOLLO_OPTIONS,
            useFactory: () => {
                const httpLink = inject(HttpLink);
                return {
                    link: httpLink.create({ uri }),
                    cache: new InMemoryCache(),
                } satisfies ApolloClientOptions<unknown>;
            },
        },
    ]);
}
@PowerKiKi
Copy link
Collaborator

This is documented in https://the-guild.dev/graphql/apollo-angular/docs/performance/server-side-rendering#using-apollo-devtools, and the better solution is:

// When providing options
{
  provide: APOLLO_OPTIONS,
  useFactory: () {
    return {
      connectToDevTools: false
      // ...
    };
  },
},
 
// Or when creating the client
apollo.create({
  connectToDevTools: false
  // ...
})

@PowerKiKi PowerKiKi closed this as not planned Won't fix, can't repro, duplicate, stale May 1, 2024
@diesieben07
Copy link
Author

But... does that not disable the Apollo Developer tools, which I want to use?

@PowerKiKi
Copy link
Collaborator

It is not possible to use Apollo Developer tools on server side, but if you want to keep using it on the browser side, then you can do it conditionally, with something roughly like that:

const platformId = inject(PLATFORM_ID);
const isBrowser = isPlatformBrowser(platformId);

return {
    ssrMode: !isBrowser,
    connectToDevTools: isBrowser,
};

@diesieben07
Copy link
Author

Yes, I want to use the Developer tools on the client, not on the server.
Disabling it on the server is not going to solve this issue, because the issue is connectToDevTools on the client side in the first place.
connectDevTools being enabled makes Apollo spawn a 10 second long setTimeout. This setTimeout prevents Zone.js from becoming stable (until it completes) and this delays Angular hydration by those 10 seconds.

This issue is even relevant with no SSR at all, still preventing ApplicationRef#isStable for 10 seconds. The fact is just that with SSR and hydration it becomes fairly obvious, because hydration is tied to isStable.

@PowerKiKi
Copy link
Collaborator

PowerKiKi commented May 2, 2024

Disabling it on the server is not going to solve this issue

Create a minimal reproduction case that attempts that, probably in a dedicated repository, and then we can work on it

no SSR at all, still preventing ApplicationRef#isStable

What is your use-case for a stable application in the browser ?

@diesieben07
Copy link
Author

diesieben07 commented May 2, 2024

Create a minimal reproduction case that attempts that, probably in a dedicated repository, and then we can work on it

https://github.com/diesieben07/apollo-angular-stable-repro

To reproduce start the dev server (npm start). Open the application in the browser and look at the console. Note how the "Angular hydrated..." message takes 10 seconds to appear.

The same can be observed in production (npm run build then npm run serve:ssr:apollo-angular-stable-repro). Unfortunately there is no way to get Angular to log the "Angular hydrated..." message in production, so you'll have to either take my word for it or check yourself that Angular starts hydration when ApplicationRef#isStable turns true. I have also logged that value manually, so the effect can be observed in production that way.

This delay goes away if the APP_INITIALIZER that accesses Apollo (in app.config.ts) is commented out / removed.

What is your use-case for a stable application in the browser ?

I do not have one, because this is a fairly niche feature of Angular. It is however used for SSR. My argument here was that this issue exists completely separate from and is not related to any kind of server side rendering.

PowerKiKi added a commit that referenced this issue May 2, 2024
Otherwise, we might encounter a delay of 10 seconds, and this might lead
to suboptimal experience as described in https://angular.io/errors/NG0506

Fixes #2251
PowerKiKi added a commit that referenced this issue May 2, 2024
Otherwise, we might encounter a delay of 10 seconds, and this might lead
to suboptimal experience as described in https://angular.io/errors/NG0506

Fixes #2251
PowerKiKi added a commit that referenced this issue May 2, 2024
Otherwise, we might encounter a delay of 10 seconds, and this might lead
to suboptimal experience as described in https://angular.io/errors/NG0506

Fixes #2251
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 a pull request may close this issue.

2 participants