@graphcommerce/docs 9.0.0-canary.99 → 9.0.0

package/framework/caching.md

@@ -152,22 +152,33 @@ cache.
 
 The service worker caches:
 
-- [static fonts](https://github.com/shadowwalker/next-pwa/blob/master/cache.js#L28)
-- [static images](https://github.com/shadowwalker/next-pwa/blob/master/cache.js#L39)
-- [\_next/image](https://github.com/shadowwalker/next-pwa/blob/master/cache.js#L50)
-- [js](https://github.com/shadowwalker/next-pwa/blob/master/cache.js#L85)
+- [static fonts](https://github.com/serwist/serwist/blob/main/packages/next/src/index.worker.ts#L27):
+  Google fonts and webfonts with StaleWhileRevalidate strategy
+- [static images](https://github.com/serwist/serwist/blob/main/packages/next/src/index.worker.ts#L64):
+  jpg, jpeg, gif, png, svg, ico, webp with StaleWhileRevalidate strategy
+- [\_next/image](https://github.com/graphcommerce-org/graphcommerce/blob/main/packages/service-worker/runtimeCaching.ts#L6):
+  Custom implementation with StaleWhileRevalidate and nextImagePlugin
+- js and css files: Only for files outside of `_next/static` with
+  StaleWhileRevalidate strategy
+
+Notable differences from previous implementation:
+
+- All `_next/static` files (js, css) are excluded from runtime caching as they
+  are handled by the precache mechanism
+- Cross-origin requests use NetworkOnly strategy instead of NetworkFirst
+- Image caching has been optimized with custom configuration for better
+  performance
 
 Note: When a new deployment is made, the service worker is updated. This means
 that all previous caches are cleared and new caches are created.
 
 It does not cache:
 
-- [\_next/data](https://github.com/shadowwalker/next-pwa/blob/master/cache.js#L107):
-  Although it looks like it does, the regex is actually wrong and it does not
-  cache anything.
-- [pages](https://github.com/shadowwalker/next-pwa/blob/master/cache.js#L152)
+- [\_next/data](https://github.com/ducanh-99/serwist/blob/main/packages/next/src/index.worker.ts#L137):
+  Uses NetworkFirst strategy to ensure fresh data
+- [pages](https://github.com/ducanh-99/serwist/blob/main/packages/next/src/index.worker.ts#L152):
   Uses NetworkFirst strategy, which means it will always try to fetch the
-  resource from the network first, and only if that fails it will use the cache.
+  resource from the network first, and only if that fails it will use the cache
 
 ## Cache invalidation limitations
 

package/framework/config.md

@@ -157,6 +157,14 @@ When a user selects a variant, it will switch the values on the configurable pag
 
 Enabling options here will allow switching of those variants.
 
+#### containerSizingContent: BREAKPOINT | FULL_WIDTH = `FULL_WIDTH`
+
+Configures the max width of the content (main content area)
+
+#### containerSizingShell: BREAKPOINT | FULL_WIDTH = `FULL_WIDTH`
+
+Configures the max width of the shell (header, footer, overlays, etc.)
+
 #### crossSellsHideCartItems: boolean = `false`
 
 Determines if cross sell items should be shown when the user already has the product in their cart. This will result in a product will popping off the screen when you add it to the cart.
@@ -223,6 +231,10 @@ Provide a value to enable Google Analytics for your store.
 
 To override the value for a specific locale, configure in i18n config.
 
+#### googlePlaystore: [GraphCommerceGooglePlaystoreConfig](#GraphCommerceGooglePlaystoreConfig)
+
+To create an assetlinks.json file for the Android app.
+
 #### googleRecaptchaKey: string
 
 Google reCAPTCHA site key.
@@ -347,6 +359,10 @@ Show a message when the product is added to the wishlist.
 
 Debug configuration for GraphCommerce
 
+#### cart: boolean
+
+Enable debugging interface to debug sessions
+
 #### pluginStatus: boolean
 
 Reports which plugins are enabled or disabled.
@@ -370,8 +386,22 @@ Issues that this can cause are:
 - The same package is included multiple times in the bundle, increasing the bundle size.
 - The Typescript types of the package are not compatible with each other, causing Typescript errors.
 
+### GraphCommerceGooglePlaystoreConfig
+
+See https://developer.android.com/training/app-links/verify-android-applinks#web-assoc
+
+#### packageName: string (required)
+
+The package name of the Android app.
+
+#### sha256CertificateFingerprint: string (required)
+
+The sha256 certificate fingerprint of the Android app.
+
 ### GraphCommercePermissions
 
+Permissions input
+
 #### cart: CUSTOMER_ONLY | DISABLED | ENABLED
 
 Changes the availability of the add to cart buttons and the cart page to either customer only or completely disables it.
@@ -386,6 +416,8 @@ Enables / disabled the account section of the website. DISABLE_REGISTRATION will
 
 #### website: ENABLED
 
+Allows the option to require login or completely disable the site.
+
 ### GraphCommerceStorefrontConfig
 
 All storefront configuration for the project

package/framework/seo.md

@@ -4,6 +4,30 @@ menu: SEO
 
 # SEO
 
+We optimize for Search engines by default by integrating a few key features:
+
+## Canonical URL
+
+We provde a
+[canonicalize / useCanonical](https://github.com/graphcommerce-org/graphcommerce/blob/canary/packages/next-ui/PageMeta/canonicalize.ts)
+function that can be used to generate canonical URLs based on the current router
+and further configuration. This functionaliy is used by the PageMeta component
+as well as robots.txt and sitemap generation.
+
+It considers the current locale, the domain.
+
+## JsonLd
+
+We integrated [JSON-LD](https://json-ld.org/) for pages.
+
+A
+[`<JsonLd>`](https://github.com/graphcommerce-org/graphcommerce/blob/main/packages/next-ui/JsonLd/JsonLd.tsx)
+component provides Json-LD metadata for your pages. See
+[<ProductPageJsonLd>](https://github.com/graphcommerce-org/graphcommerce/blob/main/packages/magento-product/components/JsonLdProduct/ProductPageJsonLd.tsx)
+or
+[`<BreadcrumbJsonLd>`](https://github.com/graphcommerce-org/graphcommerce/blob/main/packages/next-ui/BreadcrumbJsonLd/BreadcrumbJsonLd.tsx)
+for examples.
+
 ## Page Meta data
 
 Page meta data is handled by the
@@ -13,7 +37,6 @@ are hardcoded).
 
 ```tsx
 // Example from /cart.tsx
-
 <PageMeta
   title={t`Cart (${data?.cart?.total_quantity ?? 0})`}
   metaDescription={t`Cart Items`}
@@ -26,7 +49,6 @@ Dynamic example
 
 ```tsx
 // Example from /product/[url].tsx
-
 <PageMeta
   title={page?.metaTitle ?? title ?? ''}
   metaDescription={page?.metaDescription ?? ''}
@@ -35,7 +57,13 @@ Dynamic example
 />
 ```
 
-## Robots.txt & XML sitemaps
+## Robots.txt
+
+Robots.txt and the sitemap files are generated on the fly and do not rely on any
+static generation.
+
+Robots.txt is generated during runtime so that a separate robots.txt can be
+served for each domain that is configured.
 
 GraphCommerce serves robots.txt & XML sitemap routes through the page router.
 (`pages/robots.txt.tsx` & `pages/sitemap/`)  
@@ -46,7 +74,31 @@ separate sitemap for product, category & content pages.
 ### Multi domain setup
 
 When using a multi domain setup (e.g. https://mydomain.nl &
-https://mydomain.com) using the
+https://mydomain.com) configure the
+[`domain` configuration](./config.md#domain-string) in the storefront config.
+
+```js
+/** @type {import('@graphcommerce/next-config/src/generated/config').GraphCommerceConfig} */
+const config = {
+  // ...
+  storefront: [
+    {
+      locale: 'en',
+      magentoStoreCode: 'en_US',
+      defaultLocale: true,
+      domain: 'https://mydomain.com',
+    },
+    {
+      locale: 'nl',
+      magentoStoreCode: 'nl_NL',
+      defaultLocale: true,
+      domain: 'https://mydomain.nl',
+    },
+    // ...
+  ],
+}
+```
+
 [`canonicalBaseUrl` configuration](./config.md#canonicalbaseurl-string), the
 robots.txt will only include sitemaps specific to that domain.
 
@@ -54,9 +106,20 @@ robots.txt will only include sitemaps specific to that domain.
 
 When using a multi locale based setup (e.g.
 https://graphcommerce.vercel.app/en-gb), the robots.txt will include sitemaps
-for all locales on the global domain. Example:
+for all locales the configured domain. Example:
 [robots.txt](https://graphcommerce.vercel.app/robots.txt)
 
+## Sitemaps
+
+GraphCommerce generates sitemaps per locale for
+[sitemap/product.xml](https://github.com/graphcommerce-org/graphcommerce/blob/canary/examples/magento-graphcms/pages/sitemap/product.xml.tsx),
+[sitemap/category.xml](https://github.com/graphcommerce-org/graphcommerce/blob/canary/examples/magento-graphcms/pages/sitemap/category.xml.tsx)
+and
+[sitemap/content.xml](https://github.com/graphcommerce-org/graphcommerce/blob/canary/examples/magento-graphcms/pages/sitemap/content.xml.tsx).
+
+Limitations: We currently do not support hreflang in sitemaps since there is no
+Magento GraphQL API to get the hreflang for a page.
+
 ## Next steps
 
 - Learn about [Static Generation (SSG)](../framework/static-generation.md) in

package/getting-started/create.md

@@ -8,10 +8,10 @@ metaTitle: Getting started with GraphCommerce
 In this guide, you will set up a GraphCommerce app locally, allowing you to
 start building.
 
-### Requirements
+### Preparations
 
-- Lixux, MacOS or WSL2
-- Install and use node 16/18: `nvm install 16` or `nvm use 16`
+- MacOS, Windows with WSL2 or Linux
+- Install and use node 20: `nvm install 20` or `nvm use 20`
 - Install yarn: `corepack enable`
 
 ## Step 1: Create a GraphCommerce app
@@ -26,19 +26,34 @@ mkdir my-project
 # Create project folder
 ```
 
+There are a few starting points to choose from with or without Hygraph:
+
+Option 1: Only Magento Open Source:
+
 ```bash
-cp -R graphcommerce/examples/magento-graphcms/. my-project && rm -rf graphcommerce && cd my-project
-# Copy example, delete repo, navigate to project folder
+cp -R graphcommerce/examples/magento-magento-open-source/. my-project && cd my-project
 ```
 
+Option 2: Magento Open Source + Hygraph:
+
+```bash
+cp -R graphcommerce/examples/magento-graphcms/. my-project && cd my-project
+```
+
+Option 3: Adobe Commerce:
+
+Please contact us for more information to get access to the Adobe Commerce
+starting point.
+
 ## Step 2: Configure API keys (optional)
 
 Duplicate and rename the configuration example file to:
 `graphcommerce.config.js` and configure the following:
 
-- `magentoEndpoint` [?](../framework/config.md#magentoendpoint-string)
-- `hygraphEndpoint` [?](../framework/config.md#hygraphendpoint-string)
-- `magentoStoreCode` [?](../framework/config.md#magentostorecode-string)
+- `magentoEndpoint` [?](../framework/config.md#magentoendpoint-string-required)
+- `hygraphEndpoint` [?](../framework/config.md#hygraphendpoint-string-required)
+- `magentoStoreCode`
+  [?](../framework/config.md#magentostorecode-string-required)
 
 > magentoStoreCode
 >
@@ -55,11 +70,12 @@ Duplicate and rename the configuration example file to:
 
 ### Requirements
 
-- Magento version 2.4.3 or higher - Clean install, a production or a development
-  environment
+- Magento version 2.4.5 or higher - Clean install, a production or a development
+  environment (technically 2.4.3 and 2.4.4 also work, but in practice important
+  bugfixes have been made in the latest versions.)
 - Hygraph - A project with the required schema.
   [Clone ↗](https://app.hygraph.com/clone/caddaa93cfa9436a9e76ae9c0f34d257?name=GraphCommerce%20Demo)
-  the schema as your starting point.
+  the schema as your starwting point.
 
 ## Step 3: Start the app
 

package/getting-started/graphcms-component.md

@@ -182,7 +182,7 @@ fragment RowRenderer on Page @inject(into: ["HygraphPage"]) {
 - Add a new file, /components/GraphCMS/Banner/index.tsx:
 
 ```tsx
-import { RichText } from '@graphcommerce/graphcms-ui'
+import { RichText } from '@graphcommerce/hygraph-ui'
 import { BannerFragment } from './Banner.gql'
 
 export function Banner(props: BannerFragment) {

package/getting-started/improving-core-web-vitals.md

@@ -0,0 +1,355 @@
+# Improving Core Web Vitals
+
+GraphCommerce has a strict focus on getting great scores on Google's Core Web
+Vitals. This document outlines the steps we take to ensure that our frontend is
+performant.
+
+- LCP: Good: <=2.5s Needs Improvement: <=4s Bad: >4s
+- CLS: Good: <=0.1 Needs improvement: <=0.25 Bad: >0.25
+- INP: Good: <=200ms Needs improvement: <=500ms Bad: >500ms
+
+To get a good LCP and CLS there are a few things we need to do.
+
+## Rendering phases of GraphCommerce pages
+
+Rendering of the page is done in three main phases.
+
+Rule of thumb: Move as much work up the phases as possible.
+
+### Phase one: HTML/CSS and images.
+
+The HTML document containing all the HTML and CSS is downloaded and rendered on
+the frontend. Optimizing for this phase is usually where to start.
+
+The goal is that the page should look great in this phase on mobile and desktop.
+
+Of course not everything can be achieved with only HTML/CSS/Images. Customer
+specific information is not present in this phase, the server only sends
+session-less information to the browser. So any session specific information
+will be missing here.
+
+Solution: Disable JavaScript in the Chrome inspector and reload the page.
+
+Rule of thumb: Most of the attention should be put on getting as much of the
+page rendered as possible in this phase.
+
+#### Images are loaded too late
+
+Make sure the images that are required for this phase have the `loading=eager`
+property.
+
+### Phase two: React hydration
+
+Hydration is the process is to "attach" React to the HTML that was rendered by
+the server. React will attach to the HTML that exists inside the DOM and take
+over managing the DOM inside it. Next.js automatically does this for the root
+component.
+
+#### Pitfall: Hydration errors
+
+Hydration errors are problematic for performance as this will cause React to
+rerender the entire page. This means that after hydration is complete, React
+will start to rerender the entire page. This will thus double the amount of work
+React has to do.
+
+See Pitfall in in this chapter:
+https://react.dev/reference/react-dom/client/hydrateRoot#hydrating-server-rendered-html
+
+Solution: Keep an eye on the console for hydration errors and fix them.
+
+#### Pitfall: Long hydration phase
+
+Keep the hydration phase as short as possible. Web Vitals does not measure the
+execution time directly but there is a case where this happens:
+
+When React starts hydration it will start to listen to all event listeners. So
+even before hydration is complete the clicks of the user will be registered and
+will be replayed when hydration is complete. This also means that the whole
+hydration phase will count against the INP metric.
+
+The longer the hydration phase, the more often it will be measured as the INP
+metric. The more negatively it will affect the Core Web Vitals and user
+experience.
+
+Solution: Use the React Profiler to see where work is being done and optimize
+that.
+
+### Phase three: Apollo Client queries
+
+To load session specific data, Apollo Client is used. After the first render is
+complete, the Apollo Client data becomes available.
+
+Most frequently used queries are automatically persisted (cached) in the local
+storage of the browser (key: `apollo-cache-persist`). By default everything is
+persisted, except for pruned data (see
+[persistenceMapper](https://github.com/graphcommerce-org/graphcommerce/blob/3900c7c9e3741fe110378f1a03dd54b4db8b26d9/packages/graphql/components/GraphQLProvider/persistenceMapper.ts#L28-L37)).
+
+#### Pitfall: Non-session specific queries are used for the initial render
+
+Since this phase is late, do not use the result of non-session specific queries
+for the initial render. This also causes rerenders of the components causing all
+vitals to be affected.
+
+Solution: Move data fetching to the `getStaticProps` or `getServerSideProps`
+functions. That can be a bit unergonomic, in that case move the data fetching
+requirements to the GraphQL Mesh layer, by creating additional resolvers.
+
+For example, it has been complex to get attribute option value labels like the
+brand of a product without doing an additional `customAttributeMetadataV2`
+query. Fetching this information separately requires precise coordination to
+make it work even in getStaticProps.
+
+To solve this the query fetching the attribute option values has been moved to
+the GraphQL Mesh layer with the
+[`ProductInterface.custom_attributeV2`](https://github.com/graphcommerce-org/graphcommerce/blob/canary/packages/magento-graphql/schema/ProductInterface-custom_attribute.graphqls)
+and it's
+[resolver](https://github.com/graphcommerce-org/graphcommerce/blob/canary/packages/magento-graphql/mesh/customAttributeV2Resolver.ts)
+and
+[mesh configuration plugin](https://github.com/graphcommerce-org/graphcommerce/blob/canary/packages/magento-graphql/plugins/meshConfigAttrValue.ts).
+
+## Prevent components outside of the viewport from unnecessarily hydrating
+
+To keep the Hydration phase as short as possible, it's a good idea to postpone
+the hydration of (heavy) components that are outside of the viewport until they
+are needed. By using `<LazyHydrate>`, the component can be hydrated either
+manually, by setting the `hydrated` prop to true or automatically by the
+IntersectionObserver inside `<LazyHydrate>` (as soon as the component comes into
+view). It is recommended to set an estimated height value on the `height` prop.
+This will reserver space for the component, when the page is loaded clientside.
+This is to prevent multiple `LazyHydrate` components below each other from
+intersecting all at once (as they do not have any HTML, and thus any height,
+when loaded clientside). This height does not need to be exact.
+
+The IntersectionObserver method of hydrating should never be used for components
+that are inside the viewport on pageload, as it requires JS and is asynchronous.
+When items are rendered in a loop and the first few items are inside the
+viewport, these should be set to `hydrated={true}` based on the index of the
+loop.
+
+Example 1:
+
+```tsx
+import { LazyHydrate } from '@graphcommerce/next-ui'
+
+function MyLayout() {
+  return (
+    <MyComponentAboveTheFold>
+      Immediately hydrated
+    </MyComponentAboveTheFold>
+
+    <LazyHydrate hydrated={true}>
+      <MyComponentAboveTheFold>
+        Immediately hydrated
+      </MyComponentAboveTheFold>
+    </<LazyHydrate>
+
+    <LazyHydrate height={500}>
+      <MyExpensiveComponentBelowTheFold>
+        Only hydrated when scrolled into view
+      </MyExpensiveComponentBelowTheFold>
+    </LazyHydrate>
+  )
+}
+```
+
+Example 2:
+
+```tsx
+export function MyItems(props) {
+  const { items, loadingEager = 2 } = props
+
+  return (
+    <>
+      {items.map((item, index) => (
+        // The first two items are hydrated immediately. Any items after that are hydrated on intersection
+        <LazyHydrate
+          key={item.id}
+          hydrated={index < loadingEager ? true : undefined}
+          height={500}
+        >
+          <MyComponent {...item} />
+        </LazyHydrate>
+      ))}
+    </>
+  )
+}
+```
+
+## Conditionally render on mobile/desktop
+
+TLDR: Use the `<MediaQuery>` component instead of useMediaQuery or CSS
+breakpoints.
+
+To render UI conditionally for various breakpoints it is practically always
+faster to render them conditionally with CSS than it is to conditionallty render
+components with JS. However rendering conditionally with CSS will cause
+increased JS executing time, Total Blocking Time and possibly INP issues.
+
+### Conditionally render with JS: useMediaQuery
+
+useMediaQuery: When you are now using useMediaQuery to conditionally render
+content for mobile or desktop.
+
+This means that hooks like useMediaQuery should almost never be used.
+[See docs](https://mui.com/material-ui/react-use-media-query/#server-side-rendering)
+and [examples](https://mui.com/system/display/#hiding-elements).
+
+> Server-side rendering and client-side media queries are fundamentally at odds.
+> Be aware of the tradeoff.
+
+Also see
+https://mui.com/material-ui/react-use-media-query/#server-side-rendering
+
+1.  Is very slow as it has to wait for the JS to initialize on pageload.
+2.  Can cause CLS problems if the useMediaQuery is used to render elements in
+    the viewport.
+3.  Can cause LCP issues if useMediaQuery is used to render the LCP element.
+4.  Causes TBT problems as a component always needs to be rerendered. (And bad
+    TBT can cause INP problems)
+5.  HTML isn't present in the DOM, which can cause SEO issues.
+
+### Conditionally render with CSS: CSS Media query
+
+When you are using CSS to show or hide content based on media queries. Causes
+TBT problems as both code paths need to be rendered. Bad TBT can cause INP
+problems.
+
+```tsx
+function RenderConditionallyForCertainBreakpoints() {
+  return (
+    <>
+      <Box sx={{ display: { xs: 'block', md: 'none' } }}>
+        hide on screens wider than md
+      </Box>
+      <Box sx={{ display: { xs: 'none', md: 'block' } }}>
+        hide on screens smaller than md
+      </Box>
+    </>
+  )
+}
+```
+
+### MediaQuery component
+
+To solve both of the above problems we can use the `<MediaQuery>` component. It
+will conditionally render/hydrate the component based on the media query and not
+execute the JS if the media query does not match.
+
+1. On the server both code paths are rendered as normal, like you would with the
+   conditional render with CSS. On the first browser render (where JS is loaded)
+   it will conditionally show the component based on the CSS media query.
+2. During hydration the component will be hydrated only if the media query
+   matches. If the media query doesn't match it will not be hydrated (and thus
+   not execute  
+   the JS).
+3. When the media query matches the component will rerender and show the
+   component.
+4. When components are created on the client, they are conditionally rendered.
+
+Example:
+
+```tsx
+import { MediaQuery } from '@graphcommerce/next-ui'
+
+function MyLayout() {
+  return (
+    <MediaQuery query={(theme) => theme.breakpoints.up('md')}>
+      <MyExpensiveDesktopComponent>
+        Only visisble on desktop
+      </MyExpensiveDesktopComponent>
+    </MediaQuery>
+  )
+}
+```
+
+## Use Context + useState cautiously
+
+Contexts + useState should be used cautiously. When the state updates, it causes
+ALL components within the context provider to rerender, not just the components
+that use the context. When wrapping a lot of components inside a context, this
+can become very expensive.
+
+Solution for state that involves query data: Use Apollo Client cache, by using
+`useQuery` for data that is already fetched on the server and cached by Apollo.
+
+Solution for local state: use
+[Apollo Reactive variables](https://www.apollographql.com/docs/react/local-state/reactive-variables)
+
+## Image resizing
+
+When using the Image component, the sizes prop should be set correctly so no
+unnecessarily large images are served. The prop accepts either a string (vw, px,
+calc(), etc) or an object with breakpoints and a string value. See the
+[prop type](https://github.com/graphcommerce-org/graphcommerce/blob/canary/packages/image/components/Image.tsx#L176-L185)
+for all available options.
+
+Example:
+
+```tsx
+<Image
+  layout='fill'
+  alt={item.label}
+  src={item.url}
+  sizes={{
+    0: '100vw',
+    [theme.breakpoints.values.md]: '50vw',
+  }}
+/>
+```
+
+## Preventing a query waterfall
+
+When querying inside `getStaticProps`, only use `await` when the data is
+required for something else inside `getStaticProps`. Otherwise it should be
+awaited in the return statement. When a query is awaited immediately, it halts
+the code at that point until that query completes. Meaning any queries called
+after that will be called in serial. Awaiting all queries in the return
+statement allows the queries to be called in parallel.
+
+Example:
+
+```tsx
+// Bad, because each query needs to wait until the previous one is completed entirely before being fired
+export const getStaticProps: GetPageStaticProps = async (context) => {
+  // Query takes 100ms - code is halted until it finishes
+  const {data: queryOne} = await staticClient.query({ query: queryOneDocument })
+  // Query takes 100ms - code is halted until it finishes
+  const {data: queryTwo} = await staticClient.query({ query: queryTwoDocument })
+  // Query takes 100ms - code is halted until it finishes
+  const {data: queryThree} = await staticClient.query({ query: queryThreeDocument })
+
+
+  return {
+    props: {
+      ...queryOne
+      ...queryTwo
+      ...queryThree
+      // Total wait time 300ms
+    },
+  }
+}
+```
+
+```tsx
+// Good, because each query is fired in parallel and only awaited when each query is already running in the background
+export const getStaticProps: GetPageStaticProps = async (context) => {
+  // Query takes 100ms - but it runs in the background, code continues execution
+  const queryOne = staticClient.query({ query: queryOneDocument })
+  // Query takes 100ms - but it runs in the background, code continues execution
+  const queryTwo = staticClient.query({ query: queryTwoDocument })
+  // Query takes 100ms - but it runs in the background, code continues execution
+  const queryThree = staticClient.query({ query: queryThreeDocument })
+
+  return {
+    props: {
+      // Awaits query (100ms)
+      ...(await queryOne).data
+      // Awaits query, already finished in the background (0ms)
+      ...(await queryTwo).data
+      // Awaits query, already finished in the background (0ms)
+      ...(await queryThree).data
+      // Total wait time 100ms
+    },
+  }
+}
+```

package/getting-started/pages.md

@@ -152,7 +152,7 @@ import { PageOptions } from '@graphcommerce/framer-next-pages'
 import {
   hygraphPageContent,
   HygraphPagesQuery,
-} from '@graphcommerce/graphcms-ui'
+} from '@graphcommerce/hygraph-ui'
 import { StoreConfigDocument } from '@graphcommerce/magento-store'
 import {
   GetStaticProps,

package/getting-started/readme.md

@@ -61,8 +61,8 @@ https://user-images.githubusercontent.com/1251986/227236765-503ccaac-6499-48df-b
 ## Page routing
 
 GraphCommerce uses Next.js file-based
-[page routing ↗](https://nextjs.org/docs/routing/introduction). The files inside
-the `📁 /pages` directory handle routing. Modify these files to meet your
+[page routing ↗](https://nextjs.org/docs/routing/introduction). The files
+inside the `📁 /pages` directory handle routing. Modify these files to meet your
 requirements or [build a custom page](./pages.md).
 
 - Product pages: `📄 /p/[...url].tsx`