Add Server Side Render component. #5602

miina · 2018-03-14T09:14:47Z

Description

Fixes #780: Adds ServerSideRender component and /gutenberg/v1/blocks-renderer/:block API endpoints for dynamic blocks which together enable server side rendering for dynamic blocks in Gutenberg editor. API endpoint is leveraging the already existing render_callback of the block and returns identical HTML output.

Types of changes

Adds ServerSideRender component which can be used for dynamic blocks for server side render. Usage example: <ServerSideRender block="core/latest-posts" attributes={ attributes } />.
Adds /gutenberg/v1/blocks-renderer/:block API endpoints, expects the block to be in the format of namespace/block-name.

How Has This Been Tested?

Has been tested functionally with core/archives and also phpunit.

Screenshots:

Archives block with ServerSideRender component:

Checklist:

My code is tested.
My code follows the WordPress code style.
My code has proper inline documentation.

Thoughts are welcome!

…omponent.

miina · 2018-03-14T11:17:12Z

Question: at this moment the change in attributes is detected by using componentWillReceiveProps -- is there a better way to bind the change of props to updating the preview?

paulwilde · 2018-03-14T11:31:34Z

components/server-side-render/index.js

+ ...attributes,
+ _wpnonce: wpApiSettings.nonce,
+ } );
+ return window.fetch( apiURL, {


May want to use wp.apiRequest for consistency. See #5253.

I think more of a guide on using would help with that. I was working on another PR that used wp.apiRequest and it was leading to test failures (maybe it was how #4710 used in redux connect) so I removed, tests started passing and I could move forward. The only reason my modifications caused issues using wp.apiRequest as far as I could tell was that the tests themselves were not being passed enough context.

mtias · 2018-03-14T15:15:19Z

components/server-side-render/README.md

+Render core/latest-posts preview.
+```jsx
+ <ServerSideRender
+ block="core/latest-posts"


We should probably register another block for something that makes more sense server-rendered (maybe tag cloud widget?) to use as the example.

I could add Archives block from #5495. It's otherwise ready except for the preview which was waiting for SSR.

@mtias For usage example I merged the code from this PR to #5495 which adds Archives block -- thought that this way this PR wouldn't have to wait for potential fixes for the Archives block.

So basically #5495 now includes adding Archives block + SSR component with the idea that SSR component could be merged separately first.

Let me know if that's OK or if you'd prefer having the Archives block added here under this PR.

cc @westonruter

@mtias Updated the description with added screenshots of Archives block based on SSR. Let me know if there's anything else you see in the PR that requires addressing.

mtias · 2018-03-14T15:20:33Z

lib/class-wp-rest-blocks-renderer-controller.php

+ *
+ * @see WP_REST_Controller
+ */
+class WP_REST_Blocks_Renderer_Controller extends WP_REST_Controller {


Should this be singular? Block_Renderer...

Yah, same with the endpoint route.

Done in c4abc69

westonruter · 2018-03-14T17:33:39Z

lib/class-wp-rest-blocks-renderer-controller.php

+ return new WP_Error( 'rest_block_invalid_name', __( 'Invalid block name.', 'gutenberg' ), array( 'status' => 404 ) );
+ }
+
+ $atts = $this->prepare_attributes( $request->get_params() );


Since we have $block here, this means that we have $block->attributes which can be used with rest_validate_value_from_schema() and rest_sanitize_value_from_schema(). For example:

$atts = array(); $schema = $block->attributes; foreach ( $request->get_params() as $key => $value ) { if ( ! isset( $schema[ $key ] ) ) { return new WP_Error( 'rest_unrecognized_block_attribute' /* ... */ ); } $validity = rest_validate_value_from_schema( $value, $schema[ $key ], $key ); if ( is_wp_error( $validity ) ) { return $validity; } $atts[ $key ] = rest_sanitize_value_from_schema( $value, $schema[ $key ] ); }

This should eliminate the need for prepare_attributes entirely.

westonruter · 2018-03-14T17:36:50Z

lib/class-wp-rest-blocks-renderer-controller.php

+ public function register_routes() {
+
+ // @codingStandardsIgnoreLine - PHPCS mistakes $this->namespace for the namespace keyword.
+ register_rest_route( $this->namespace, '/' . $this->rest_base . '/(?P<name>[\w-]+\/[\w-]+)', array(


One idea: instead of letting name be a parameter, we could register over all of the registered blocks and create an endpoint for each one. This could then allow for the block's attributes schema to be used as an attributes object arg in the args here, and it would eliminate the need for prepare_attributes logic in get_item_output. (See https://core.trac.wordpress.org/ticket/38583)

This would allow for a list of all the server-side renderable blocks to be discovered by looking at the REST API schema. Only the blocks returned by get_dynamic_block_names() would be included.

westonruter · 2018-03-14T17:38:46Z

lib/class-wp-rest-blocks-renderer-controller.php

+ 'title' => 'blocks-renderer',
+ 'type' => 'object',
+ 'properties' => array(
+ 'output' => array(


I think the rendered name would be more in-line with the rest of the REST API.

Done in c4abc69

westonruter · 2018-03-14T17:43:19Z

components/server-side-render/index.js

+ }
+
+ return (
+ <RawHTML key="html">{ response }</RawHTML>


Should this use SandBox instead?

I guess not because then styles won't be applied.

@westonruter Sandbox doesn't stop styles being applied (If I understand correctly it ensures no css / js bleeds into admin experience). It's used in #4710. Should work on such block-specifics defer to this once it's released?

I mean the CSS from the editor. Otherwise, the CSS has to be re-printed in the iframe.

westonruter · 2018-03-14T17:44:52Z

components/server-side-render/index.js

+ }
+
+ componentWillReceiveProps( nextProps ) {
+ if ( JSON.stringify( nextProps ) !== JSON.stringify( this.props ) ) {


What about using isEqual from lodash?

I was going to comment that there was room to figure out how aggressive this component should be with refetches and ask if a shallow equality check could make any sense. However, by design, block attributes should (until abused) retain a very simple shape. isEqual should do it.

More importantly, it's not clear to me why there is state synchronization at all. Perhaps this is a relic of a previous solution? response appears to be the only datum requiring local state. Component props should be fed directly into getOutput. If the goal is to trigger a refetch and a rerender, the following should be enough:

componentWillReceiveProps( nextProps ) { if ( ! isEqual( nextProps, this.props ) ) { this.getOutput(); } }

…t of the REST API * Singularize "blocks renderer" to "block renderer" * Rename 'output' property to 'rendered' property. * Re-use get_item_permissions_check and get_item method names.

pento · 2018-03-14T18:52:31Z

lib/class-wp-rest-block-renderer-controller.php

+ * @return WP_REST_Response|WP_Error Response object on success, or WP_Error object on failure.
+ */
+ public function get_item( $request ) {
+ if ( ! isset( $request['name'] ) ) {


The regex for name in the register_rest_route() call means $request['name'] should never be not set.

westonruter · 2018-03-14T22:24:41Z

I'm working on refactoring how the routes are registered. Will be pushing up within the hour.

* Supply block attributes schema as endpoint schema. * Introduce attributes endpoint property and let REST API schema validate and sanitize them. * Ensure that attribute values are sanitized in addition to validated.

miina · 2018-03-15T13:34:08Z

lib/class-wp-rest-block-renderer-controller.php

+ $registry = WP_Block_Type_Registry::get_instance();
+ $block = $registry->get_registered( $request['name'] );
+ $data = array(
+ 'rendered' => $block->render( $request->get_param( 'attributes' ) ),


@westonruter This isn't working with the current SSR component code since the attributes are all sent as separate params and not as one attributes array:

const apiURL = addQueryArgs( '/gutenberg/v1/block-renderer/' + block, { ...attributes, _wpnonce: wpApiSettings.nonce, } );

Just sending attributes: attributes as param would fail the request, is there an existing method that creates an acceptable query string for the API (e.g. ?attributes[key1]=value1&attributes[key2]=value2... etc? If not then perhaps we could still pass all the attributes as separate params and modify the endpoint accordingly. Thoughts?

That's a good question. I think it's important for attributes to be under an attributes query parameter because that will prevent conflicts with block attributes. Like if a block has a name or a context these will conflict with the REST API args. It seems like this should be allowed:

const apiURL = addQueryArgs( '/gutenberg/v1/block-renderer/' + block, { attributes, _wpnonce: wpApiSettings.nonce, } );

In other words, I think addQueryArgs needs to be able to properly convert arg values that are objects.

Couldn't find an existing method at this moment, apparently query-string is intentionally not supporting nested attributes and suggests sending the object as a JSON string.

Added a custom method for now to the class to put together the query string supporting objects (ServerSideRender.getQueryUrlFromObject).

mcsf · 2018-03-15T12:35:18Z

components/server-side-render/README.md

+
+ServerSideRender component is used for server-side rendering preview in Gutenberg editor, specifically for dynamic blocks. Server-side rendering in a block's `edit` function should be limited for blocks which are heavily dependent on (existing) PHP rendering logic that is heavily intertwined with data, such as when there are no endpoints available.
+
+New blocks should be built in conjunction with any necessary REST API endpoints so that JavaScript can be used for rendering client-side in the `edit` function for the best user experience, instead of relying using the PHP `render_callback`. The logic necessary for rendering should be included in the endpoint so that both the client-side JS and server-side PHP logic should require a mininal amount of differences.


s/relying using/relying on/

mcsf · 2018-03-15T13:08:55Z

components/server-side-render/README.md

+ServerSideRender
+=======
+
+ServerSideRender component is used for server-side rendering preview in Gutenberg editor, specifically for dynamic blocks. Server-side rendering in a block's `edit` function should be limited for blocks which are heavily dependent on (existing) PHP rendering logic that is heavily intertwined with data, such as when there are no endpoints available.


I think it's important to stress two other conditions to prefer SSR, more significant, I dare say, than the logic/data entanglement, since that isn't of itself insurmountable:

A lack of potential to take some existing widget-like functionality and improve its user-facing editing experience. For instance, even Archive could benefit from a full JS-driven editing mode: similarly to how Latest Posts offers presentation tweaks (e.g., whether to display as a grid, to show publishing date) or beyond (e.g., allowing tweaking an entry's title, changing its date or otherwise moving it out of that particular archive view).

An unwillingness to create a full JS experience for a block considered legacy.

The ultimate point, perhaps, is that—however useful—SSR should be regarded as a fallback.

mcsf · 2018-03-15T13:09:12Z

components/server-side-render/README.md

+
+## Usage
+
+Render core/latest-posts preview.


s/latest-posts/archives/

mcsf · 2018-03-15T13:09:32Z

components/server-side-render/README.md

+
+## Output
+
+Output is using the `render_callback` set when defining the block. For example if `block="core/latest-posts"` as in the example then the output will match `render_callback` output of that block.


s/latest-posts/archives/

mcsf · 2018-03-15T13:40:48Z

components/server-side-render/index.js

+ }
+
+ componentWillReceiveProps( nextProps ) {
+ if ( JSON.stringify( nextProps ) !== JSON.stringify( this.props ) ) {


I was going to comment that there was room to figure out how aggressive this component should be with refetches and ask if a shallow equality check could make any sense. However, by design, block attributes should (until abused) retain a very simple shape. isEqual should do it.

More importantly, it's not clear to me why there is state synchronization at all. Perhaps this is a relic of a previous solution? response appears to be the only datum requiring local state. Component props should be fed directly into getOutput. If the goal is to trigger a refetch and a rerender, the following should be enough:

componentWillReceiveProps( nextProps ) { if ( ! isEqual( nextProps, this.props ) ) { this.getOutput(); } }

mcsf · 2018-03-15T13:41:22Z

components/server-side-render/index.js

+ }
+ }
+
+ getOutput() {


Is a name like fetch more apt?

mcsf · 2018-03-15T13:46:02Z

components/server-side-render/index.js

+ constructor( props ) {
+ super( props );
+ this.state = {
+ response: {},


Is the empty object as a representation of missing state a pattern from somewhere else? I'd expect null or undefined to be a better fit. This works well with the fact that the request resolution already checks for response truthiness:

if ( response && response.output ) {

Meaning that we can easily distinguish the three possible states, e.g.:

no content: response === null

content missing: response !== null && isEmpty( response )

count found: ! isEmpty( response )

mcsf · 2018-03-15T13:47:52Z

phpunit/class-rest-block-renderer-controller-test.php

+
+ /**
+ * NA.
+ */


I'd drop the placeholder comments, since they can throw our linter off and later slip through review.

mcsf · 2018-03-15T13:48:54Z

lib/class-wp-rest-block-renderer-controller.php

+ * @access public
+ */
+ public function __construct() {
+


Per the project's style guide, function bodies shouldn't start with an empty line. The same applies to other occurrences in the diff.

danielbachhuber

👍 Looking pretty good on my end. Left some minor nit picks and then I think we're good for merge.

danielbachhuber · 2018-04-24T12:44:17Z

lib/class-wp-rest-block-renderer-controller.php

+ * @access public
+ */
+ public function __construct() {
+ // @codingStandardsIgnoreLine - PHPCS mistakes $this->namespace for the namespace keyword.


Can we ignore this in the ruleset?

Added an exception for this file within 6d1ee65.

danielbachhuber · 2018-04-24T12:45:16Z

lib/class-wp-rest-block-renderer-controller.php

+ continue;
+ }
+
+ // @codingStandardsIgnoreLine - PHPCS mistakes $this->namespace for the namespace keyword.


Ditto above.

Added an exception for this file within 6d1ee65.

danielbachhuber · 2018-04-24T12:46:48Z

lib/class-wp-rest-block-renderer-controller.php

+ public function get_item( $request ) {
+ global $post;
+
+ $post_ID = isset( $request['post_id'] ) ? intval( $request['post_id'] ) : 0;


Can we change the casing of $post_ID to $post_id ?

Changed within 6d1ee65.

danielbachhuber · 2018-04-24T12:51:09Z

lib/class-wp-rest-block-renderer-controller.php

+ }
+
+ $data = array(
+ 'rendered' => $block->render( $request->get_param( 'attributes' ) ),


We may also be passing the full block content to the render callback in #6239

Rather than needing to remember passing all supported arguments to the render() callback, it would be useful to have a helper function for this.

danielbachhuber · 2018-04-24T12:54:24Z

phpunit/class-rest-block-renderer-controller-test.php

+ $response = $this->server->dispatch( $request );
+
+ $this->assertErrorResponse( 'gutenberg_block_cannot_read', $response, rest_authorization_required_code() );
+ }


Can we include additional tests for test_get_item_without_permissions_invalid_post() and test_get_item_without_permissions_cannot_edit_post(), just to make sure we have those code paths covered?

danielbachhuber · 2018-04-24T13:04:01Z

Re-requesting a review from @mcsf, because I'd like to make sure his prior comments were addressed to his satisfaction.

I've created a new issue for batch previews in #6381

@westonruter Can you speak briefly to how server block validation (#4063) relates to this endpoint?

…server-side-render

pento

This is good to go. I'll merge it shortly.

aduth · 2018-04-30T18:32:32Z

components/server-side-render/index.js

+ const path = '/gutenberg/v1/block-renderer/' + block + '?context=edit&' + this.getQueryUrlFromObject( { attributes } );
+
+ return wp.apiRequest( { path: path } ).then( ( response ) => {
+ if ( response && response.rendered ) {


There's nothing to say that the component is still mounted by the time this response is received, so attempting to setState will result in errors. If anything asynchronous is to occur in a component, it must be complemented by a cancellation in componentWillUnmount. It's a bit burdensome, but also speaks to the bigger concern that handling asynchronous behaviors in components is knowingly hard to maintain (and why extracting these behaviors out into e.g. data/core-data avoids this burden being placed on the component author and enables reuse)..

Changed within #6571.

aduth · 2018-04-30T18:34:35Z

components/server-side-render/index.js

+ const response = this.state.response;
+ if ( ! response || ! response.length ) {
+ return (
+ <div key="loading" className="wp-block-embed is-loading">


For what reason do we need a key?

Replaced with Placeholder within #6571.

aduth · 2018-04-30T18:35:03Z

components/server-side-render/index.js

+ return (
+ <div key="loading" className="wp-block-embed is-loading">
+
+ <p>{ __( 'Loading...' ) }</p>


Do we need both a div and a p, or would one or the other have been sufficient?

Replaced with Placeholder within #6571.

aduth · 2018-04-30T18:35:53Z

components/server-side-render/index.js

+ getQueryUrlFromObject( obj, prefix ) {
+ return map( obj, ( paramValue, paramName ) => {
+ const key = prefix ? prefix + '[' + paramName + ']' : paramName,
+ value = obj[ paramName ];


Are paramValue and value the same?

Changed within #6571.

aduth · 2018-04-30T18:36:38Z

components/server-side-render/index.js

+ return map( obj, ( paramValue, paramName ) => {
+ const key = prefix ? prefix + '[' + paramName + ']' : paramName,
+ value = obj[ paramName ];
+ return isObject( paramValue ) ? this.getQueryUrlFromObject( value, key ) :


Maybe not intentional:

n_ > _.isObject( [] ) true n_ > _.isObject( function() {} ) true

See also: https://lodash.com/docs/4.17.10#isPlainObject

Changed within #6571.

aduth · 2018-04-30T18:39:51Z

components/server-side-render/index.js

+ }
+
+ fetch( props ) {
+ this.setState( { response: null } );


We should check if this.state.response is already null here, as it will be when this function is called by componentDidMount and we'll wastefully cause an immediate re-render (setState always incurs a render unless prevented by shouldComponentUpdate).

Calling setState() in [componentDidMount] will trigger an extra rendering, but it will happen before the browser updates the screen. This guarantees that even though the render() will be called twice in this case, the user won’t see the intermediate state. Use this pattern with caution because it often causes performance issues. It can, however, be necessary for cases like modals and tooltips when you need to measure a DOM node before rendering something that depends on its size or position.

https://reactjs.org/docs/react-component.html#componentdidmount

Changed within #6571.

aduth · 2018-04-30T18:41:21Z

components/server-side-render/index.js

+
+ const path = '/gutenberg/v1/block-renderer/' + block + '?context=edit&' + this.getQueryUrlFromObject( { attributes } );
+
+ return wp.apiRequest( { path: path } ).then( ( response ) => {


There is available a mapping to @wordpress/api-request as a dependency to avoid referencing the global here.

Changed within #6571.

aduth · 2018-04-30T18:42:27Z

components/server-side-render/index.js

+
+ render() {
+ const response = this.state.response;
+ if ( ! response || ! response.length ) {


Why do we check response.length ? Is it desirable that if an empty response was received from the server, we show a loading indicator forever?

Changed within #6571, let me know if it looks OK now.

mtias · 2018-05-01T11:50:59Z

components/server-side-render/index.js

+ } );
+ }
+
+ getQueryUrlFromObject( obj, prefix ) {


This sounds like a wordpress/url package utility.

This sounds like a wordpress/url package utility.

In fact, it could probably be built-in as the default behavior for the existing addQueryArgs function.

addQueryArgs works well but not for nested attributes, thus the need for creating a custom method. Couldn't find an existing utility that would put together URL in case of nested params, if you happen to know any, happy to change it!

If the behavior is needed, it could be added to the existing function via pull request to the packages repository.

mtias · 2018-05-01T11:52:24Z

components/server-side-render/index.js

+ const response = this.state.response;
+ if ( ! response || ! response.length ) {
+ return (
+ <div key="loading" className="wp-block-embed is-loading">


We shouldn't reuse classes but components. If there's something in the way the embed blocks handles the loading state that is useful, it should be extracted in a separate UI component.

jeffpaul · 2018-05-02T14:53:18Z

@mtias @aduth are your recent comments here something that should be added to a new issue that someone could help pickup and resolve? I want to make sure we capture those as otherwise nothing will happen with your input if we just leave them on this PR post-merge.

aduth · 2018-05-02T15:05:42Z

They could be, yes. My hope would be that the feedback wouldn't simply be ignored by the original participants though.

jeffpaul · 2018-05-02T15:20:20Z

@aduth in my experience, many comments post-merge get lost. So let's capture actionable feedback and get that into a new issue so someone can pick up that work. Feel free to emoji-react on certain comments that are actionable and I can go through and pull all those into a new issue if you'd like.

miina · 2018-05-02T19:27:24Z

@jeffpaul @aduth Looks like @westonruter found a potential bug with SSR component when using the Columns block. Perhaps the post-merge feedback could be addressed together with that.

mtias · 2018-05-03T14:22:09Z

Yes, I don't think an issue is needed in this particular case as the comments with the code are easier to follow — however you prefer, @miina.

miina added 8 commits March 12, 2018 19:52

Add blocks-renderer API endpoint. Add skeleton for ServerSideRender c…

cd58776

…omponent.

Update SSR preview when editing attributes.

b0ede76

Fix binding preview change.

340136e

Fix binding preview change.

514dd4f

Add tests. Fix permission check for get_item.

a90f40d

Remove debugger line.

0c127e1

Fix some phpcs.

b0b977a

Fix some jscs.

395a168

miina mentioned this pull request Mar 14, 2018

Server side rendering API endpoint #780

Closed

Show 'loading' when changing response.

1d05c2d

paulwilde reviewed Mar 14, 2018

View reviewed changes

Use wp.apiRequest for consistency.

c40dd25

miina changed the title ~~Add Server Side Render component [WIP]~~ Add Server Side Render component. Mar 14, 2018

mtias requested a review from a team March 14, 2018 14:59

mtias added [Feature] Block API API that allows to express the block paradigm. Framework Issues related to broader framework topics, especially as it relates to javascript Needs Testing Needs further testing to be confirmed. labels Mar 14, 2018

mtias reviewed Mar 14, 2018

View reviewed changes

westonruter reviewed Mar 14, 2018

View reviewed changes

westonruter added 2 commits March 14, 2018 11:26

Update ServerSideRender readme to note intended usage

f323651

Rename classes, methods, and property to be more aligned with the res…

c4abc69

…t of the REST API * Singularize "blocks renderer" to "block renderer" * Rename 'output' property to 'rendered' property. * Re-use get_item_permissions_check and get_item method names.

pento reviewed Mar 14, 2018

View reviewed changes

Register block-renderer endpoint for each dynamic block

6557877

* Supply block attributes schema as endpoint schema. * Introduce attributes endpoint property and let REST API schema validate and sanitize them. * Ensure that attribute values are sanitized in addition to validated.

miina commented Mar 15, 2018

View reviewed changes

mcsf reviewed Mar 15, 2018

View reviewed changes

ryelle mentioned this pull request Mar 15, 2018

New block: Custom Navigation Menu #5036

Closed

Fixes to README. Use isEqual. Renaming method.

228c756

karmatosed mentioned this pull request Apr 19, 2018

Consider real-world usage of WordPress to quantify assumptions made across the Gutenberg project #6228

Closed

danielbachhuber self-requested a review April 19, 2018 21:44

danielbachhuber requested changes Apr 24, 2018

View reviewed changes

danielbachhuber mentioned this pull request Apr 24, 2018

Create a batch preview implementation for Server Side Render component #6381

Open

danielbachhuber requested a review from mcsf April 24, 2018 13:04

miina added 4 commits April 25, 2018 13:13

Add more tests. Add exception for namespace to as ruleset.

6d1ee65

Fix eslint.

2bbbeb7

Merge branch 'master' of github.com:WordPress/gutenberg into add/780-…

6f7d62e

…server-side-render

Add context param to API request.

67af6b7

danielbachhuber approved these changes Apr 25, 2018

View reviewed changes

danielbachhuber added this to the 2.8 milestone Apr 26, 2018

pento added 2 commits April 26, 2018 14:07

Add version numbers to the phpdocs

007fb1d

Tweak the README a little

1c9ef56

pento approved these changes Apr 26, 2018

View reviewed changes

pento merged commit d7ddb69 into WordPress:master Apr 26, 2018

aduth reviewed Apr 30, 2018

View reviewed changes

mtias reviewed May 1, 2018

View reviewed changes

miina mentioned this pull request May 3, 2018

Fix ServerSideRender component bug with Columns block #6571

Merged

talldan mentioned this pull request Jul 13, 2018

Add Archives block #7949

Merged

mcsf mentioned this pull request Aug 8, 2018

Provide an API to validate block input, either client-side or server-side #4063

Closed

Verdinjoshua26 mentioned this pull request Sep 25, 2022

[Snyk] Fix for 16 vulnerabilities Verdinjoshua26/gutenberg#50

Open

Verdinjoshua26 mentioned this pull request Oct 1, 2023

[Snyk] Fix for 1 vulnerabilities Verdinjoshua26/gutenberg#87

Open

yassine4999 mentioned this pull request Oct 1, 2023

[Snyk] Security upgrade stylelint from 13.13.1 to 14.0.0 yassine4999/gutenberg#21

Open


		ServerSideRender component is used for server-side rendering preview in Gutenberg editor, specifically for dynamic blocks. Server-side rendering in a block's `edit` function should be limited for blocks which are heavily dependent on (existing) PHP rendering logic that is heavily intertwined with data, such as when there are no endpoints available.

		New blocks should be built in conjunction with any necessary REST API endpoints so that JavaScript can be used for rendering client-side in the `edit` function for the best user experience, instead of relying using the PHP `render_callback`. The logic necessary for rendering should be included in the endpoint so that both the client-side JS and server-side PHP logic should require a mininal amount of differences.


		## Output

		Output is using the `render_callback` set when defining the block. For example if `block="core/latest-posts"` as in the example then the output will match `render_callback` output of that block.


		const path = '/gutenberg/v1/block-renderer/' + block + '?context=edit&' + this.getQueryUrlFromObject( { attributes } );

		return wp.apiRequest( { path: path } ).then( ( response ) => {

Add Server Side Render component. #5602

Add Server Side Render component. #5602

Conversation

miina commented Mar 14, 2018 • edited Loading

Description

Types of changes

How Has This Been Tested?

Screenshots:

Checklist:

miina commented Mar 14, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Lewiscowles1986 Mar 15, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pento Mar 14, 2018 • edited Loading

Choose a reason for hiding this comment

westonruter commented Mar 14, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

miina Mar 16, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielbachhuber left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielbachhuber commented Apr 24, 2018

pento left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

miina commented Mar 14, 2018 •

edited

Loading

Lewiscowles1986 Mar 15, 2018 •

edited

Loading

pento Mar 14, 2018 •

edited

Loading

miina Mar 16, 2018 •

edited

Loading