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

Adding test name block with support for entity data store #37132

Merged
merged 9 commits into from Mar 13, 2023

Conversation

joelclimbsthings
Copy link
Contributor

@joelclimbsthings joelclimbsthings commented Mar 8, 2023

All Submissions:

Changes proposed in this Pull Request:

Adding a basic name block to the product editor, with support for the entity data store.

Closes #37007 .

How to test the changes in this Pull Request:

  1. Checkout branch.
  2. Enable new-product-management-experience feature flag.
  3. Navigate to Products -> Add new.
  4. You should see the block editor, with the name block present.
  5. If you have redux dev tools, open them and select the core store (for some reason this is listed twice for me, and I need to select the 2nd one)
  6. Notice when you type into the name field that the EDIT_ENTITY_RECORD action is fired.

Other information:

  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you written new tests for your changes, as applicable?
  • Have you created a changelog file for each project being changed, ie pnpm --filter=<project> changelog add?
  • Have you included testing instructions?

FOR PR REVIEWER ONLY:

  • I have reviewed that everything is sanitized/escaped appropriately for any SQL or XSS injection possibilities. I made sure Linting is not ignored or disabled.

@github-actions
Copy link
Contributor

github-actions bot commented Mar 8, 2023

Test Results Summary

Commit SHA: ca24f9e

Test 🧪Passed ✅Failed 🚨Broken 🚧Skipped ⏭️Unknown ❔Total 📊Duration ⏱️
API Tests25900202610m 54s
E2E Tests189006019514m 25s

To view the full API test report, click here.
To view the full E2E test report, click here.
To view all test reports, visit the WooCommerce Test Reports Dashboard.

@codecov
Copy link

codecov bot commented Mar 8, 2023

Codecov Report

Merging #37132 (ca24f9e) into trunk (0cf5677) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff            @@
##             trunk   #37132   +/-   ##
========================================
  Coverage     46.7%    46.7%           
  Complexity   17191    17191           
========================================
  Files          429      429           
  Lines        64845    64845           
========================================
  Hits         30275    30275           
  Misses       34570    34570           
Impacted Files Coverage Δ
...ugins/woocommerce/includes/class-wc-post-types.php 2.8% <ø> (ø)

@joelclimbsthings joelclimbsthings changed the base branch from trunk to add/initial-product-draft-37003 March 8, 2023 20:14
@joelclimbsthings joelclimbsthings self-assigned this Mar 8, 2023
@joelclimbsthings joelclimbsthings requested a review from a team March 8, 2023 20:15
@joelclimbsthings joelclimbsthings marked this pull request as ready for review March 8, 2023 20:15
"compilerOptions": {
"outDir": "build"
"outDir": "build",
"resolveJsonModule": true,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to tweak TS configuration to support importing JSON files, as there are benefits to using the standard block.json file to provide metadata.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1


blocks.push(
createBlock( nameBlock.name, {
name: product.name,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious if this logic will still be needed if we start using templates to generate the form?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@louwie17 After our conversation this morning, my thought is no (it's not needed). I believe once we have your template PR merged I can just register this block and move it to the template..? If you get that merged first, I'm glad to rebase and retool a bit. Otherwise we can migrate it in that PR or another follow-up.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also in favor of removing this. Seems like at best we can avoid this, but worst case is we will need to parse the product and retrofit it into the hydrated template.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Louren's settings PR is now merged, and I've rebased this PR to include it. I started experimenting with loading the blocks from the post type template in d284e9b. I'm uncertain of the pattern here, and arguably this might belong in a separate PR. I can continue on Monday but let me know if you have any thoughts @louwie17

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I don't think its necessary to register the template as a block (unless you saw a similar pattern in Gutenberg somewhere?)
In theory we should just be able to pass it into the setupEditor function similar to what Josh started doing here: https://github.com/woocommerce/woocommerce/pull/36921/files#diff-5fbb147f0c06b95b81afa9f70ae6db13e289b2714f4b21d041a7bd88670a1d03R106

Josh's approach is similar to Gutenberg's approach here: https://github.com/WordPress/gutenberg/blob/trunk/packages/editor/src/components/provider/index.js#L84
We may also want to make use of the useBlockEditorSettings that is being made use of there (if the call to setupEditor is not enough).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But on second thought it might help to leave this as is for now and merge it, to un-block any block field work and create a separate PR for the template support.

Base automatically changed from add/initial-product-draft-37003 to trunk March 9, 2023 21:11
@github-actions github-actions bot added the plugin: woocommerce Issues related to the WooCommerce Core plugin. label Mar 11, 2023
@louwie17
Copy link
Contributor

@joelclimbsthings I hope you don't mind, but I messed around with the template work and got it working in this commit: aff7ac2
So I decided to push it up right away.

@mdperez86
Copy link
Contributor

@joelclimbsthings and @louwie17 Good work here and also tested well to me. I'm going to merge this PR as we talked @louwie17 so we can unblock the rest of the issues the depend on this PR.

@mdperez86 mdperez86 self-requested a review March 13, 2023 14:44
Copy link
Contributor

@mdperez86 mdperez86 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job!!!

@mdperez86 mdperez86 merged commit 4dff6db into trunk Mar 13, 2023
30 checks passed
@mdperez86 mdperez86 deleted the add/name-block-37007 branch March 13, 2023 14:45
@github-actions github-actions bot added this to the 7.6.0 milestone Mar 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plugin: woocommerce Issues related to the WooCommerce Core plugin.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create a product name field block
4 participants