Feature 22 - Blocks for WP Contributions

[emilse-webdev]

Description

Adding blocks for the plugin (Done!). Added phpcs too

Task / Issue

Blocks enhacement

Passed Tests

In local

[emilse-webdev]

Not finished **

[tw2113]

Hey @emilse-webdev

A couple decent sized things here.

1. Is this block meant to only be for Plugin contributions? Or is it meant to handle all 4 contribution types in the end? Asking because we have 4 possible versions: Theme, Plugin, Codex, and WordPress Core.
2. When it comes to the block(s) development, whether we are going to do individual blocks for each contribution type, or one block that handles all 4, we are going to want to make use of functional components as opposed to class based block components.
3. Personally, since we already have 4 different widgets, and looks like only 2 shortcodes, I'd prefer to see individual blocks for each contribution type. It should allow for minimal attributes needed for each block and rendering as needed.

Based on this we would need to rework this branch and pull request a bit to make it so that this specific block is listed and displayed as such to be specifically the plugin block, as well as restructure the files to have that match. That would allow us to copy/paste/rename files to make the other contribution type blocks with minimal retyping.

We also need to rework to make it based on functional components instead of class based.

For the block rendering, look around in the WP_Widget class extensions and the widget method to see how those are displaying the final card result, and let's mimic from there.

Let me know if you have any questions or want to possibly rubber duck to plan some stuff out for this. I've had my head in block creation for a couple months now so it's still generally fresh in my mind.

[emilse-webdev]

I'm trying to handle a single component for each contribution type, as there's two shortcodes at the moment, I've started with rendering the shortcodes and yes, I'd also prefer function components, lets see how it goes. I will re-order it, I'm trying to have it 100% working and order and clean everything. Thanks a lot for the block rendering tip it will help a lot!

[tw2113]

Perhaps to help mentally break down this task of creating blocks for our contribution types, think of it this way.

Theme/Plugin contributions Shortcode: has a slug parameter for the plugin/theme slug on WordPress.org. has a "type" parameter that we hardcode based on which shortcode is being displayed. Widget: has a generic widget title parameter, and a slug parameter.

So the most persistent thing we need to have here is the slug to use, and then a hardcoding of the type is fine. I would review the helper-functions.php as well, as those could prove useful for the block. For example you just need to ultimately pass what will be the slug attribute in the server side render, into say wp_contributions_plugin_card() and echo the returned value. There's a theme function of the same naming structure in that helper file, that can be useful for the theme block.

[emilse-webdev]

with the current methods I can render the card correctly, but it renders at the header of the page, I need to return the html with the data so it renders where the card is added, I'm creating an adapted template for blocks, commiting soon.

[emilse-webdev]

Working all ! Now replicating for Core and Codex !

[emilse-webdev]

Done! all working! I'll upload the recording to show how it works

[tw2113]

How much effort would be needed to move the build process out of the block folder and into the root package.json so that we have just the one to work with?

I'm absolutely on board with the idea of getting rid of Grunt for the build process as that's extremely legacy at this point and no longer used on any client site.

Package.json

Also curious where you got the dev dependencies list. Not saying it's necessarily a bad list to use, but I'm curious if a lot of them are the same ones that we have in other projects that WebDevStudios has going. Lastly on this topic I'm wondering how things would go if we were to get the versions used bumped up to the latest versions. Since this a new feature for the plugin, we have zero to worry about for breaking backwards compatibility, and may as well start with the latest of them all.

You can get a list of out of date packages with npm outdated and perhaps a solid list to go off of for packages would be what we're using with CPTUI-Extended, https://github.com/WebDevStudios/CPTUI-Extended/blob/master/package.json in case you're wanting to match up with other products we've been working on in 2022.

Also let's switch to making use of @wordpress/scripts in our dev dependencies

Build

I'm not sure if I'm not doing something right, but it's not appearing to be building for me fully locally. I am seeing this error in my browser console:

Warning: WP_Contributions_Block.getDerivedStateFromProps(): A valid state object (or null) must be returned. You have returned undefined.

Block src

Would love to see the src files separated out a bit more, making use of imports to make everything overall a bit more clean and organized. Here's where we can also switch out the wp usage for the WordPress scripts import.

The save portion of block.js is good and as it should be, but I'd like to get the edit into its own file.

Is there specific purpose for using RichText for the theme/plugin slug? or could that be a general text field?

Sidebar.js

Not quite sure what the purpose of this file is and what its contents are meant for. Is it possible that it's leftovers from previous attempts? Or does it for sure have purpose here. Also this file is still in the class components style as opposed to functional components, in case it is still being intently used.

Definitely making some good progress overall here, and based on what I'm seeing, the final results of the block should be displaying the intended content in the end. However, there's need to keep massaging the code for some consistency and everything. We'll get there!

[emilse-webdev]

I will move it to the main package and also update everything and order in separate files, the sidebar was an additional intent for letting the user have an option for applying custom css and selectable templates. I made the main functionality but wanted to add that to have it full with all features.

[tw2113]

Closing as we finished up a block in PR #34