search

ramsaylanier / WordExpress

WordPress using Node, React, GraphQL, and Apollo
http://wordexpress.io
MIT License
1.56k stars 129 forks source link

WordPress built in Shortcodes #12

Open ramsaylanier opened 8 years ago

ramsaylanier commented 8 years ago

As per on the Road Map, WordPress built in short codes, like [caption] should probably work with this project - they currently don't.

I think the most logical step would be to, when rendering the post, parse the post_content field (which I'm already doing), strip out shortcodes and replace them with the output of rendering a React component for that shortcode.

So, we'd create a Caption component, and when we parse the post_contet field, when we see [caption][/caption] we replace it with a the component.

It's probably going to be difficult.

ramsaylanier commented 8 years ago

I've got the Caption shortcode working! Haven't tested with a lot of different options but...seems to work!

zstepek commented 8 years ago

The WP.com API looks like it has a REST endpoint that prerenders shortcode output, which would be useful for cases where you don't yet have a component available. This appears to be what Calypso is using for displaying shortcode generated content in the post editor. Something similar might be useful here, too. A generic React component that displays the HTML returned by the shortcode if there isn't a React component wired up to that shortcode.

ramsaylanier commented 8 years ago

It might be worth looking into if there is an elegant solution that can be incorporated into GraphQL. Just thinking about it - we already have to parse the post-content to pull our the shortcode. If we use the API, we'd have to wait for a result until we can render all of the content. That seems bad.

But I'm definitely open to suggestions. If using the API could work it would save a lot of time.

ramsaylanier commented 8 years ago

Also, the way the Caption shortcode works in this project is without a separate React component. Take a look at the Shortcode functions I built - they just parse a shortcode and return HTML as a string.

zstepek commented 8 years ago

The primary motivator for having the server do the heavy lifting here was for compatibility with third-party plugins that include shortcodes without having to reinvent the wheel. Waiting for the render may not be the worst thing in the world if we have a good intermediary state for the generic shortcode component that shows something is loading, though with the variety of types of content that could be returned by a shortcode, they may be difficult to consistently represent with a generic visual placeholder.

If we look at examples of the flow of asynchronous, data driven documents, many simply reflow the page when the content is available and provide little to no visual feedback before or during reflow. This may be as simple as fading in the content when it loads to signal the visual change and make the transition a bit less jarring to the viewer.

Either way, I think that the ability to register a client-side renderer for a shortcode that bypasses the call to the server and then falling back to a server-generated HTML response covers most potential use cases. Just thinking about the unfortunate reality that some end user who doesn't know what they're doing could be administering a site that uses WordExpress and install something like Visual Composer then wonder why their pages don't render. This would make things just a bit more magical and stupid-proof.

ramsaylanier commented 8 years ago

Agreed. A long term solution to handle all shortcodes is a great idea, but quite a hard task as this point. Using the REST API to handle those seems like the best idea at this point, but it isn't a high priority right now.

Also, figuring out Server Side Rendering is #1 on my to-do list, and will probably have overarching effects on how everything works, this included.