Open SOHELAHMED7 opened 4 years ago
Can confirm I have noticed this behaviour too - my guess is that this because there are sort of two createPage
processes happening. The original - which isn't actually running, and then the shadowed one which is running. Hence an empty createPage call.
Hiya!
This issue has gone quiet. Spooky quiet. 👻
We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open! As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!
Thanks for being a part of the Gatsby community! 💪💜
Hey again!
It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY
. Please feel free to reopen this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!
Thanks again for being part of the Gatsby community! 💪💜
Hiya!
This issue has gone quiet. Spooky quiet. 👻
We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open! As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!
Thanks for being a part of the Gatsby community! 💪💜
From https://github.com/gatsbyjs/gatsby/issues/20413
Sice I use headless CMS for sourcing Gatsby I can not rely that CMS user creates always all page types for all Gatsby's templates. Thus it is common for me that some templates remain unused. I was looking for some "if" condition to prevent this warning but unsuccessfully. So currently my log is filling with this misleading information. It would be nice to have a way how to say that unused templates can be intentional and do not printing warnings.
Getting the same error :/
warn The GraphQL query in the non-page component "/Users/CESARMAC/Desktop/XUP/xup/packages/webapp-lists/src/templates/list.js" will not be run.
import React from 'react'
import { graphql } from 'gatsby'
import Helmet from "react-helmet";
import SEO from '../components/SEO'
import List from '../features/List'
function ListTemplate({ data, pageContext }) {
const { sanityListInstance: listInstance } = data
return (
<>
<SEO
title={listInstance?.list.title}
imageSrc={listInstance?.list.image.asset.fixed.src}
imageHeight={listInstance?.list.image.asset.fixed.height}
imageWidth={listInstance?.list.image.asset.fixed.width}
/>
<List
list={listInstance}
/>
</>
)
}
export default ListTemplate
export const pageQuery = graphql`
query ListInstancesById($id: String!) {
sanityListInstance(id: { eq: $id }) {
customId
activeDate {
local
}
list {
title
_updatedAt(formatString: "MMMM Do, YYYY")
_rawDescription(resolveReferences: { maxDepth: 10 })
image {
asset {
fluid(maxHeight: 544, maxWidth: 1000) {
...GatsbySanityImageFluid
}
}
asset {
fixed(width: 960) {
...GatsbySanityImageFixed
}
}
}
experienceStop {
place {
...placeFields
}
event {
...eventFields
}
}
tags {
name
}
listDate {
local
}
}
}
}
`
const Promise = require("bluebird");
const path = require("path");
const dateFns = require("date-fns");
const { addDays, format, endOfDay, parseISO, startOfDay } = dateFns;
const { DateTime } = require("luxon");
const nodeEnv = process.env.NODE_ENV;
const yearMonthDayFormat = "yyyy-MM-dd";
exports.createPages = ({ graphql, actions }) => {
const { createPage } = actions;
return new Promise((resolve, reject) => {
const listTemplate = path.resolve("./src/templates/list.js");
const listPreviewTemplate = path.resolve(
"./src/templates/listPreview.js"
);
const legalDocumentTemplate = path.resolve("./src/templates/legal.js");
resolve(
graphql(
`
{
allSanityListInstance {
edges {
node {
id
list {
slug {
current
}
}
activeDate {
local
}
customId
}
}
}
allSanityLists {
edges {
node {
id
slug {
current
}
}
}
}
allSanityLegal {
edges {
node {
_updatedAt
title
slug {
current
}
}
}
}
}
`
).then((result) => {
if (result.errors) {
console.log(`Error! This is what happened ${result.errors}`);
reject(result.errors);
}
result.data.allSanityListInstance.edges.forEach(({ node }) => {
node.list &&
createPage({
path: `/lists/${node.list.slug.current}`,
component: listTemplate,
context: {
id: node.id,
},
});
});
if (nodeEnv === "development") {
result.data.allSanityLists.edges.forEach(({ node }) => {
node.slug &&
createPage({
path: `/lists/${node.slug.current}`,
component: listPreviewTemplate,
context: {
id: node.id,
},
});
});
}
const legalDocuments = result.data.allSanityLegal.edges;
const formattedLegalDocuments = legalDocuments.map(
({ node: document }) => ({
...document,
path: `/legal/${document.slug.current}/`,
})
);
formattedLegalDocuments.forEach((document) => {
createPage({
...document,
component: legalDocumentTemplate,
context: {
title: document.title, // Used for query
documents: formattedLegalDocuments,
},
});
});
})
);
});
};
exports.onCreatePage = ({ page, actions }) => {
const { createPage, deletePage } = actions;
deletePage(page);
createPage({
...page,
context: {
...page.context,
},
});
};
in my experience: Gatsby scrapes all graphql
calls to execute staticly. all. This includes original files, and shadows. So while your shadowed file is the one that get run and the query is being used as the pageQuery, it has still found the original query and is still executing that query. Since it now is not a page, it will throw the non-page component
error as it always does in querys that are not pages/templates/
Thanks @laurenskling, that is a helpful observation. This issue has been causing me some confusion when trying to shadow a file that makes a call to useStaticQuery
, which then errors because Gatsby complains about multiple root queries.
Am I to understand that the only workaround at this point is to replace the shadowed theme with your own, forked version of a theme?
I imagine a thorough reading of the documentation might reveal this limitation, but it seems worth highlighting in the documentation clearly.
For instance, in section about shadowing themes to say something like "Note: shadowing does not prevent Gatsby from scraping graphql queries from the original file, so if you want to change the behavior of a file that contains a top level query, you will have to fork rather than shadow the theme".
multiple root queries is about your shadow having the same name as the original (since that one is run as well). If you change the name of the query you can run a query in your shadow. Just be aware the original is being scraped and prepared too. So if the shape of your schema changes, the original query can fail and fail your entire build :(
I would love to see a response from the gatsby team. There's little attention going to theming and shadowing if you ask me, which is scary for me since I use it heavily.
Even though you can shadow templates with queries when using a theme, I would avoid it. Shadowing queries makes your site brittle. A theme could make changes to its queries without breaking its (NPM package) API. But this could break your shadowed query. This would take anyone by surprise who is not familiar with how themes and shadowing work.
I think a good way to structure themes is to separate the logic/queries from the layout, which some of the official themes have adopted. E.g. there is gatsby-theme-blog-core
, which contains queries and minimal layout, and there is gatsby-theme-blog
, which shadows layouts. If you wanted to adopt this theme, you could shadow all the layouts of the core theme to give it a personalized look and feel. It's very tempting to add a missing feature to the core theme by shadowing template queries and then pick up these changes in a shadowed layout. But to shadow a query you need to duplicate it and then modify it. If the original query changes in a future update, you have a problem.
If you have the need to shadow queries, this might be an indication that you should consider submitting a pull request to the (core) theme you are using or roll our own core theme, which you can then fully customize.
Gatsby themes are very powerful, but they come with many pitfalls. It's so easy to author a theme that inadvertently creates implicit dependencies on the Gatsby graph or is based on the assumption that there is only one version of a specific Gatsby plugin in the dependency graph. I ran into really hard to debug errors when using Gatsby themes that I could only fix brute force with Yarn resolutions.
I wonder if many of the theming related problems can be fixed at all or whether themes and related APIs need to be reinvented. It could also be that many organizations do not have the need to package logic and styling as a reusable theme when they have only one web property.
I would be curious to hear more from the Gatsby team.
Ah yes, @maiertech, seems you are quite right. I tried to following @laurenskling advice, but ran into more problems, where the query doesn't pick up the data from my sanity hosted graphql data, put just uses the place holder data. (Not sure what is happening there !!??). I think the best approach in my case is to just fork the theme and modify it for my own purposes.
Yeah... themes seem kind of inflexible, and brittle.
@haberdashPI If you are using a theme make sure they separate queries and presentational components as @maiertech talked about theme authors need to understand this structure and that modifying it is a breaking change. But you should be safe to shadow the query as long as the theme author doesn't change the name/location of that file. You can see examples of this below in my repo of Gatsby themes, specifically with SANITY as well. Let me know if you have any questions. But my themes still throw this error, because some queries intentionally go unused at times in the build/dev process.
Thanks @ehowey, so if I understand you correctly what I was trying to do should have worked. (Actually I am using your theme as a starting point already, thanks so much!!). I am not sure what went wrong. However, I have found a reasonable workaround, that makes my life a lot easier, and I don't actually need to shadow any GraphQL queries in that setup. If I find a really do need to shadow I can try digging into this a little deeper, and provide an update here for people who find themselves in the same situation.
@haberdashPI sounds good! Glad it all got working for you. Feel free to ping me if you have questions and want to talk in more detail via ZOOM or email - but I don't want to clutter up this issue.
@haberdashPI
However, I have found a reasonable workaround, that makes my life a lot easier,
Could you please give more information about your workaround? I'm facing exactly the same problem as in your repository: https://github.com/LekoArts/minimal-blog-additional-field - I need to add a subtitle field.
I am still getting this issue, when a page template is not being used (hence the template is not being rendered as a page)
Does anyone have a solution?
It's only a warning, it shouldn't stop you in any form. You can just ignore the warning.
Really hoping one day themes and shadowing will get some love again. I'm heavily invested in it.
Description
When trying to shadow a GraphQL query I am getting a warning during build process in CLI. However the project runs fine in localhost
Warning:
E.g. Shadowed File
/path-to/project-name-leko-minim/src/@lekoarts/gatsby-theme-minimal-blog-core/templates/page-query.tsx
:Steps to reproduce
Reproduce repo- https://github.com/LekoArts/minimal-blog-additional-field
git clone https://github.com/LekoArts/minimal-blog-additional-field.git
cd minimal-blog-additional-field
npm i
gatsby develop
Expected result
There should be no warning message
Actual result
Build should be successful without any warning
Environment
Run
gatsby info --clipboard
in your project directory and paste the output here.