Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove propTypes definitions #42364

Open
33 tasks done
nielslange opened this issue May 19, 2023 · 23 comments
Open
33 tasks done

Remove propTypes definitions #42364

nielslange opened this issue May 19, 2023 · 23 comments
Labels
priority: normal The issue/PR is of normal priority—not many people are affected or there’s a workaround, etc. team: Kirigami & Origami WC Store Editing (FSE) type: cooldown Things that are queued for a cooldown period (assists with planning). type: enhancement The issue is a request for an enhancement. type: epic Container issue with high-level description of work that will be done in sprint. type: refactor The issue/PR is related to refactoring.

Comments

@nielslange
Copy link
Member

nielslange commented May 19, 2023

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

Preview Give feedback
  1. team: Kirigami & Origami type: cooldown type: enhancement type: refactor
    albarin
  2. priority: normal team: Kirigami & Origami type: cooldown type: enhancement type: refactor
    nielslange
  3. team: Kirigami & Origami type: community contribution type: cooldown type: enhancement type: refactor
    thealexandrelara

Done

Preview Give feedback
  1. type: cooldown type: enhancement type: refactor
  2. type: cooldown type: enhancement type: refactor
  3. type: cooldown type: enhancement type: refactor
    thealexandrelara
  4. type: cooldown type: enhancement type: refactor
  5. type: cooldown type: enhancement type: refactor
  6. type: cooldown type: enhancement type: refactor
  7. type: cooldown type: enhancement type: refactor
  8. type: cooldown type: enhancement type: refactor
  9. type: cooldown type: enhancement type: refactor
    albarin
  10. type: cooldown type: enhancement type: refactor
  11. type: cooldown type: enhancement type: refactor
  12. type: cooldown type: enhancement type: refactor
    samueljseay
  13. type: cooldown type: enhancement type: refactor
  14. type: cooldown type: enhancement type: refactor
  15. type: cooldown type: enhancement type: refactor
  16. type: cooldown type: enhancement type: refactor
    mikejolley
  17. type: cooldown type: enhancement type: refactor
  18. type: cooldown type: enhancement type: refactor
  19. type: cooldown type: enhancement type: refactor
  20. type: cooldown type: enhancement type: refactor
    roykho
  21. type: cooldown type: enhancement type: refactor
    roykho
  22. type: cooldown type: enhancement type: refactor
    sunyatasattva
  23. type: cooldown type: enhancement type: refactor
    roykho
  24. type: cooldown type: enhancement type: refactor
  25. type: cooldown type: enhancement type: refactor
  26. type: cooldown type: enhancement type: refactor
    thealexandrelara
  27. type: cooldown type: enhancement type: refactor
    albarin
  28. type: cooldown type: enhancement type: refactor
    albarin
  29. type: cooldown type: enhancement type: refactor
  30. type: cooldown type: enhancement type: refactor
@nielslange nielslange added type: enhancement The issue is a request for an enhancement. type: refactor The issue/PR is related to refactoring. type: cooldown Things that are queued for a cooldown period (assists with planning). type: good first issue The issue is a good candidate for the first community contribution/for a newcomer to the team. labels May 19, 2023
@hritikchaudhary
Copy link
Contributor

hritikchaudhary commented May 19, 2023

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
Copy link
Member Author

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.

@nielslange nielslange added type: epic Container issue with high-level description of work that will be done in sprint. and removed type: good first issue The issue is a good candidate for the first community contribution/for a newcomer to the team. labels May 19, 2023
@hritikchaudhary
Copy link
Contributor

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

@nielslange
Copy link
Member Author

@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
Copy link
Contributor

Thanks @nielslange

@hritikchaudhary
Copy link
Contributor

hritikchaudhary commented May 20, 2023

Hi @nielslange, I have completed the setup of the development environment, had to install [email protected] 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
Copy link
Member Author

@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
Copy link
Contributor

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
Screenshot 2023-05-22 at 1 28 15 PM
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...
image
Can I still go ahead with the changes, relying on unit test and build?

@nielslange
Copy link
Member Author

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.

@hritikchaudhary
Copy link
Contributor

ohh! got it.
Thanks!

@hritikchaudhary
Copy link
Contributor

Raised 1st PR woocommerce/woocommerce-blocks#9565 to fix woocommerce/woocommerce-blocks#9514 and woocommerce/woocommerce-blocks#9523

@hritikchaudhary
Copy link
Contributor

woocommerce/woocommerce-blocks#9595 to fix woocommerce/woocommerce-blocks#9519

@nielslange
Copy link
Member Author

woocommerce/woocommerce-blocks#9613 to fix woocommerce/woocommerce-blocks#9517 woocommerce/woocommerce-blocks#9545 woocommerce/woocommerce-blocks#9547 woocommerce/woocommerce-blocks#9548

