Feature/203 gutenberg block structure

[ryanwelcher]

Description of the Change

This the implementation of the changes outline in #203

Benefits

A defined way of handling blocks in a theme.

Possible Drawbacks

This is big change to the build process.

Checklist:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests passed.

Applicable Issues

#203

Changelog Entry

[dainemawer]

@ryanwelcher forgive me for this one - I'm not sure if our linting even supports it but for a single parameter, functions don't require parentheses.

[ryanwelcher]

ah good catch! VSCode should be formatting on save for me. Wonder if that rule is not being run?

[dainemawer]

@ryanwelcher would it be cleaner to maybe organise the folder so that we could export out something like: import { edit, save, json } from './folder'

[dainemawer]

@ryanwelcher just a couple of things that we've been encountering on projects lately:

• It would be nice to start the Theme Scaffold with the PHP wiring to blocks, a lot of projects I've been working on includes PHP Classes like BlockFactory and AbstractBlock as well as provides a way for adding blocks to an allowList and denyList.
• Over the last year, we've really been using ServerSideRender quite heavily. Would be good to have an example of a ServerSideRender block setup (if that's possible)

Everything else looks really great - glad you're paying this some attention!

[fabiankaegy]

I also took a look at the PR and it looks very solid to me 👍 This will result in a much better workflow when working with block in themes.

[ryanwelcher]

@dainemawer thanks for the feedback!

• It would be nice to start the Theme Scaffold with the PHP wiring to blocks, a lot of projects I've been working on includes PHP Classes like BlockFactory and AbstractBlock as well as provides a way for adding blocks to an allowList and denyList.

This makes a lot of sense. My concern with adding it in was that we quickly get into a lot of code/boilerplate that may or may not be useful on all projects. The concept behind registering the blocks in a single place on the PHP side does lend it self to an allow/deny list very easily via a a custom php filters - but again not necessarily on every project.

As an aside, there is an internal block-library plugin being worked on that will provide a set of blocks as well as a way to add more blocks on a per-project basis. I would be concerned that having an API here as well as in that plugin would be more confusing than helpful/

• Over the last year, we've really been using ServerSideRender quite heavily. Would be good to have an example of a ServerSideRender block setup (if that's possible)

This is potentially a larger conversation, I don't think the "10up way" should be to use ServerSideRender to render the block in the edit state unless there is a reason for doing so - such as needing the latest data from the server. The majority of the time, a block can leverage the markup structure from the PHP side with the addition of RichText fields to allow inline editing and keep the inputs out of the Block Inspector panel. The same CSS can be used in both the editor and the front end and the user gets a much more integrated experience that doesn't require PHP renders for every change.

[dainemawer]

@dainemawer thanks for the feedback!

• It would be nice to start the Theme Scaffold with the PHP wiring to blocks, a lot of projects I've been working on includes PHP Classes like BlockFactory and AbstractBlock as well as provides a way for adding blocks to an allowList and denyList.

This makes a lot of sense. My concern with adding it in was that we quickly get into a lot of code/boilerplate that may or may not be useful on all projects. The concept behind registering the blocks in a single place on the PHP side does lend it self to an allow/deny list very easily via a a custom php filters - but again not necessarily on every project.

As an aside, there is an internal block-library plugin being worked on that will provide a set of blocks as well as a way to add more blocks on a per-project basis. I would be concerned that having an API here as well as in that plugin would be more confusing than helpful/

• Over the last year, we've really been using ServerSideRender quite heavily. Would be good to have an example of a ServerSideRender block setup (if that's possible)

This is potentially a larger conversation, I don't think the "10up way" should be to use ServerSideRender to render the block in the edit state unless there is a reason for doing so - such as needing the latest data from the server. The majority of the time, a block can leverage the markup structure from the PHP side with the addition of RichText fields to allow inline editing and keep the inputs out of the Block Inspector panel. The same CSS can be used in both the editor and the front end and the user gets a much more integrated experience that doesn't require PHP renders for every change.

Thanks for this insight @ryanwelcher - and thanks for listening to my opinions. Looking forward to this being merged in.

[samikeijonen]

@ryanwelcher Would all custom blocks have it's own entry point?

[ryanwelcher]

@samikeijonen yes. Technically, each block could have the same JS File as the enqueue process would only add it once but each block has it's own assets.

[ryanwelcher]

I've added some notes/changes from @jaredrethman and some further tweaks. I'd love another set of 👀 on it if possible. I have an internal project that needs to adhere to how we create blocks in the scaffolds, so I'd like to get this ironed out soonish if possible.

[joesnellpdx]

@ryanwelcher

I left a few comments. I may be dense as I'm certainly not the Gutenberg expert - so please push back if any of my comments / suggestions are off base.

My overarching concerns:

• Consistency across our tooling and guidance for blocks (training, block library, scaffolding)
• "Easy" (relatively) to follow patterns
• Not adding unnecessary bloat, render blocking scripts, etc to the output that will negatively impact performance (especially on the front end - although we've been seeing issues in the admin on super complex block setups)

Besides the above and my other comments, the setup works for me and I have no issues.

Please add a time on my calendar if would make more sense to discuss!

[ryanwelcher]

@joesnellpdx changes based on our call have been pushed.

[joesnellpdx]

After discussing my concerns with @ryanwelcher, hopping on a call and making a few tweaks - I support these updates with the following caveats.

1. @tlovett1 review the updates to the webpack.settings.js and webpack.config.common.js - in reference to the ~10upScripts that are in motion
2. A small blog post is sent out at the time of this release so folks don't get caught off guard.