PageDataResolver

pageDataResolver is designed to handle API calls required on every route change of the application. This function is executed by the theme engine and it gets the themeId, router and the fpi instance as arguments - and performs asynchronous calls to fetch essential data. The function calling is managed by the Theme Engine; theme developers just need to define the function.

Example

//helper/lib

export async function pageDataResolver({ fpi, router, themeId }) {
    const state = fpi.store.getState();
    const pageValue = getPageSlug(router);
    const APIs = [  ]
    const currentPageInStore = state?.theme?.page?.value ?? null;
    
    if ( pageValue && pageValue !== currentPageInStore ) {
        APIs.push(
            fpi.theme.fetchPage({
                pageValue,
                themeId,
            }).then(console.log)
        )
    }
    return Promise.all(APIs).catch(console.log);
}

// Export it from index.jsx file

import { pageDataResolver } from "./helper/lib";

 return {
    pageDataResolver
    
    //other keys....
 }

Full argument reference

The example above destructures three keys, but the theme engine passes more. During server-side rendering the engine calls pageDataResolver with one object:

Key	Type	Contents
fpi	object	The Fynd Platform Interface instance
themeId	string	The identifier of the applied theme
router	object	The matched route, plus filterQuery
cookies	object	themeCookie, userGroups, userAppLocationDetails, userStatus, and any extra cookies the platform is configured to forward
headers	object	userData, userAgent, userStatus, storeData, userGroups, experimentalFeatures, and any extra headers the platform is configured to forward
query	object	isEdit, previewId, navigationPreviewId

pageDataResolver receives router, and globalDataResolver does not. globalDataResolver receives applicationID, and pageDataResolver does not.

Read Request Context for what each value means, which outbound header carries it, and how to forward it to the theme APIs.

The client call is smaller

The engine calls pageDataResolver again on every client-side route change, but with fewer keys than the server sends:

Key	Server	Browser
fpi, themeId, router	yes	yes
cookies.userGroups, cookies.userAppLocationDetails	yes	yes
cookies.themeCookie, cookies.userStatus	yes	no
headers.userData, headers.userAgent, headers.storeData	yes	yes
headers.userStatus, headers.userGroups, headers.experimentalFeatures	yes	no
query.isEdit, query.previewId	yes	yes
query.navigationPreviewId	yes	no

This is the reason to store context in the FPI custom state during server-side rendering. A value that the browser call does not receive is only available if the server saved it first:

if (userStatus) {
  fpi.custom.setValue("userStatus", userStatus); // Server run
} else {
  const saved = fpi.store.getState()?.custom?.userStatus; // Later browser runs
}

Returning cookies

pageDataResolver may return a cookies array. During server-side rendering the engine collects the arrays from both resolvers and sets them on the response. A return value is optional.