Hi @hritikchaudhary,

Thanks a lot for your effort on these issues, especially on woocommerce/woocommerce-blocks#9613. I've had a quick look at it and see that you've worked on four different sections:

  • assets/js/atomic/blocks/product-elements/add-to-cart/
  • assets/js/base/components/product-list/
  • assets/js/blocks/price-filter/
  • assets/js/blocks/product-new/

Your hard work is truly appreciated! You've applied changes to multiple sections, and that shows your dedication.

However, just to share some thoughts for future work - it can be a bit easier to manage if we do smaller updates. For example, instead of one big update that includes changes to many sections, we can do smaller updates for each section.

Why is this a good idea? Let's imagine this scenario: we put all the changes together, but after a few weeks we discover a problem in one section. If we need to go back to the previous version, we'd have to undo all the changes, not just the ones that caused the problem.

On the other hand, if we did separate updates for each section, we could just go back to the previous version of the section with the problem. The other sections wouldn't be affected.

I understand that this may seem like more work, and I'm sorry if it seems like I'm asking a lot. But it will make it easier to find and fix any issues in the future. Would it be possible to split woocommerce/woocommerce-blocks#9613 into separate updates for each section? If it's too much work, don't worry, we can keep it as is for now.

And for next time, if you could focus your updates on one specific section, that would be amazing! Hope this makes sense and thanks again for all your hard work. You're doing a fantastic job!

@hritikchaudhary
Copy link
Contributor

Yes no worries I can split woocommerce/woocommerce-blocks#9613 into separate updates one for each issue.. it is not much work.
Thanks for the feedback!

@hritikchaudhary
Copy link
Contributor

hritikchaudhary commented May 28, 2023

@hritikchaudhary
Copy link
Contributor

Hi @nielslange, I was going through reviews module assets/js/blocks/reviews we have 10 files in it but as only 3 files had proptypes on 3 issues are there, I think we should convert all of them to ts/tsx. If you agree can I fix these in one of the three issues we have or should i create new issues for each and add them to this epic?
Here is the list of files in that folder:

  1. assets/js/blocks/reviews/attributes.js
  2. assets/js/blocks/reviews/edit-utils.js
  3. assets/js/blocks/reviews/editor-block.js
  4. assets/js/blocks/reviews/editor-container-block.js - Convert editor-container-block.js to editor-container-block.tsx and replace propTypes with TypeScript definitions woocommerce-blocks#9526
  5. assets/js/blocks/reviews/example.js
  6. assets/js/blocks/reviews/frontend-block.js - Convert frontend-block.js to frontend-block.tsx and replace propTypes with TypeScript definitions woocommerce-blocks#9525
  7. assets/js/blocks/reviews/frontend-container-block.js - Convert frontend-container-block.js to frontend-container-block.tsx and replace propTypes with TypeScript definitions woocommerce-blocks#9527
  8. assets/js/blocks/reviews/frontend.js
  9. assets/js/blocks/reviews/save.js
  10. assets/js/blocks/reviews/utils.js

@nielslange
Copy link
Member Author

Hi @nielslange, I was going through reviews module assets/js/blocks/reviews we have 10 files in it but as only 3 files had proptypes on 3 issues are there, I think we should convert all of them to ts/tsx. If you agree can I fix these in one of the three issues we have or should i create new issues for each and add them to this epic? Here is the list of files in that folder:

Thanks for double-checking. I'd say, converting all files to .ts/.tsx makes sense. Please go ahead and do that. The next days, I'll be travelling, so I might review your contributions a bit slower. Feel free to slow down a bit. 😀

@hritikchaudhary
Copy link
Contributor

Thanks for double-checking. I'd say, converting all files to .ts/.tsx makes sense. Please go ahead and do that. The next days, I'll be travelling, so I might review your contributions a bit slower. Feel free to slow down a bit. 😀

haha sure np..

@senadir senadir added the team: Kirigami & Origami WC Store Editing (FSE) label Nov 28, 2023
@ObliviousHarmony ObliviousHarmony transferred this issue from woocommerce/woocommerce-blocks Dec 11, 2023
@nielslange nielslange added the priority: normal The issue/PR is of normal priority—not many people are affected or there’s a workaround, etc. label May 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: normal The issue/PR is of normal priority—not many people are affected or there’s a workaround, etc. team: Kirigami & Origami WC Store Editing (FSE) type: cooldown Things that are queued for a cooldown period (assists with planning). type: enhancement The issue is a request for an enhancement. type: epic Container issue with high-level description of work that will be done in sprint. type: refactor The issue/PR is related to refactoring.
Projects
None yet
Development

No branches or pull requests

3 participants