Approaches to pulling global settings from Sanity into a Next.js app

Just wondering how other people typically approach pulling global settings from Sanity into their app. For example, a site colour theme. I was thinking of using

getInitialProps

in the

_app.js

component and wrapping the site in a component using React context. Any other approaches that would work well or better than my idea?

Soon you can just query from the component: https://nextjs.org/blog/next-12#react-server-components (not sure if it’s quite ready for prime yet though).
You sacrifice the static build capabilities by pulling it in

_app.js

 I believe. Another strategy is to have a pre-build script that pulls in the data and writes it to a JSON file that you can import where you need it.

Query from the component will be great.
A pre-build script would probably be a good idea. I was hoping to avoid using

getInitialProps

. Thanks for the insight User!

What User said. Until then you can do what I do and add a script to your next.config.json that pulls the data and saves it as a json file in the public folder.

I think that’s what I’ll do. Thanks User!

I use https://github.com/ricokahler/next-plugin-preval for my global site settings, which saves a buncha API fetchs

Very cool, thanks User!

I go a different route, and have a global <Layout> component that I wrap all my pages with and pass global

site

and relative

page

data to

You can peep that setup in hull: https://github.com/User/HULL

I was actually looking at the hull repo before posting about this. Great project BTW!

thank you!

I looked at Nextjs doc again recently, it says

Adding a custom 

getInitialProps

 in your 

App

 will disable Automatic Static Optimization  in pages without Static Generation .

I take that means it’ll only disable static optimization for pages that don’t export a

getStaticProps

, wonder if it’s a recent change?

https://nextjs.org/docs/advanced-features/custom-app#caveats

if that’s the case that’s an great option. That would mean it’s not a problem for most people anyway. I remember that caveat differently so it may have been a change or I might just remember it wrong.
Edit after refreshing what

getInitialProps

is: Downside is that

getInitialProps

is a server render function. So each request to load a page would result in a call to an external API.

It’s updated 2 years ago https://github.com/vercel/next.js/pull/13205/files so it shouldn’t be a new thing… nevertheless the wording is confusing 😓 I’m tempted to give it a try but I’m happy with my fetch json thing

Yeah 😅 my fetch json thing works fine as well. But server components will simplify that a lot. I wonder though, if you server render the header for example, will that be a request for each page that uses that component?
This is something I feel Gatsby has a much better handle on than Next.

From what I understand it could trigger a request for each page, if so it won’t be a good fit for things that probably won’t change much like global data and stuff. One could potentially fetch a json and hard-coded it into a server component, thought that lead us right back to square one, but with extra steps

I’ve been thinking about pulling all that global data into a json file and use GROQ to query it. But I can’t find much info on how to use GROQ for anything that isn’t sanity data directly 😅

I’ve actually looked into it recently, all you need is https://github.com/sanity-io/groq-js !

Thanks I was looking for that one earlier today. I stumbled on it a while back but couldn’t remember where I found it 😄

Unpopular opinion. We don't use static generation because we don't want to rebuild our app on every CMS change. We had this issue when we tried Gatsby years back. I use a combination of getInitialProps on the _app and getServerSideProps on the individual pages. Then we have a cache layer on top of that external to Next.js so the page requests are all cached.

Unpopular opinion. We don't use static generation because we don't want to rebuild our on every CMS change. I use a combination of getInitialProps on the _app and getServerSideProps on the individual pages. Then we have a cache layer on top of that external to Next.js so the page requests are all cached.

nice, that’s kinda oldschool I think. Are you hosting with vercel / netlify in that case? Curious why you wouldn’t choose to use ISR, as it won’t require rebuilding the app on every CMS change.

It might be old school to some, but I'd wager it's what the majority of large organizations do. At one point in time, before Vercel and Netlify existed (they are brand new in the grand scheme of things), and before our company grew to it's current size, we used Heroku here on Marketing. Man we hated it. Site constantly crashed. Ran into so many issues. Eventually our DevOps teams on Product really ramped up, so to save a shit load of money (and I mean a shit load) and a shit load of headache (and I mean a shit load), we moved to their architecture and came in-house.
Once Vercel (then Zeit) came onto the scene, I stated a case to leave the in-house deployment architecture and move all our sites to Zeit Now, but was denied (rightfully so).

do you have an example of running a pre-build script via

next.config.js

?

Yep, this might not be exactly what you're after, but I wrote about fetching layout data from an external source in next.js about a year ago. Here's the link to the article: https://maxkarlsson.dev/blog/layout-in-next-js-from-external-source
The main gist is this snippet:

You should be able to adapt that to suit your needs

Right, I've seen that code snippet. Thanks User.

Another approach I’ve seen is to add a

prebuild

entry to

package.json

to run the script.