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:
-
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.json
file:-
Update every
@sitecore-jss
package to version~22.1
. -
Update the
@sitecore-cloudsdk/events
package to version^0.3.1
. -
Update the
@types/node
package to version^20.14.2
.
-
-
Install the dependencies with the following command:
RequestResponsenpm install
-
We highly recommend you install version
0.32.6
of thesharp
image 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 (
GraphQL
orREST
) and prerendering (SSG
orSSR
) 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.
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.ts
file, replace it with the 22.1 version. Otherwise, modify your file as follows:-
In the
configText
prop assignment, add atrim
method 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-header
plugin, 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
ComponentConsumerProps
has been removed, if you have anyimport
statements that reference it, update them all to useWithSitecoreContextProps
instead. -
Because the
resolvePageUrl
function now accepts an object, and becauseserverUrl
is now optional, the latter is omitted if the metadata edit mode for Pages is enabled. If you've customized thepages/api/editing/render.ts
file and you currently pass theresolvePageUrl
function 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
EditingComponentPlaceholder
or theRenderingType
enum, 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/image
component (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/image
to 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
import
statement 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/image
component, add the following rendering that includes the newly-definedunoptimized
prop: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:
-
If you have not customized the
/src/Scripts.tsx
file, replace it with the 22.1 version. Otherwise, modify it as follows:-
Add the following
import
statement:RequestResponseimport { EditingScripts } from '@sitecore-jss/sitecore-jss-nextjs';
-
Add an
EditingScripts
component: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.ts
file, replace it with the 22.1 version. Otherwise, modify it as follows:-
Add the
useSiteQuery
parameter to theGraphQLDictionaryService
initialization: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.ts
file, replace it with the 22.1 version. Otherwise, modify it as follows:-
Update the
personalizeLayout
function call to passpersonalizeData.componentVariantIds
as 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.ts
file, replace it with the 22.1 version. Otherwise, modify it as follows:-
Prepare
personalizeData.componentVariantIds
and add it as a parameter of thepersonalizeLayout
function 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.ts
file, replace it with the 22.1 version. Otherwise, modify it as follows:-
In the
personalizeMiddleware
constructor signature, locate the following line withincdpConfig
if present:RequestResponsescope: process.env.NEXT_PUBLIC_PERSONALIZE_SCOPE,
-
If it is present, move that line to the root of the constructor signature, outside of
cdpConfig
.
Here's an example of the updated constructor signature suitable for JSS 22.1:
RequestResponsethis.personalizeMiddleware = new PersonalizeMiddleware({ ... cdpConfig: { ... }, scope: process.env.NEXT_PUBLIC_PERSONALIZE_SCOPE, });
ImportantKeeping this
scope
withincdpConfig
will 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.Metadata
by 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.ts
file:-
Add the following
import
statement:RequestResponseimport { EditMode } from '@sitecore-jss/sitecore-jss-nextjs';
-
In the
handler
definition, 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.ts
file from your new 22.1 app into your existing app. -
If you have not customized the
lib/page-props-factory/plugins/preview-mode.ts
file, 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
PreviewModePlugin
class declaration, locate the existingdata
assignment, 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.editable
property 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.