Pwa-studio: [feature]: Proposal Refactoring for store configuration load

[larsroettig]

With the current design of loading store configuration, in some cases, we are forced to have dependency between
loading store configuration and loading product data. With the proposal, I will give a short overview of which configuration we should load from Magento Backend. Also, how we can refactor the current state.

Current State

Currently, we only consider the Magento store configuration for the footer component https://github.com/magento/pwa-studio/blob/5542122475b834cd0ae07ee7ccda2aeb4d65d57e/packages/venia-ui/lib/components/Footer/footer.js#L7

Shop owners can change many settings by default in Magento 2, and this helped Magento to grow so fast. From my point of view, we should be taking store configuration into account to change our behaviour in PWA Studio. We already have Tickets in our backlog that are required to loading store configuration see #1940.
For that reason, it is now a good time to think about what are requirements and how we can implement this.

Currently Supported by PWA Studio

• Copyright
• Media URL

A good MVP for store configuration load

• Storename
• Root Category ID
• Count products per page
• Locale options
• Base Currency
• Display Currency
• Weight Unit
• Language

My requirements to a good store configuration load

If I think about how often as the customer will change the store name, Copywrite, etc. then we understand this should not so often happen.

• Central where point we load configuration
• Extensible with own configuration
• Cachable
• Fast
• No query dependency

Proposal of refactoring

1. Load Store Configuration on build time

Currently, we already load only the secure media URL on build time. Loading Store Configuration on build helps
we don't need to think about cache. On every build, we
load the data from Magento.

Advantage

• No to thing about cache easy to implement
• Central on the build we can generate a react config provider (env-specific) that helps us with store config
• Extensible at the build

Disadvantages

• Nees a redeploy the PWA to see store config changes
• Load on the build will ingress the build time
• Not scalable for a multi-store setup

Implementation Detail

Methode that provides the config:
The method getMediaURLneed to be refactored to getStoreConfig()

https://github.com/magento/pwa-studio/blob/develop/packages/pwa-buildpack/lib/Utilities/graphQL.js#L35-L39

Build Config:
https://github.com/magento/pwa-studio/blob/develop/packages/venia-concept/webpack.config.js#L9

GraphQL Query:
https://github.com/magento/pwa-studio/blob/develop/packages/pwa-buildpack/lib/queries/getStoreMediaUrl.graphql

2. Load Store Configuration as the first request

Advantage

• No, redeploy the PWA to see store config changes
• Scalable for a multi-store setup we know about the scope
• Extensible if we a have central config provider

Disadvantages:

• Need to implement a cache logic
• Ingress may be time for the first request
• Category Query need to wait for Store Configuration is loaded

[fooman]

Any chance of something like

Load store config at build time and seed it into the service worker. If it gets updated in the admin the service worker somehow (insert unknown to me wizardry here) is able to invalidate the config and retrieves the latest version?

[shochdoerfer]

@fooman the service worker could inspect the HTTP headers sent from the server. Once a certain header is set, reload the store config from the endpoint and cache it again. The Magento API would need to set that header only when the store config was changed.

[niklaswolf]

I also think the service worker will be key here. I'm not quite sure which headers are supported right now by the graphql endpoints, but it also would be great for other usecases to have the basic headers supported that workbox is taking into account: https://developers.google.com/web/tools/workbox/modules/workbox-broadcast-update#how_are_updates_determined

[fooman]

These issues sound related
https://github.com/magento/pwa-studio/issues/1617
https://github.com/magento/pwa-studio/issues/1669

[Jordaneisenburger]

In our current project that's in development we load storeconfig once and save it in context so we can reuse it everywhere. We are going with the pollInterval option on useQuery so we don't have to do any redeploying.

We've made a hook called useStoreConfig() and a context that looks like

export const StoreConfigProvider = ({
    children,
    additionalConfig = {},
    query = getStoreConfig,
}) => {
    const { error, data } = useQuery(query);

    if (error) {
        console.error('Could not load store config', error);
    }

    return (
        <StoreConfig.Provider
            value={merge({}, defaultConfig, additionalConfig, data)}
        >
            {children}
        </StoreConfig.Provider>
    );
};

This gives us the opportunity to extend our base Storefront config easily for custom projects

[larsroettig]

@Jordaneisenburger how you handlequery dependency? StoreConfigProvider should be loaded as the first thing? Also, I think this should be supported by PWA Studio out of the box. For those reasons, I was writing this :smile_cat:

[Jordaneisenburger]

Yeah you can do something like this in your src/index.js i think something like this is what pwa studio could also provide out of the box indeed.

           <StoreConfigProvider
                query={storeConfig}
                additionalConfig={{
                    feedbackCompanySummary: {
                        link: '',
                        name: '',
                        score: '',
                        score_max: '',
                        total_reviews: '',
                    },
                    deliveryTimeLabel: {
                        label: '',
                    },
                }}
            >

[revanth0212]

Nice details @larsroettig

At the initial looks of it, StaleWhileRevalidate strategy in the SW for the store config will address the issue at hand.

We can couple this along with bundle time fetch as well if needed.