Roadmap to complete stable version about react-apollo-hooks HOT 10 CLOSED

What about supporting all the fetch options?

"cache-first" | "cache-and-network" | "network-only" | "cache-only" | "no-cache" | "standby"

I would like to see "cache-and-network" for my use-cases

from react-apollo-hooks.

@rostero1 Could you please open a separate issue with your question? Let's focus on the roadmap here.

from react-apollo-hooks.

Refactor client+query caching: use react context, add error messages (inherit from react-apollo).

Do you mean replace the WeakMap used in queryCache.js with React context? If so I'm not sure it's a good idea. It was introduced in 246208c to fix #23. React context wouldn't work in the following case:

render(
  <Suspense fallback={<MyFallbackComponent />}>
    <ApolloProvider client={client}>
      <MyComponent />
    </ApolloProvider>
  </Suspense>
);

If <MyComponent /> were suspended then <ApolloProvider /> would lose its state, and I guess it's a place where you'd like to store the query cache which should be passed by context. Of course, we could require to always use the provider component at the top of the react tree or require users to create the cache outside the tree and pass it as a property, but I think the current solution is the most ergonomic one.

Bundle with rollup, report bundle size.

Do you mean use rollup for creating a UMD version, ready to use with <script> HTML tags? Are there any benefits of using rollup for creating CJS or ES modules versions?

Find a good way to replace lodash with interal utilities.

Right now only a small subset of lodash is added to the final app bundle, and it may be already added by other libraries. So I'm not sure if moving it to internal utilities would lower its size.

Add more recipes and examples (most developers mindset is not prepared for hooks and Suspense yet).

👍 Great idea. I'd appreciate any contributions here.

from react-apollo-hooks.

Do you mean replace the WeakMap used in queryCache.js with React context? If so I'm not sure it's a good idea. It was introduced in 246208c to fix #23.

I was thinking about simple context createContext(new WeakMap()) that will use same singleton instance but still allow to inject another WeakMap instance in unit tests.

Do you mean use rollup for creating a UMD version, ready to use with <script> HTML tags? Are there any benefits of using rollup for creating CJS or ES modules versions?

Mostly for rollup-plugin-size-snapshot that allows to track bundle size between PRs. Web community loves to freak out about npm package sizes.

Right now only a small subset of lodash is added to the final app bundle, and it may be already added by other libraries. So I'm not sure if moving it to internal utilities would lower its size.

Lately github introduces new feature that bugs you about unstable libs. So even if my code is 100% stable - I have to publish new version with updated dependency version. That's the reason I'm removing third party utilities from my repos.
But it's just a suggestion.

from react-apollo-hooks.

@lindskogen There are supported right now in the non-suspense mode. With suspense, we'll have to emulate these options. I tried to add support for cache-and-network in #15. I don't need them right now and not sure I'll have time to work on them in the near future, but I'd accept PR.

from react-apollo-hooks.

I'm very new to apollo and graphql. I might be having some issues with no-cache and was wondering if this was the appropriate place.

const { error, fetchMore, data, loading } = useQuery(MyQuery, {
  fetchPolicy: 'no-cache',
  suspend: false,
  ssr: false,
  variables: {
    cursor: '',
    pageSize: pageSize,
    search: '',
    orderBy: orderBy
  },
});

fetchMore({
  query: MyQuery,
  variables: {
    cursor: endCursor,
    pageSize: pageSize,
    search: searchTerm,
    orderby: orderBy,
  },
  updateQuery: (_, { fetchMoreResult }) => {
    console.log('fetchMoreResult', fetchMoreResult)
    return fetchMoreResult;
  },

After the initial load, I search, then I change the page size. Now fetchMoreResult logs the correct response from the server, but data seems to be showing the initial response (which is not the response I requested).

from react-apollo-hooks.

I think the problem was that sometimes it was using the variables from fetchMore and sometimes it was using variables from useQuery. After I have them both use the same variables, the problem seemed to resolve itself. How do I know which variables are being applied, though?

from react-apollo-hooks.

Hi @trojanowski, in #15 you said you're gonna wait with its implementation until suspense for data fetching is released. According to the react roadmap that's not gonna happen before mid 2019. Any plans to release the other four PRs (especially #21 ) before that? That would be very helpful. Thank you

from react-apollo-hooks.

@schlesingermatthias all of those PRs are already released and available in the latest version.

from react-apollo-hooks.

I'm going to close this issue because IMO this library can be considered stable to use (in the non-suspense mode). I created a new meta issue with a list of breaking changes planned for the next version: #138.

from react-apollo-hooks.