Serializing differently than previewing

[sirbrillig]

I wanted to open the discussion on potentially using this to server-side render dynamic blocks. For a trivial example, how could we display a block that contained the WP site-title?

One suggestion that I've seen is to serialize such a block as a custom HTML tag, such as <SiteTitle />. That would cause it to be silently and safely ignored if it was being parsed by a browser. Then there would be a PHP filter (registered as part of the block plugin) which would transform that tag into markup before it is rendered to the client.

In this case the editor preview of a block would be rendered by the JavaScript component, possibly using the REST API to get the data it requires. When serializing to the post content, however, the output would need to be different than the preview. To that end could we have an optional method on the registered block in addition to display that was used for serialization, if present. (Maybe something like encode.)

[aduth]

To me, it seems that at least one thing served well by shortcodes is this sort of dynamic rendering requirement. That is, unless, part of the hope with a block syntax is to try to consolidate everything (e.g. shortcodes, widgets) to a single unified convention. Even if that's the case, If it could be deferred to a future milestone, I don't see why in the meantime we couldn't simply have the use case of a site title satisfied by...

<!-- wp:site-title -->
[site_title]
<!-- /wp -->

(assuming comment syntax for delineating blocks, where in the editor the form UI behaviors associated with dynamic blocks could still allow for managing applicable options)

[sirbrillig]

👍 I agree that deciding this is not crucial at this stage.

That said, I think there's a real slippery slope when it comes to using shortcodes for this sort of thing: if we don't provide a new mechanism, shortcodes will almost certainly be used to add new dynamic blocks, which could quickly mean that the number of shortcodes in use skyrockets. It's been discussed several times in core channels, but shortcodes were never designed for heavy usage; they are error-prone, hard to parse, and generally not performant. IMO we should definitely be working to make sure the blocks API affords supporting a means to replace them.

[aduth]

It's been discussed several times in core channels, but shortcodes were never designed for heavy usage; they are error-prone, hard to parse, and generally not performant.

Seems regardless of whether it's shortcodes or a new syntax we develop, these are factors we'd need to address; Is there something inherent to shortcodes that makes their syntax or implementation a poor choice for dynamic blocks? What I'm getting at is... if we're likely to encounter similar concerns in a custom syntax, should we simply look to optimize shortcodes instead?

(I might be out of the loop to the specific concerns around shortcodes, so any links to previous discussions or overviews would be appreciated.)

[sirbrillig]

I'll try to find links, but my understanding is that the issue lies in that they behave sort-of like html, but they are not html, and they are embedded within html. For example, something like this: <a href="[url_shortcode link='http://google.com']">[dynamic_text_shortcode wrapper="<div class='mytext'>{{text}}</div>"]</a>. Also they are parsed with regular expressions, which makes them more fragile.

Yes, a version of shortcodes which used custom html tags would, I think, solve all the issues around their use. I'm hopeful that such a syntax can be developed as part of the block API.

A few possibly relevant links:

• https://wordpress.slack.com/archives/core-editor/p1484854528001636
• https://make.wordpress.org/core/2017/01/17/editor-technical-overview/ (see "Coda" section)
• https://make.wordpress.org/core/2015/10/14/shortcodes-roadmap-clarifications/

There's definitely been more discussion around this, but for some reason I can't find it right now.