Join the conversation

Sign in to join this conversation, and others like it, in the communities you care about.

Apollo

A community of developers, designers and others who love Apollo and GraphQL. 馃殌

Apollo / General

We will be getting a new API for apollo-react using hooks soon?

We will be getting a new API for apollo-react using hooks soon?

Apollo/General路 February 13, 2019 at 10:57pm

We will be getting a new API for apollo-react using hooks soon?

Apollo聽/聽General聽路聽February 13, 2019 at 10:57pm

February 13, 2019 at 11:41pm

I'm currently using react-apollo-hooks from Trojanowski on some side projects https://github.com/trojanowski/react-apollo-hooks. I'm happy with that API and I will continue using it until react-apollo supports hooks natively

like-fill
7
  • reply
  • like

February 14, 2019 at 3:10am

From some of the discussion I saw on Twitter it looks like they are waiting for the Suspense API to be finalized before diving into hooks.

like-fill
4
  • reply
  • like

February 14, 2019 at 10:48am

But isn't Suspense in react already?

  • reply
  • like

But isn't Suspense in react already?

Only Suspense for Code Splitting is available in React currently, via React.lazy(). Suspense for Data Fetching will come later this year. Here's the Roadmap: https://reactjs.org/blog/2018/11/27/react-16-roadmap.html

like-fill
1
  • reply
  • like

Ah never got that it's not supported from React side I just thought the ecosystem is not mature enough (react-cache) though the mechanism on react side will be the same, I am not to clear about this. I tried https://github.com/trojanowski/react-apollo-hooks too and its a really great developer experience but not stable enough for production workloads imho.

  • reply
  • like

February 15, 2019 at 9:15am
I tried https://github.com/trojanowski/react-apollo-hooks too and its a really great developer experience but not stable enough for production workloads imho.

@flexzuu what problems did you have?

like-fill
2
  • reply
  • like

I'm currently using react-apollo-hooks from Trojanowski on some side projects https://github.com/trojanowski/react-apollo-hooks. I'm happy with that API and I will continue using it until react-apollo supports hooks natively

That library looks awesome 馃ぉ Thanks for sharing it

like-fill
2
  • reply
  • like

February 15, 2019 at 12:34pm

I just added some details around our current Hooks thoughts, and a plan of attack, here: https://github.com/apollographql/react-apollo/issues/2539#issuecomment-464025309

like-fill
5
  • reply
  • like

February 15, 2019 at 4:58pm

There're two problems with current Apollo Client design:

  • It requires you to create a client explicitly with overhead of creating context, passing headers .... It's not the job of developers.
  • Apollo decided to become modular with Links. It's the best design ? I think no. There're a simpler solution to modular design. My thought on this is: Developer shouldn't know about client, or link to get productive with Graphql. All they need to know is:
  • I put a graphql api url
  • I put a headers when i query
  • I might modify the cache i want.
  • reply
  • like

February 15, 2019 at 6:53pm

@revskill -- have you looked at apollo-boost? That sounds like exactly what you're asking for.

  • reply
  • like

February 21, 2019 at 6:32pm

I was looking at react-apollo-hooks. Looking at the docs, it appears that it doesn't support subscriptions yet.

  • reply
  • like

@fbartho What i mean is this api:

const {data, loading, errors} = useGraphql({url, headers, query, variables})

As you see, it's simple, no ceremony, no configuration beforehand. Why on earth i have to create a client before writing any React Component ? It's wrong to me by the design with React and how we code. If i want to query data, i just put an url, configure a headers and put query there, whenever i want, there's no magic client for me to keep track of it anymore.

Edited
  • reply
  • like

February 22, 2019 at 10:35pm

@revskill I believe client is helpful in maintaining/accessing the client-side cache, etc.

  • reply
  • like

March 4, 2019 at 5:11pm

@revskill The vast majority of the time, your url and headers shouldn't be changing from one call to the next. And it also shouldn't be the responsibility of a UI component to know what the URL is or to set the headers. Encapsulating these things into a client that is then provided to all components in the app (or a sub-tree of the app) using ApolloProvider then makes it extremely easy to make calls to your API from any component.

As VikR001 mentions, the client-side cache is also extremely important. The use of a cache allows us to avoid making a new call to the server every single time a component is re-mounted, and also gives us an easy, single place to update our data when a mutation or subscription causes the data to change

  • reply
  • like

March 4, 2019 at 6:37pm

I would argue there is a sweet spot between the two approaches. Using both in a responsible manner can have great benefits on performance.

  • reply
  • like