Gatsby: A Unique Shortcode Issue with Gatsby

Created on 13 Feb 2019  路  6Comments  路  Source: gatsbyjs/gatsby

Summary

First, thanks for reading this ticket. -- I'm struggling to wrap my head around how to implement this.

Within the content of my pages, I have some WordPress style "shortcodes." Overall, processing these shortcodes down to components has been pretty straight forward, except one.

We have a [table name="something"/] shortcode where there is an external DB call needed to pull the data for the table. The data we need isn't known until I get to process the shortcode within the respective page template.

The options I see for getting the data for the table are as follows:

1 -- Preprocess all of the content looking for [table name="something"/] shortcodes in gatsby-node.js and pass in any table "names" found so that the page's GraphQL queries can grab that data. Then marry the data in the components.

2 -- Query all of the tables within each page, and just find the names required to build the page. (Not sure if this will bloat the bundle sizes or anything)

To be honest, I'm pretty comfortable in Gatsby but this issue has thrown me for a loop. Any insight would be much appreciated.

Relevant information

The content with the shortcodes is coming from gatsby-source-prismic and the tables are coming from gatsby-source-pg. All pages are "created" (createPage) in gatsby-node.js.

question or discussion

Most helpful comment

@pieh Thanks for the feedback. How would this become query-able? If I just pass it into pageContext, I can use graphQL? I think I'm missing something.

This is probably part when this gets tricky.

If you don't use transformers for your base data that you are checking you could do this like this: https://gist.github.com/pieh/01dd1b9b5900c48d37443c7d5807bf45

I'm working on testing this now. Would the unused data get put into the final pages Gatsby renders or not?

Yes, it would - we can't really remove "unused data". It could work if we would strip out data that is not used on initial render - but we can't really analyse code to check if there isn't any dynamic functionality that would cause component to use data that was marked as unused.

All 6 comments

2 -- Query all of the tables within each page, and just find the names required to build the page. (Not sure if this will bloat the bundle sizes or anything)

This definitely has potential to bloat / overfetch data. But it also seem like easiest to implement and might not be that bad if you don't have large amount of tables.

1 -- Preprocess all of the content looking for [table name="something"/] shortcodes in gatsby-node.js and pass in any table "names" found so that the page's GraphQL queries can grab that data. Then marry the data in the components.

I think that would be preferable. You would still need to "marry" data in component I think but at least query for tables would return just tables used in given page. Let me know if you need help implementing this approach

Yet another idea (but also more complex than one you proposed):

Still parse content in gatsby-node.js, but instead of just extracting table names do something like this:

For example content:

Lorem ipsum

[table name="foo"]

sit amet

[table name="bar"]

split this into array of:

[
  {
    type: "text",
    text: "Lorem ipsum"
  },
  {
    type: "table"
    table___NODE: `id_of_foo_table_node`
  },
  {
    type: "text",
    text: "sit amet"
  },
  {
    type: "table"
    table___NODE: `id_of_bar_table_node`
  },
]

then you could query:

{
  parsedContent {
    type
    text
    table { // this is now link to table Node
      fieldsFromTableNode
    }
  }
}

and you could iterate over parsedContent array and depending on type either render just text or use some component for table data

@pieh Thanks for the feedback. How would this become query-able? If I just pass it into pageContext, I can use graphQL? I think I'm missing something.

@pieh On this approach:

2 -- Query all of the tables within each page, and just find the names required to build the page. (Not sure if this will bloat the bundle sizes or anything)

This definitely has potential to bloat / overfetch data. But it also seem like easiest to implement and might not be that bad if you don't have large amount of tables.

I'm working on testing this now. Would the unused data get put into the final pages Gatsby renders or not?

@pieh Thanks for the feedback. How would this become query-able? If I just pass it into pageContext, I can use graphQL? I think I'm missing something.

This is probably part when this gets tricky.

If you don't use transformers for your base data that you are checking you could do this like this: https://gist.github.com/pieh/01dd1b9b5900c48d37443c7d5807bf45

I'm working on testing this now. Would the unused data get put into the final pages Gatsby renders or not?

Yes, it would - we can't really remove "unused data". It could work if we would strip out data that is not used on initial render - but we can't really analyse code to check if there isn't any dynamic functionality that would cause component to use data that was marked as unused.

@pieh That example is perfect. Thank you. I know that gatsby-source-prismic is doing some magic behind the scenes to transform their API response to nodes.

I'm going to go this route:

1 -- Preprocess all of the content looking for [table name="something"/] shortcodes in gatsby-node.js and pass in any table "names" found so that the page's GraphQL queries can grab that data. Then marry the data in the components.

As I've already written the shortcode processing logic for all of the other shortcodes at the page level and marrying the data shouldn't be too hard.

Thanks for the support and work on Gatsby. Love it. Long term would like to contribute a bit to the SEO best practices for moderately complex sites. Hope to have something written up that I can share in the future.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

signalwerk picture signalwerk  路  3Comments

kalinchernev picture kalinchernev  路  3Comments

ghost picture ghost  路  3Comments

KyleAMathews picture KyleAMathews  路  3Comments

timbrandin picture timbrandin  路  3Comments