Upgrade JSS 22.0.0 Next.js apps to version 22.1
This topic covers most of the changes you must make to your existing JSS 22.0.0 applications to take advantage of the new features in version 22.1, including metadata-based editing for Pages. However, because of the nature of JavaScript and Next.js application development, this topic doesn't account for all the customization you might have in your existing application.
The new metadata-based editing architecture provides improved page speeds when visually editing in Pages. It's also significantly easier to configure and maintain than the older, chromes-based architecture. As such, we strongly recommend updating all your apps to use metadata editing mode. The metadata mode is enabled by default for all new apps created from the JSS 22.1 starter kit.
While upgrading, consider the JSS templates and add-ons you used when creating your Next.js application. You can find them in your package.json file. For example, a JSS 22.0.0 application included in the XM Cloud starter foundation uses the following templates and add-ons:
Some code examples, images, and UI labels may still use XM Cloud while engineering assets are being updated.
-
nextjs -
nextjs-xmcloud -
nextjs-sxa -
nextjs-multisite
-
If you haven't already done so, upgrade your app to JSS 22.0.0.
-
Familiarize yourself with the changelog. If your application is heavily customized, the changelog can provide guidance on what additional changes you need that are not covered in this topic.
This topic describes how to:
Update application dependencies in your existing app
For your upgraded application to work correctly, you will need to update dependencies.
To update your dependencies:
-
In your existing application's
package.jsonfile:-
Update every
@sitecore-jsspackage to version~22.1. -
Update the
@sitecore-cloudsdk/eventspackage to version^0.3.1. -
Update the
@types/nodepackage to version^20.14.2.
-
-
Install the dependencies with the following command:
RequestResponsenpm install -
We highly recommend you install version
0.32.6of thesharpimage processing library using the following command. This is to improve memory usage of the image optimization feature:RequestResponsenpm i [email protected]
Create a JSS 22.1 Next.js application
To simplify the upgrade process as much as possible, create a JSS 22.1 Next.js application with the XM Cloud add-on. You can then copy some files from this app into your existing app.
To create a JSS 22.1 Next.js application with the XM Cloud add-on included:
-
In a console, run the following command:
RequestResponsenpx [email protected] nextjs -
If prompted to install the
[email protected]package, answer y. -
Enter the folder path for the JSS 22.1 Next.js app. For example, enter
./jss221, to create the app folder in your current working directory. -
Follow the remaining prompts, selecting the same options for data fetching (
GraphQLorREST) and prerendering (SSGorSSR) as in your existing application. -
When asked if you are building for Sitecore XM Cloud, answer y to install the XM Cloud add-on.
-
Select other add-ons used by your existing application and press Enter.
The script then installs the application dependencies.
Some code examples, images, and UI labels may still use XM Cloud while engineering assets are being updated.
Update the Next.js template files in your existing app
This explains how to synchronize files in your existing application with corresponding files from your new JSS 22.1 app.
To update the Next.js template files:
-
If you have not customized the
scripts/generate-config.tsfile, replace it with the 22.1 version. Otherwise, modify your file as follows:-
In the
configTextprop assignment, add atrimmethod call afterconfig[prop]?, such as:RequestResponseconfig[prop]?.trim() -
At the end of that assignment, replace the comma before the newline character with a semicolon:
RequestResponse// Before }',\n`; // After }';\n`;
Here's an example of the updated assignment suitable for JSS 22.1:
RequestResponseconfigText += `config.${prop} = process.env.${constantCase(prop)} || '${config[prop]?.trim()}';\n`; -
-
If you have not customized the
lib/next-config/plugins/cors-headerplugin, replace it with the 22.1 version. Otherwise, modify your file as follows:-
Because cross-origin resource sharing (CORS) is now handled by API handlers or middleware, remove the following CORS header for API endpoints:
RequestResponse{ source: '/api/:path*', headers: [ { key: 'Access-Control-Allow-Origin', value: config.sitecoreApiHost.replace(/\/$/, ''), }, ], },
-
-
Because
ComponentConsumerPropshas been removed, if you have anyimportstatements that reference it, update them all to useWithSitecoreContextPropsinstead. -
Because the
resolvePageUrlfunction now accepts an object, and becauseserverUrlis now optional, the latter is omitted if the metadata edit mode for Pages is enabled. If you've customized thepages/api/editing/render.tsfile and you currently pass theresolvePageUrlfunction intoEditingRenderMiddleware, modify your file as follows:-
Replace the existing handler initialization with the following:
RequestResponseconst handler = new EditingRenderMiddleware({ resolvePageUrl: ({ serverUrl, itemPath }) => `${serverUrl}${itemPath}`, }).getHandler();
NoteIf you haven't customized
pages/api/editing/render.ts, you don't need to make any new changes to it for this release. -
-
If your app contains any references to the now-deprecated
EditingComponentPlaceholderor theRenderingTypeenum, such as the following example in[[...path]].tsx, delete them:RequestResponseimport Layout from 'src/Layout'; import { RenderingType, EditingComponentPlaceholder } from '@sitecore-jss/sitecore-jss-nextjs'; ... const isComponentRendering = layoutData.sitecore.context.renderingType === RenderingType.Component; ... {isComponentRendering ? ( <EditingComponentPlaceholder rendering={layoutData.sitecore.route} /> ) : ( <Layout layoutData={layoutData} headLinks={headLinks} /> )} -
If you use the
next/imagecomponent (instead of built-in JSS components such asImage,Banner, and so on) to render Sitecore images, we recommend you configure it to conditionally disable Next.js image optimization in edit and preview modes.NoteThis process is not necessary when using
next/imageto load static images or images from external sources.The following example describes one way you can implement conditional optimization, involving fetching the page state and using it to dynamically initialize a prop named
unoptimized:-
In your custom code (such as a custom component), add a new
importstatement together with two new definitions, as follows:RequestResponseimport { useSitecoreContext } from '@sitecore-jss/sitecore-jss-nextjs'; ... const { sitecoreContext } = useSitecoreContext(); const unoptimized = sitecoreContext.pageState !== LayoutServicePageState.Normal; -
In your
next/imagecomponent, add the following rendering that includes the newly-definedunoptimizedprop:RequestResponse<Image {...props} unoptimized={unoptimized}/>
NoteBuilt-in JSS components use conditional image optimization by default.
-
Update the XM Cloud add-on
To update the XM Cloud add-on:
Some code examples, images, and UI labels may still use XM Cloud while engineering assets are being updated.
-
If you have not customized the
/src/Scripts.tsxfile, replace it with the 22.1 version. Otherwise, modify it as follows:-
Add the following
importstatement:RequestResponseimport { EditingScripts } from '@sitecore-jss/sitecore-jss-nextjs'; -
Add an
EditingScriptscomponent:RequestResponse<EditingScripts />
Here's an example of the updated file suitable for JSS 22.1:
RequestResponseimport { EditingScripts } from '@sitecore-jss/sitecore-jss-nextjs'; const Scripts = (): JSX.Element | null => ( <> <EditingScripts /> ... </> ); -
-
If you have not customized the
/src/lib/dictionary-service-factory.tsfile, replace it with the 22.1 version. Otherwise, modify it as follows:-
Add the
useSiteQueryparameter to theGraphQLDictionaryServiceinitialization:RequestResponseuseSiteQuery: true,
Here's an example of the updated initialization suitable for JSS 22.1:
RequestResponsenew GraphQLDictionaryService({ siteName, clientFactory, ... useSiteQuery: true, }) -
-
If you have not customized the
/lib/page-props-factory/plugins/personalize.tsfile, replace it with the 22.1 version. Otherwise, modify it as follows:-
Update the
personalizeLayoutfunction call to passpersonalizeData.componentVariantIdsas a parameter, such as:RequestResponse// Get variant(s) for personalization (from path) const personalizeData = getPersonalizedRewriteData(path); // Modify layoutData to use specific variant(s) instead of default // This will also set the variantId on the Sitecore context so that it is accessible here personalizeLayout( props.layoutData, personalizeData.variantId, personalizeData.componentVariantIds );
-
-
If you have not customized the
/lib/page-props-factory/plugins/preview-mode.tsfile, replace it with the 22.1 version. Otherwise, modify it as follows:-
Prepare
personalizeData.componentVariantIdsand add it as a parameter of thepersonalizeLayoutfunction call, such as:RequestResponseimport { SiteInfo, personalizeLayout, getGroomedVariantIds, } from '@sitecore-jss/sitecore-jss-nextjs'; ... props.headLinks = []; const personalizeData = getGroomedVariantIds(variantIds); personalizeLayout( props.layoutData, personalizeData.variantId, personalizeData.componentVariantIds );
-
-
If you have not customized the
lib/middleware/plugins/personalize.tsfile, replace it with the 22.1 version. Otherwise, modify it as follows:-
In the
personalizeMiddlewareconstructor signature, locate the following line withinedgeConfigif present:RequestResponsescope: process.env.NEXT_PUBLIC_PERSONALIZE_SCOPE, -
If it is present, move that line to the root of the constructor signature, outside of
edgeConfig.
Here's an example of the updated constructor signature suitable for JSS 22.1:
RequestResponsethis.personalizeMiddleware = new PersonalizeMiddleware({ ... edgeConfig: { ... }, scope: process.env.NEXT_PUBLIC_PERSONALIZE_SCOPE, });ImportantKeeping this
scopewithinedgeConfigwill continue to work for now, but this approach is deprecated and will no longer be supported after the next major release of JSS. -
-
(Optional) Specify the edit mode used for Pages. If not specified, this is set to
EditMode.Metadataby default.ImportantWith the introduction of editing metadata architecture for Pages, JSS now uses metadata for editing as standard. We strongly recommend you use this new method to take advantage of faster page speeds and simpler configuration. If, however, you want to continue using the older, chromes-based editing architecture for now, you can manually apply this setting.
To specify the edit mode, make the following changes to your
\src\pages\api\editing\config.tsfile:-
Add the following
importstatement:RequestResponseimport { EditMode } from '@sitecore-jss/sitecore-jss-nextjs'; -
In the
handlerdefinition, add one of the following property assignments based on your preferred editing method:RequestResponse// Use only one of the following pagesEditMode: EditMode.Metadata, // Newer, recommended method (default) pagesEditMode: EditMode.Chromes, // Older method
Here's an example of the updated definition specifically using metadata, suitable for JSS 22.1:
RequestResponseconst handler = new EditingConfigMiddleware({ ... pagesEditMode: EditMode.Metadata, }).getHandler();ImportantIf you've decided to use the new metadata architecture, you will also need to follow the rest of the steps in this section; otherwise, you can skip those steps and proceed to update the SXA add-on.
-
-
Copy the
lib/graphql-editing-service.tsfile from your new 22.1 app into your existing app. -
If you have not customized the
lib/page-props-factory/plugins/preview-mode.tsfile, replace it with the 22.1 version. Otherwise, modify it as follows:-
Ensure your file imports all of the following classes and functions required for metadata editing integration:
RequestResponseimport { SiteInfo, personalizeLayout, getGroomedVariantIds, } from '@sitecore-jss/sitecore-jss-nextjs'; import { editingDataService, isEditingMetadataPreviewData, } from '@sitecore-jss/sitecore-jss-nextjs/editing'; import { graphQLEditingService } from 'lib/graphql-editing-service'; ... -
In the
PreviewModePluginclass declaration, locate the existingdataassignment, such as:RequestResponseconst data = await editingDataService.getEditingData(context.previewData); -
Immediately before that assignment, add the following new condition for processing editing page props in metadata mode:
RequestResponse... // If we're in Pages preview (editing) Metadata Edit mode, prefetch the editing data if (isEditingMetadataPreviewData(context.previewData)) { const { site, itemId, language, version, variantIds } = context.previewData; const data = await graphQLEditingService.fetchEditingData({ siteName: site, itemId, language, version, }); if (!data) { throw new Error( `Unable to fetch editing data for preview ${JSON.stringify(context.previewData)}` ); } props.site = data.layoutData.sitecore.context.site as SiteInfo; props.locale = context.previewData.language; props.layoutData = data.layoutData; props.dictionary = data.dictionary; props.headLinks = []; const personalizeData = getGroomedVariantIds(variantIds); personalizeLayout( props.layoutData, personalizeData.variantId, personalizeData.componentVariantIds ); return props; } ... -
We recommend you update the code comment in front of the older assignment statement to differentiate it from the new addition, such as:
RequestResponse// If we're in preview (editing) Chromes Edit mode, use data already sent along with the editing request // This mode is used by the Experience Editor. // In Pages it's treated as a legacy mode but is still supported for backward compatibility. const data = await editingDataService.getEditingData(context.previewData); ...
-
-
For metadata-based editing in Pages, the
field.editableproperty has been superseded byfield.metadata. If you have any custom field components that refer tofield.editable, you need to rework your custom code to replace those references.NoteExperience Editor and chromes-based editing still relies on
field.editable.
Update the SXA add-on
To upgrade the SXA add-on:
-
Replace the following files with the new versions from your 22.1 app:
-
src/components/Image.tsx -
src/components/Promo.tsx -
src/components/Title.tsx -
src/assets/sass/components/title/_component-title.scss
-
Replace the import path for editing utilities
We're moving all editing utilities currently located at @sitecore-jss/sitecore-jss/utils, so if you currently refer to this path in any of your import statements you will need to update them to use the new path @sitecore-jss/sitecore-jss/editing instead.
This change affects the following utilities:
-
ChromeCommand -
DefaultEditFrameButton -
DefaultEditFrameButtonIds -
DefaultEditFrameButtons -
EditButtonTypes -
EditFrameDataSource -
ExperienceEditor -
FieldEditButton -
handleEditorAnchors -
HorizonEditor -
isEditorActive -
mapButtonToCommand -
Metadata -
resetEditorChromes -
WebEditButton
The older path will only continue to work until the next release of JSS. Therefore, we strongly recommend you make the necessary changes as soon as possible.
Next steps
To finalize the upgrade process, make sure you resolve any errors and warnings you encounter. Enable debug logging for JSS specific issues to assist you if necessary.
Certain header configurations can prevent metadata integration from working. To avoid this issue, make sure your response headers allow the Pages domain to load responses inside an iframe.