RFC: True MVC blocks using DTO's

[defunctl]

What does this do/fix?

A proof of concept for a single block to show the possibility of true MVC blocks.

This:

1. Heavily reduces the boilerplate required to make a block.
2. Retains type hinting for fields using Data Transfer Objects for the models, just match the properties to the fields and the system does the rest.
3. Seriously reduces the size of controllers, now we only need to inject the block model and that's it. This will make adding new fields much quicker and easier to implement.
4. Uses PHP-DI's autowiring, allowing controllers to inject other dependencies when you need to make more complex blocks or bring in external classes to do more work.

TODO

• [ ] Update tribe-libs generators.
• [ ] Move dependencies to their proper libraries.

QA

Screenshots/video:

Icon Grid Edit Screen:

Icon Grid Frontend:

Tests

Does this have tests?

• [ ] Yes
• [x] Not yet...
• [ ] No, I need help figuring out how to write the tests.

[dpellenwood]

Thanks for mocking this up, @defunctl . The only concern/question I have relates to being able to use a block template/view with data other than an ACF block's registered fields. For example, We often end up with patterns where a Hero Block and a Post Subheader use the same data, layout options, etc but the latter's data source is ACF fields defined for a post type rather than via a block. Can you help me understand how we might accomplish that with this architecture? (Ideally not having to duplicate the template file, Controller classes, CSS/JS, etc.)

[defunctl]

@dpellenwood can definitely look into that, can you point me to code where we're doing that now so I can have a look?

[dpellenwood]

@dpellenwood can definitely look into that, can you point me to code where we're doing that now so I can have a look?

Sure thing. Harvard Public Health has a recent example: Hero Block & Post "Subheader" built by calling the Hero Block template and setting up the necessary data via Post meta fields.

[defunctl]

@dpellenwood can definitely look into that, can you point me to code where we're doing that now so I can have a look?

Sure thing. Harvard Public Health has a recent example: Hero Block & Post "Subheader" built by calling the Hero Block template and setting up the necessary data via Post meta fields.

Awesome, I'll check it out this eve and get back to you.

[defunctl]

@dpellenwood see the updated code pushes. I converted the Hero block into this MVC Field Model system and am now using it in the Single Controller/View, similar to your code example. It still needs work, but definitely shows the basic idea once it's been polished up some.

Screenshot of the hero block being used inside the Single Controller/View:

[dpellenwood]

@dpellenwood see the updated code pushes. I converted the Hero block into this MVC Field Model system and am now using it in the Single Controller/View, similar to your code example. It still needs work, but definitely shows the basic idea once it's been polished up some.

Lovely. Makes total sense to me. Thanks for demoing it!

[ChrisMKindred]

I know this PR is still a WIP but I am going to brain dump some thoughts after a scan of everything:

• I really like having everything about the block in a single place (Model, Config, etc...). Everything is much more easily ported to other projects.
• Can we move the blocks into the plugin? I am not liking it being all in the theme and if we are in Multisite now we are forced to use child themes or double up the code...
• I'd love to be able to filter the view path. Could I filter the view path to load either out of the plugin folder, or just set it up to run a locate_template for the current active theme?