Size Change: -349 B (-0.02%)

Total Size: 1.89 MB

_{compressed-size-action}

Flaky tests detected in 2ea5fa6.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/16371612834
📝 Reported issues:

• [Flaky Test] Redirection after template creation #60678 in /test/e2e/specs/site-editor/site-editor-url-navigation.spec.js

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @amir2mi.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: amir2mi.

Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org>
Co-authored-by: Soean <soean@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: oxyc <scholdstrom@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@WordPress/gutenberg-core, the code is ready for review and initial feedback. I'm working on the remaining to-do list items, which should be a blocker for the review.

Would love some docs, here either in the PR description or JSDoc so it's exposed.

Pushed the JSDoc documentation and e2e tests for ServerSideRender component behavior.

Currently, I’m unsure if I can also export the new hook without introducing breaking changes. Does anyone have experience with similar alterations for core packages?

Why?

• The package only exports one default component; wp.serverSideRender global also refers to that component.
• The new import would resemble this import { default as ServerSideRender, useServerSideRender } from '@WordPress.org/server-side-render'; but how would this translate into wp globals?

Currently, I’m unsure if I can also export the new hook without introducing breaking changes. Does anyone have experience with similar alterations for core packages?

I'm not sure if this is the correct way to do it, but what would happen if we exported the hook like this?

diff --git a/packages/server-side-render/src/index.js b/packages/server-side-render/src/index.js
index 5d90709bea..2b3f874ab6 100644
--- a/packages/server-side-render/src/index.js
+++ b/packages/server-side-render/src/index.js
@@ -9,6 +9,8 @@ import { useSelect } from '@wordpress/data';
  */
 import ServerSideRender from './server-side-render';
 
+export { useServerSideRender } from './hook';
+
 /**
  * Constants
  */
diff --git a/tools/webpack/packages.js b/tools/webpack/packages.js
index c99c25ee01..4730fde776 100644
--- a/tools/webpack/packages.js
+++ b/tools/webpack/packages.js
@@ -114,7 +114,6 @@ const exportDefaultPackages = [
        'dom-ready',
        'redux-routine',
        'token-list',
-       'server-side-render',
        'shortcode',
        'warning',
 ];

From what I've tested, the following import statements should all work:

import ServerSideRender from '@wordpress/server-side-render';
import { useServerSideRender } from '@wordpress/server-side-render';
import ServerSideRender, { useServerSideRender } from '@wordpress/server-side-render';

@t-hamano, I tried that, but it breaks the code that relies on wp globals. You can try running the test plugin in the console to see the breakage.

Examples:

// Doesn't work.
const ServerSideRender = wp.serverSideRender;

// This works, but we'll still be breaking the BC.
const { default: ServerSideRender } = wp.serverSideRender;

Update

@gziolo suggested "exporting" the new hook as a property on the default exported component. It solves the backward-compatibility problem with wp global, but then I see import/named error when I try to use the new import methods.

diff --git packages/server-side-render/src/index.js packages/server-side-render/src/index.js
index 5d90709bea2..c2c3484b718 100644
--- packages/server-side-render/src/index.js
+++ packages/server-side-render/src/index.js
@@ -8,16 +8,14 @@ import { useSelect } from '@wordpress/data';
  * Internal dependencies
  */
 import ServerSideRender from './server-side-render';
+import { useServerSideRender } from './hook';
 
 /**
  * Constants
  */
 const EMPTY_OBJECT = {};
 
-export default function ExportedServerSideRender( {
-	urlQueryArgs = EMPTY_OBJECT,
-	...props
-} ) {
+function ExportedServerSideRender( { urlQueryArgs = EMPTY_OBJECT, ...props } ) {
 	const currentPostId = useSelect( ( select ) => {
 		// FIXME: @wordpress/server-side-render should not depend on @wordpress/editor.
 		// It is used by blocks that can be loaded into a *non-post* block editor.
@@ -43,3 +41,8 @@ export default function ExportedServerSideRender( {
 
 	return <ServerSideRender urlQueryArgs={ newUrlQueryArgs } { ...props } />;
 }
+
+ExportedServerSideRender.ServerSideRender = ExportedServerSideRender;
+ExportedServerSideRender.useServerSideRender = useServerSideRender;
+
+export default ExportedServerSideRender;

Screenshot

Possible solution: the module in the NPM package exports ServerSideRender both as default and named:

// src/index.js
export default ServerSideRender; // mark as @deprecated maybe
export { ServerSideRender, useServerSideRender };

This encourages plugin authors to write import { ServerSideRender } from instead of import ServerSideRender from. That's good because they'll use the new convention, but it's also bad because it will transpile to a wp.serverSideRender.ServerSideRender reference which doesn't exist in old WordPress versions, only in the latest.

When building the wp-server-side-render script, which absolutely needs to be backward compatible, we could introduce a "shim":

// src/script-index.js
import * as ssr from './index.js';

function attachExports( main, all ) {
  for ( const key in all ) {
    if ( key !== 'default' ) {
      main[ key ] = all[ key ];
    }
  }
  return main;
}

export default attachExports( ssr.default, ssr );

And then make the webpack config in tools/webpack/packages.js use the script-index.js when building the package as a script. By modifying the import field for the server-side-render package.

Building the NPM package (build, build-module) will continue to use index.js. We could even break the back-compat there if we wanted and stop doing a default export completely. Because it's just a NPM package, back-compat is really crucial only for the scripts that WordPress uses at runtime.

@jsnajdr, unfortunately, a separate import path was triggering a parse error. To avoid modifying the webpack configuration, I ultimately settled on a mixed solution for the exports, which soft-deprecates the default export.

The new and old exports are functioning as expected in my tests, but I would appreciate a second opinion on this matter.

Screenshot

I've adjusted the JSDocs for the component/hook. The API sections of the README file are now generated automatically.

@WordPress/gutenberg-core, I would appreciate final feedback/reviews here to land this enhancement

My only concern is folks continuing to rely on these components/hooks more, where ideally tailored UI experiences are better.

100%. The tailored UI experience is what we should promote. SSR is a good stepping stone when refactoring existing code, such as shortcodes, and you want to provide a temporary basic UI.