Add Gutenberg block for the [job] shortcode

[ice9js]

Here's my stab at creating a Gutenberg block for the [job] shortcode. Yay!
I wouldn't consider it quite production ready just right now but I think there are a number lessons to be learned here, so here we go:

The block

The block consists of two 'views'. When selected, it will display a select box where one can select the job listing which should be displayed. I'd say that's already a worthwhile improvement over inputting the id's manually.
Ideally the select would be replaced by a search box with autocomplete which can still be added later.

When the block is deselected it will show the preview for the currently selected job listing based on the default template.

A block of blocks

Following our talk with @alexsanford I also started looking into how we could leverage block templates and <InnerBlocks/> to make the layout of this block configurable. I came up with these issues that need to be solved before we can fully explore that idea:

• A 'parent' block seems to have no control over its child blocks but can provide them with default values and arrangement. This means that as of right now a user wouldn't be able to smoothly add and remove child blocks as they'd lack the context of their 'big' parent.
• We'd need to update the shortcodes with a way to pass the arrangement from Gutenberg to the themes. Then it becomes the question of whether any theme authors are willing to implement it.

Theoretically, we could entirely scrap the shortcode at this point and make Gutenberg output the entire HTML straight away (takes care of the latter). This could make sense with server side rendering considering we still want all the updates reflected on the page even after it's been published.

Finally, I'm wondering - if we can make it work - perhaps the next step could be to allow inline edits to job listings straight from Gutenberg ?

Other considerations

• I feel like it might be worth reorganizing our directory structure a bit.
  For example, I made use of Gutenberg's data module and I feel the data layer is something that could be shared between the different blocks for WP Job Manager. I put it in assets/blocks/data for now but it should probably have its own build and be loaded separately.

• For now I resorted to fetching all job listings at once to make the block work but it'd be nice to have a search box instead of a select and filter listings based on that. This might require some updates to the REST API ?

• I updated webpack.config.js so we can continue using ES6 imports for dependencies provided by WordPress core.

To do's:

As I previously mentioned, there are a few rough edges here and there:

• Add loading state/placeholder for when the listings are being loaded
• Replace the job listings select input with a search box
• Split off the data layer
• Add a separate control for triggering between select and preview instead of relying on the block being active ?

[alexsanford]

I will do a proper review soon, but here are a few comments based on your description and an initial look:

Block UI

• What do you think of using an Edit button like I did for the SSR version of the Jobs shortcode block? See [WIP] Gutenberg block for the [jobs] shortcode using Server-Side Rendering #1545. This might be less jarring than a big change on select.

• If you originally select the first item from the dropdown, the UI never changes.

Discussion

A 'parent' block seems to have no control over its child blocks but can provide them with default values and arrangement. This means that as of right now a user wouldn't be able to smoothly add and remove child blocks as they'd lack the context of their 'big' parent.

Yes, I’ve been thinking about this quite a bit, and it’s something that I want to explore more deeply.

Conceptually, we need a way for a block like this to have a “controlling template”, which has (at least) the following properties:

• The template is used by Edit to display the child blocks.
• The child blocks are locked.
  • Note that we may eventually want some children, or some attributes of some children, to be unlocked in order to allow user customization on a per-block basis. This can be in a later iteration, though!
• The template is used for every render. Thus, a block using such a template must be dynamic.
  • We will need to figure out how this works when there are static blocks within the template.
• The template is editable by the theme and/or a user in order to customize the look of the site.
• If the template is changed, all blocks using the template should render using the new template.

Beyond this, we’re also going to need a way to pass data from the parent down to the children (e.g. the Job ID), which I haven’t quite wrapped my head around yet. On the surface, this seems like it should be simple. But this data is going to have to be available in Edit, potentially Save, also on the server in the render_callback, and I’m not sure how static blocks quite fit with this. Still pondering this one.

I’m thinking, though, that we might be able to explore these concepts in our plugins, and extend the discussion into Gutenberg core.

We'd need to update the shortcodes with a way to pass the arrangement from Gutenberg to the themes. Then it becomes the question of whether any theme authors are willing to implement it.

I think in order to move into the “Block of Blocks” approach, as you also mentioned, we need to move away from the shortcodes. We'll need a way for theme developers to change block templates as discussed above. We will keep the shortcodes around for a while, but eventually they will likely be replaced by a block-based way of customizing the site.

Finally, I'm wondering - if we can make it work - perhaps the next step could be to allow inline edits to job listings straight from Gutenberg ?

I think that would be great. We wouldn’t need it on the first iteration, but it would certainly be a great convenience for the user. We would need to think about the UX though; it needs to be clear that the user is editing the actual Job Listing, not just one specific visual representation of it.

[jom]

Closing this for now as it doesn't seem like a priority, but hopefully one day we can start implementing these.