Remove `propTypes` definitions

[nielslange]

While the majority of files have been converted from JS to TS, we still have a few JS files that use propTypes definitions. In addition, we also have a few TSX files that use propTypes definitions.

Steps to reproduce

1. Search for propTypes in your favourite IDE.
2. Exclude the following files/folders:

build, node_modules, vendor, storybook, .xml, .json, reports

Running these steps, I can find 211 results in 36 files.

Expected outcome

I suggest we eliminate all propTypes definitions and utilize TypeScript (TS/TSX) for type checking.

### To do
- [ ] woocommerce/woocommerce-blocks#9524
- [ ] woocommerce/woocommerce-blocks#9526
- [ ] woocommerce/woocommerce-blocks#9539
- [ ] woocommerce/woocommerce-blocks#9542
- [ ] woocommerce/woocommerce#42360
- [ ] woocommerce/woocommerce#42294

### Done
- [ ] woocommerce/woocommerce-blocks#9514
- [ ] woocommerce/woocommerce-blocks#9515
- [ ] woocommerce/woocommerce-blocks#9516
- [ ] woocommerce/woocommerce-blocks#9517
- [ ] woocommerce/woocommerce-blocks#9518
- [ ] woocommerce/woocommerce-blocks#9519
- [ ] woocommerce/woocommerce-blocks#9520
- [ ] woocommerce/woocommerce-blocks#9521
- [ ] woocommerce/woocommerce-blocks#9522
- [ ] woocommerce/woocommerce-blocks#9523
- [ ] woocommerce/woocommerce-blocks#9525
- [ ] woocommerce/woocommerce-blocks#9527
- [ ] woocommerce/woocommerce-blocks#9528
- [ ] woocommerce/woocommerce-blocks#9529
- [ ] woocommerce/woocommerce-blocks#9530
- [ ] woocommerce/woocommerce-blocks#9531
- [ ] woocommerce/woocommerce-blocks#9532
- [ ] woocommerce/woocommerce-blocks#9533
- [ ] woocommerce/woocommerce-blocks#9534
- [ ] woocommerce/woocommerce-blocks#9535
- [ ] woocommerce/woocommerce-blocks#9536
- [ ] woocommerce/woocommerce-blocks#9537
- [ ] woocommerce/woocommerce-blocks#9538
- [ ] woocommerce/woocommerce-blocks#9540
- [ ] woocommerce/woocommerce-blocks#9541
- [ ] woocommerce/woocommerce-blocks#9544
- [ ] woocommerce/woocommerce-blocks#9545
- [ ] woocommerce/woocommerce-blocks#9546
- [ ] woocommerce/woocommerce-blocks#9547
- [ ] woocommerce/woocommerce-blocks#9548

[hritikchaudhary]

Hi @nielslange I'd like to work on this... it'll be my first issue for woocommerce-blocks.. I'm setting it up on my local
if I understand this correctly we have to:

1. Convert JS files to TS/TSX, excluding the mentioned files..
2. Remove propTypes definitions

That's all right?

[nielslange]

Hello @hritikchaudhary 👋 Thanks for showing interest in working on this issue! Any help is much appreciated.

Given that it touches numerous files, I think it might be better to split this issue into individual issues. That way, it's easier to implement the individual issues. Let me quickly convert this issue into an epic and create the necessary individual issues.

Convert JS files to TS/TSX, excluding the mentioned files..

If a *.js file is using a propTypes definition, that file should be renamed to *.ts respectively *.tsx, depending on its nature.

Remove propTypes definitions

The propTypes definition within the individual file should be replaced with the corresponding TS definitions. For example, let's have a look at https://github.com/woocommerce/woocommerce-blocks/blob/trunk/assets/js/blocks/product-search/block.js.

To remove the propTypes definitions, we'd have to introduce an interface, e.g. like this:

interface ProductSearchBlockProps {
	attributes: {
		label: string;
		placeholder: string;
		formId: string;
		className: string;
		hasLabel: boolean;
		align: string;
	};
}

and then change

