Send post_id to the REST API in the ServerSideRender component within the Editor #9323
Conversation
| @@ -20,10 +20,11 @@ import { addQueryArgs } from '@wordpress/url'; | |||
| import Placeholder from '../placeholder'; | |||
| import Spinner from '../spinner'; | |||
|
|
|||
| export function rendererPathWithAttributes( block, attributes = null ) { | |||
| export function rendererPath( block, attributes = null, urlQueryArgs = null ) { | |||
There was a problem hiding this comment.
Minor: I think for this case we may be able to do urlQueryArgs = {} on the parameter list, and then ...urlQueryArgs inside addQueryArgs.
For attributes probably we did not follow this path because we needed to wrap it in an object.
There was a problem hiding this comment.
Good call. Done.
| @@ -0,0 +1,3 @@ | |||
| # ServerSideRender | |||
There was a problem hiding this comment.
Minor: We normally name the file README.md (in caps). Maybe we can append some text saying it adds the post_id to the urlQueryArgs of ServerSideRender exposed in '@wordpress/components'.
There was a problem hiding this comment.
Heh. Turns out I had fixed the name in a rebase and forgot to push! 🤦♂️
Updated the text.
| const { getCurrentPostId } = select( 'core/editor' ); | ||
|
|
||
| return { | ||
| urlQueryArgs: { |
There was a problem hiding this comment.
We are ignoring the urlQueryArgs we may be receiving. Maybe we can just check if in urlQueryArgs props this component receives the property post_id is not set and if that's case we add it. urlQueryArgs would default to "{}" so on the most common case we would only add the post_id (equivalent to what we have now).
There was a problem hiding this comment.
Good catch! I've updated the implementation for this. It no longer uses withSelect but just returns a functional component instead.
packages/editor/src/utils/index.js
Outdated
| @@ -2,5 +2,6 @@ | |||
| * Internal dependencies | |||
There was a problem hiding this comment.
We have some prior art in having a component in @wordpress/editor that adds/enhances props to a component in @worpress/components, e.g., https://github.com/WordPress/gutenberg/blob/master/packages/editor/src/components/panel-color/index.js and we implemented them in src/components maybe we can also add this one there to be consistent.
There was a problem hiding this comment.
This is looking good 👍 Thank you for iterating on this @alexsanford! I left some comments with possible improvements we can do but from the functional point of view, the tests went great.
alexsanford
force-pushed
the
fix/post-id-wrapper-for-ssr
branch
from
df6daa6 to
d2d6039
Compare
alexsanford
force-pushed
the
fix/post-id-wrapper-for-ssr
branch
from
d2d6039 to
ff0eb6b
Compare
alexsanford
force-pushed
the
fix/post-id-wrapper-for-ssr
branch
from
ff0eb6b to
0c8481c
Compare
|
@jorgefilipecosta Thanks for the comments! I've addressed them above. Note that since I needed to force push anyway (because of an earlier rebase that didn't get pushed) I went ahead and rebased this onto |
| @@ -20,10 +20,11 @@ import { addQueryArgs } from '@wordpress/url'; | |||
| import Placeholder from '../placeholder'; | |||
| import Spinner from '../spinner'; | |||
|
|
|||
| export function rendererPathWithAttributes( block, attributes = null ) { | |||
| export function rendererPath( block, attributes = null, urlQueryArgs = {} ) { | |||
There was a problem hiding this comment.
Given this is an exported function, do we need to keep (or deprecate) the original rendererPathWithAttributes()?
There was a problem hiding this comment.
Phrased another way: maybe we should keep the name as rendererPathWithAttributes(), and it simply supports a third urlQueryArgs argument.
There was a problem hiding this comment.
Hi @danielbachhuber, the function rendererPathWithAttributes is exported just for testing but is not exported outside of @wordpress/components as we only export the default export outside of the module (the component)
No plugin could have used this function so even if we change the name I don't think deprecations are necessary.
There was a problem hiding this comment.
Ah, makes sense. Thanks for clarifying @jorgefilipecosta
danielbachhuber
added
[Package] Server Side Render
Description
Fixes #8178
This PR adds a wrapper around the
ServerSideRendercomponent within the@wordpress/editorpackage that adds apost_idparameter to the REST API call. This ensures the global$postobject is set properly. Previously, it was only set when rendering to the frontend, but not when rendering for the API call.This PR is an iteration of this previous PR: #8270
How has this been tested?
This was tested locally using a dynamic block that displayed information from the
$postobject, ensuring the post information was rendered properly on the frontend and in the editor usingServerSideRender.An automated test was added to ensure that the parameter is added properly to the URL path.
Also I verified that the current two blocks using
ServerSideRender(Archives and Latest Comments) still work as expected.Types of changes
This change should be a non-breaking enhancement.
That said, I did change the name of the
rendererPathWithAttributesfunction torendererPath, and it's technically possible that some 3rd-party code is importing and using that. But I assume that's ok since it's not part of Gutenberg's documented API.Checklist: