Update post lib to use WP posts per page value

[GuilleAngulo]

Description

It updates the variable post per page querying readingSettingsPostsPerPage. If the previous POST_PER_PAGE variable is set, it will use it displaying a warn:

'You are using the deprecated POST_PER_PAGE variable. Use your WordPress instance instead to set this value ("Settings" > "Reading" > "Blog pages show at most").'

It is used a functionality similar to apollo client, memoizing the value in order to avoid extra requests (since it is used in various spots)

Fixes #171

[colbyfayock]

just out of curiosity, do you think this is better suited as its own individual query?

wouldn't we have it available throughout the application to easily use if we added it to the site query?

next-wordpress-starter/src/data/site.js

Line 3 in 76e4f01

export const QUERY_SITE_DATA = gql`

thoughts?

[GuilleAngulo]

ah thats a really good idea! totally missed. I will make the changes, thanks @colbyfayock !

[GuilleAngulo]

Having a problem with this approach: If we store this value withing the site context, we can't have access to it inside fetching functions (getStaticProps) to pre-render as is required to generate the pagination ... Do you know if there is a way to retrieve this context data inside getStaticProps? Maybe in this case its worth having like its now?

[colbyfayock]

so interestingly, i was using NextAuth which passes looks at the context available as an arugment on getServerSideProps, i wonder if it's available on there by change?

https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation

i'm not sure how NextAuth is doing it though so might be a long shot

[GuilleAngulo]

I think they work with cookies: when using getServerSideProps is possible to extract from that context object the http request and check the cookie with the info. In the case of getStaticProps is not possible.... trying to figure out if there is another way to do it ..

[colbyfayock]

can you merge in the latest into here? then ill see if i can poke around a little bit

[GuilleAngulo]

@colbyfayock let me see if I can push it, I had some WIP and now the branch is looking little different 😅 (is a mess with testing lines xD).
Sorry I couldnt back to this one this days, didnt find one clear answer on how to structure it...

EDIT: Done!

[GuilleAngulo]

After researching what the approach might be, I haven't come up with any clear answers 😞. Here are some findings/tries I made (in case are useful):

• To use some data obtained in App.getInitialProps (_app.js) in other pages (without being getServerSideProps) it can be done through the getInitialProps function inside the pages. I discarded this approach since at pages/posts/page/[page].js it is required to use getStaticPath which doesnt have access to this initial context (and probably is not a good idea change the fetching methods)

// _APP.JS

App.getInitialProps = async function (appContext) {
   ...
   const metadata = await getSiteMetadata();

  appContext.ctx.postsPerPage = metadata.postsPerPage;
  const appProps = await NextApp.getInitialProps(appContext);

  return {
    ...appProps,
    ...otherProps
}

// INDEX.JS

Home.getInitialProps = async ({ postsPerPage }) => {
  ...
}

Other approachs that could work, but maybe not suitable solution:

• Fetch and pass all posts to the component, and make the pagination treatment inside the component. Doesnt seem like the best idea to pass all the site posts to the component and slice the target posts client side...
• Keep the way it was originally at the PR. But it would mean that for every page we would be making the same request (making extra calls for the same data).
• We could treat this variable as the plugins: fetching the data with the other plugins (maybe making it no optional) and writing to a json file. Then we could read from that file on the getStaticProps function of the pages.

What do you think the approach should be? Thoughs on other alternatives?

[colbyfayock]

hm yeah, i poked around a bit and i see what you mean

as far as the current solution you're proposing, do you think we even need to memoize? wouldn't the query get cached?

[colbyfayock]

i love the idea of a config, maybe we can play around with that idea separately

the only concern is dealing with issues like the wp search index where it was causing build issues on first run

[GuilleAngulo]

About config it would be nice, because it also can work for #173 and other WP variables at one place. Hopefully using the node path module for the read there should be no problems, but that's something we can only know by testing in that environment...

About the current solution, you have a great point: memoize is not required as Apollo is already doing that work. Should I fix that part and leave this solution for now?

[colbyfayock]

yeah i think that sounds good, works for me. and if you want to merge in the latest again, got a conflict it .gitignore 😅

[GuilleAngulo]

Oops not sure what happened ... just made the changes, and force pushed to the branch but it closed 😶 ... I will reopen on another PR with the last changes.

[colbyfayock]

😳

[GuilleAngulo]

I was playing with git reset while testing and probably pushed with no changes by error 😓 . Luckily I had the changes locally, I'm opening another PR with the same solution