Closed phryneas closed 2 months ago
patrick91
commented
2 months ago I like the idea how having less mental load on users of the library!
should we also export all our other hooks from this package to prevent further confusion
I think that would be cool, but I wonder if this would work well with auto imports, right?
For example ApolloClient could come from multiple places. I don't know if you have any ideas about this?
phryneas
commented
2 months ago @patrick91 We could suggest ESLint configuration to warn on wrong imports.
Also, with https://github.com/apollographql/apollo-client-nextjs/pull/206 we should catch most cases where people use a "wrong hook".
phryneas
commented
2 months ago I'm going to pick up this PR and scope it back for a bit now
@apollo/client-react-streaming will already have the final shape (but in this PR still contain the hooks, will remove those in a stacked PR)@apollo/experimental-nextjs-app-support will have the shape from before the package splitThat will be what we ship as 0.9.0
I'll open another follow-up PR for 0.10.0 that introduces the / import for @apollo/experimental-nextjs-app-support and deprecates the /ssr and /rsc ones in another follow-up, probably 0.11.0
new reduced scope for 0.9.0
@apollo/client-react-streamingwill already have the final shape (but in this PR still contain the hooks, will remove those in a stacked PR)@apollo/experimental-nextjs-app-supportwill have the shape from before the package splitThat will be what we ship as 0.9.0
I'll open another follow-up PR for 0.10.0 that introduces the
/import for@apollo/experimental-nextjs-app-supportand deprecates the/ssrand/rscones in another follow-up, probably 0.11.0## original scope
The idea of this change would be that usage of Apollo Client between RSC and SSR/Browser would be more inline by unifying how we handle imports. Right now, in RSC you have to ```js import { ApolloClient, HttpLink, InMemoryCache } from "@apollo/client"; import { registerApolloClient } from "@apollo/experimental-nextjs-app-support/rsc"; ``` and in SSR/Browser, you'd do ```js import { ApolloNextAppProvider, NextSSRInMemoryCache, NextSSRApolloClient, SSRMultipartLink, } from "@apollo/experimental-nextjs-app-support/ssr"; ``` This change would unify that: * `NextSSRApolloClient` and `NextSSRInMemoryCache` are renamed to `ApolloClient` and `InMemoryCache` (old names are still exported, but with a deprecation warning) * both RSC and SSR/Browser now import from `@apollo/experimental-nextjs-app-support` instead of `.../ssr` and `.../rsc` - the bundler can handle that (old entry points are still available - this was already a change made in the new packaging setup) * On RSC, we also export `AccumulateMultipartResponsesLink`, `RemoveMultipartDirectivesLink` and `SSRMultipartLink` - because why not? :) So usage would change like this in RSC ```js import { HttpLink } from "@apollo/client"; import { ApolloClient, InMemoryCache, registerApolloClient } from "@apollo/experimental-nextjs-app-support"; ``` and in SSR/Browser, you'd do ```js import { ApolloNextAppProvider, InMemoryCache, ApolloClient, SSRMultipartLink, } from "@apollo/experimental-nextjs-app-support"; ``` This should make it more intuitive to use this package. Some additional thoughts: * should we also export all our other hooks from this package to prevent further confusion?