Gatsby: [v2][RFC] Deprecate page queries completely and replace with StaticQuery?

Created on 20 Jul 2018 · 8Comments · Source: gatsbyjs/gatsby

Several people have suggested this and it's started feeling better and better over time.

It'd definitely better to have one pattern for queries rather than two. And the reaction to <StaticQuery> seems positive.

We'd have to add support for <StaticQueries> getting variables passed to them when they're on pages. Which felt weird as that's "magical" but... it's no less magical than the existing page queries. Less since it has a component tied to it.

Oh hmmm... just had a thought — we could create a <PageQuery> component that's identical to <StaticQuery> except it takes variables 🤔

Thoughts?

stale?

Source

KyleAMathews

👍7

Most helpful comment

FWIW, I personally would find it much more intuitive if there were just a single query component, and that the entire pageQuery magic would be removed.

As I am used to Apollo, I would absolutely love it if the query component was similar. I will show this with a complete example to clarify my thoughts.

Old style:

export default ({data}) => {
    return (
        <div>
            <div dangerouslySetInnerHTML={{ __html: data.markdownRemark.html }} />
        </div>
    );
}

export const pageQuery = graphql`
query PageQuery($fileAbsolutePath: String!) {
  markdownRemark(fileAbsolutePath: { eq: $fileAbsolutePath }) {
    html
    frontmatter {
      path
      title
    }
  }
}
`;

Suggested style:

const query = gql`
query PageQuery($fileAbsolutePath: String!) {
  markdownRemark(fileAbsolutePath: { eq: $fileAbsolutePath }) {
    html
    frontmatter {
      path
      title
    }
  }
}
`;

export default ({pageContext}) => (
    <Query query={query} variables={pageContext.context}>
        {({ loading, error, data }) => {
            return (
                <div>
                    <div dangerouslySetInnerHTML={{ __html: data.markdownRemark.html }} />
                </div>
            );
        }}
    </Query>
);

Obviously code could be restructured with the query being at the bottom, if desired. It is a little more boilerplate on each page that uses a query - but it would remove all the magic and allow for much more options on how to query.

Also, loading state in Gatsby is now hardcoded to <div>Loading (StaticQuery)</div>, and probably error state causes some error handler to be invoked. The Apollo way lets the page handle both as it sees fit.

nakedible on 23 Jul 2018

❤8

All 8 comments

I don’t think that a PageQuery and StaticQuery would solve the issue which people have namely that there are two queries. If you could use one query to do both they would be satisfied I guess.

But I wouldn’t like to use the current page queries the way StaticQueries are used — I don’t want to place the huge GraphQL queries I have in the middle of the component, I want to separate that and place it under the component.
My IDE is also giving me highlighting etc for the page queries because that’s the common usage.

For proper type checking and prop destructoring you‘d use:
https://next.gatsbyjs.org/docs/static-query/#typechecking
I would use it this way probably all the time (but my project has no need for staticQueries yet)

Isn’t there a way to upgrade pageQuery to also do the static thing?

LekoArts on 20 Jul 2018

Yeah, the idea is that PageQuery (a new thing, not the existing thing) would work the same way as but be able to take arguments from the pageContext.

You'd still be able to move the query to the bottom still e.g.

import React from 'react'
import { graphql, PageQuery } from 'gatsby'

const Page = ({ data }) => <div><h1>Hi {data.title}</h1><div>{data.body}</div></div>

export default () => (
  <PageQuery
     query={graphql`...the query`}
     render={data => <Page data={data} />}
  />
)

KyleAMathews on 20 Jul 2018

Would it be possible to put the query in a variable (like with the queries on pages right now)? Because otherwise my IDE isn’t recognizing it.

LekoArts on 20 Jul 2018

Not yet but we'd like to support that as well. Which IDE? Most IDEs go off the graphql function I thought.

KyleAMathews on 20 Jul 2018

Oh, seems like the responsible plugin had a little hiccup. The staticQuery "way" now also works :)
Then I'm happy with that (and the variable support).

If someone is interested: That's Webstorm + JS GraphQL plugin

LekoArts on 20 Jul 2018

FWIW, I personally would find it much more intuitive if there were just a single query component, and that the entire pageQuery magic would be removed.

As I am used to Apollo, I would absolutely love it if the query component was similar. I will show this with a complete example to clarify my thoughts.

Old style:

export default ({data}) => {
    return (
        <div>
            <div dangerouslySetInnerHTML={{ __html: data.markdownRemark.html }} />
        </div>
    );
}

export const pageQuery = graphql`
query PageQuery($fileAbsolutePath: String!) {
  markdownRemark(fileAbsolutePath: { eq: $fileAbsolutePath }) {
    html
    frontmatter {
      path
      title
    }
  }
}
`;

Suggested style:

const query = gql`
query PageQuery($fileAbsolutePath: String!) {
  markdownRemark(fileAbsolutePath: { eq: $fileAbsolutePath }) {
    html
    frontmatter {
      path
      title
    }
  }
}
`;

export default ({pageContext}) => (
    <Query query={query} variables={pageContext.context}>
        {({ loading, error, data }) => {
            return (
                <div>
                    <div dangerouslySetInnerHTML={{ __html: data.markdownRemark.html }} />
                </div>
            );
        }}
    </Query>
);

nakedible on 23 Jul 2018

❤8

Old issues will be closed after 30 days of inactivity. This issue has been quiet for 20 days and is being marked as stale. Reply here or add the label "not stale" to keep this issue open!