const ProductSearchBlock = ( {
	attributes: { label, placeholder, formId, className, hasLabel, align },
} ) => {

to

const ProductSearchBlock = ( {
	attributes: { label, placeholder, formId, className, hasLabel, align },
}: ProductSearchBlockProps ) => {

Kindly note that I created the TS interface for demo purposes without looking too much into this case. I noticed that the label good first issue might be misplaced for this issue. Nevertheless, feel free to gap one of the individual issues to work on. I'll create them now.

[hritikchaudhary]

@nielslange sure not a problem, will work on it.

[nielslange]

@nielslange sure not a problem, will work on it.

@hritikchaudhary I just converted this issue into an epic and created all individual issues. You are welcome to pick one of the issues. I suggest starting with the smallest file. Some files are quite big. Converting them from *.js to *.tsx will, most likely, introduce many TypeScript errors. The smaller the file, in terms of lines of code, the less TypeScript errors will be introduced.

Thanks again for showing interest in working in this area, and please don't hesitate to ask if you have any questions. 🙌

[hritikchaudhary]

Thanks @nielslange

[hritikchaudhary]

Hi @nielslange, I have completed the setup of the development environment, had to install php@7.3 from shivammathur/php.
but there is an issue, when I generate zip using npm run package-plugin:dev and upload it to my local wordpress instance it gives me The link you followed has expired. and if i generate a production zip using npm run package-plugin it let me upload the plugin but i don't see any woocommerce block when i try to add blocks.
I also tried to directly pasting generated dev zip in wp-content/plugins but it was not visible under plugins.

Do you know how to resolve this? or where can I look to solve this? Cause i converted a block file and unit tests and linting is successful but is there any way from UI I can confirm the functionality of that file is intact..

Environment info:
Node: v16.15.0
PHP: v7.3.33
Wordpress instance installed in docker
OS: MacOS Ventura (M1 silicon)
Thanks!

[nielslange]

@hritikchaudhary I suggest following the steps as described on Getting Started.

As for the steps you described, I'm not sure what exactly you're trying to do. Here's how my local setup looks like:

• I'm using Laravel Valet for creating local development sites.
• My sites are located at ~/Sites.
• My plugins are located as ~/Plugins.
• My themes are located at ~/Themes.
• My primary development site is https://store.test/ which is located at ~/Sites/store.
• The fork of the WooCommerce Blocks plugin is located at ~/Plugins/woocommerce-blocks.
• That fork is symlinked into my primary site like this:

cd ~/Sites/store/wp-content/plugins
ln -s ~/Plugins/woocommerce-blocks

Apart from symlinking the WooCommerce Blocks plugin into your development site, you could also directly fork the plugin into the plugins folder of the site.

That said, I suggest heading over to Getting Started, which explains how to start contributing to WooCommerce Blocks.

[hritikchaudhary]

Hi @nielslange
Yes I followed the Getting Started only.
One thing i missed was my repo was not located at ~/Plugins as I am using wordpress for docker, but now i have bind the repo to ~/plugins

and I'm able to see WooCommerce Blocks, but still its not visible in panel nor the blocks are visible in blocks inserter, I've build the project already...

Can I still go ahead with the changes, relying on unit test and build?

[nielslange]

One thing i missed was my repo was not located at ~/Plugins as I am using wordpress for docker, but now i have bind the repo to ~/plugins

Keeping the fork of the WooCommerce Blocks repo in ~/Plugins was just an example of what I am doing. The fork can live in any other direction.

and I'm able to see WooCommerce Blocks, but still its not visible in panel nor the blocks are visible in blocks inserter, I've build the project already...

On your screenshot, I see that the WooCommerce Blocks plugin is active, but the WooCommerce plugin is missing. WooCommerce Blocks can be seen as an add-on for WooCommerce. In WooCommerce Blocks, we migrate shortcodes to blocks. Every few weeks, we then merge WooCommerce Blocks into WooCommerce. However, without the WooCommerce plugin, you will not see the functionality of the WooCommerce Blocks plugin.

Can I still go ahead with the changes, relying on unit test and build?

Sure, you can proceed with the changes. To do that, please select one of the tasks, as listed in the description of this epic.