writeQuery in getInitialProps about next-with-apollo HOT 13 CLOSED

Just to add to this, If I do something like:

static async getInitialProps ({ apolloClient }) {
  await apolloClient.writeQuery({
    query: MUTATION_WRITE_FACET
  })
  return {}
}

I'll get:

Error writing result to store for query: mutation AddFacet { AddFacet @client } Cannot read property 'AddFacet' of undefined

from next-with-apollo.

It should be possible to query and mutate local state inside getInitialProps, I'm personally doing it but with the API, I think you should not see any change with Apollo dev tools, except for client side navigations, that's because for the first render there's no browser instance so Apollo dev tools will not be aware of what happens in getInitialProps, as a personal recommendation try moving queries and mutations out of getInitialProps, for most cases you should only use the apollo client there to do requests that will decide if the page should be rendered or just do a redirect or show an error, something like that.

from next-with-apollo.

I tried to avoid using the dev tools by using the Query component:

<Query query={ QUERY_GET_FACET }>
  { ({ data }) => (
    <p>{ data.facet.foo }</p>
  ) }
</Query>

However this doesn't seem to change.

My use case is that I want to build a store of breadcrumbs that can be built dynamically, which doesn't really make sense to be used in some kind of container component.

...I'm personally doing it but with the API...

I'm not entirely sure what this means?

from next-with-apollo.

It means that I'm using the apollo client inside getInitialProps but not for apollo-link-state - @client.
You can also use the graphql() HOC instead, will that work for you ?

from next-with-apollo.

HOC won't work as I need to build data dynamically. In redux, this was achieved by dispatching various redux actions in the initial props, which I was hoping to achieve with the apollo client. I'm not sure if this is related to apollographql/apollo-link-state#185

from next-with-apollo.

I just read that issue, in short words apollo-link-state doesn't supports SSR, this comment can be a solution.

I didn't know about that issue with apollo-link-state, but I don't think that ignoring the queries only for SSR is a bad idea, seems like a good solution, at least for the meantime until someone tackles the issue.

from next-with-apollo.

Unfortunately I need SSR for SEO purposes :( So ignoring the query is not an option for me. Anyway, I don't think this is an issue with this project, so I will close this ticket then hope and pray for apollographql/apollo-link-state#185

from next-with-apollo.

Just to quickly add, it looks like writeData will work in getIntialProps:

apolloClient.writeData({
  data: {
    breadcrumbs: ["one", "two", "three"]
  }
})

from next-with-apollo.

I am reopening as I have had some progress:

static async getInitialProps ({ apolloClient }) {
  apolloClient.mutate({
    mutation: MUTATION_WRITE_FACET
  })
  return {}
}

<Query query={ QUERY_GET_FACET }>
  { ({ data }) => {
    console.log(data.facet.foo)
    return <p>Hello</p>
  } }
</Query>

My console shows me:

node_1  | baasdz
node_1  | null

It might be that my page is rendering twice for some reason AND the default cache is overriding the built cache.

from next-with-apollo.

After removing defaults from the client, I have to do something like so, and then things seem to work correctly:

static async getInitialProps ({ apolloClient }) {
  let facet
  
  try {
    apolloClient.readQuery({ query: QUERY_GET_FACET })
  } catch (e) {
    apolloClient.writeData({
      data: {
        facet: {
          __typename: "Facet",
          foo: null
        }
      }
    })
  }

  apolloClient.mutate({
    mutation: MUTATION_WRITE_FACET
  })

  return {}
}

from next-with-apollo.

Related?

• apollographql/apollo-link-state#236

from next-with-apollo.

For SSR all changes to the cache will happen to a cache in the server, only the state of that ApolloClient is sent to the browser, and then a new ApolloClient is created (see this line) using that state, that's how we get the SSR for apollo queries (and by using getDataFromTree).

The double render is because of an issue with react-apollo. I managed to get to the root of the problem some months ago (here), but I didn't have enough time to build a solution, it was more complicated than what I thought.

from next-with-apollo.

I can't thank you enough @lfades for your help. Thank you so much for your hard work. I'm going to close this issue in favour of the upstream issue you linked: #25

from next-with-apollo.