Product Title, Product Stock, Product Summary don't load in the frontend when added alone

[Aljullu]

To reproduce

1. Create a post or page in a dev build.
2. Add one of those three blocks: Product Title, Product Stock, Product Summary.
3. Choose a product and visit the post/page in the frontend.
4. Notice the block doesn't load and there is an error in the console:
   404 GET .../wp-content/plugins/woocommerce-gutenberg-products-block/build/product-title-frontend.js

Expected behavior

The block should load correctly and there shouldn't be a 404 error.

[tomasztunik]

Mentioned blocks are atomic Product Element blocks, and we have couple more of those than the ones listed here. So far we did not expose any of the atomic Product Element blocks as standalone webpack entry points.

Should we expose all of them? I can see how it might be nice to build completely custom landing pages using this or sky is the limit really! But we should make a call if we want to expose all elements as entry points, if not all should be exposed have clear conditions what should be exposed or make it not possible to insert atomic elements outside of parent blocks that support them.

To expose them we need to add them to the webpack.entries.js and provide custom dir to their location in assets/js/atomic/blocks folder ie.

	'product-title': {
		customDir: '../atomic/blocks/product-elements/title',
	},

Most of those blocks don't implement frontend rendering (via frotnend.js/ts/tsx) of the block and they'll fail to load as *-frontend.js variant of the block is not generated unless block has it available.

This is as far as I made it. The question is - should atomic blocks have ability to be rendered as stand-alone blocks and if so - are they still atomic components? Should we then implement frotnend variant for all of those components?

This worked in editor because in editor edit variant was used not frontend one.

[Aljullu]

Thanks for the research @tomasztunik!

This is as far as I made it. The question is - should atomic blocks have ability to be rendered as stand-alone blocks and if so - are they still atomic components? Should we then implement frotnend variant for all of those components?

I think the initial intention was to make those blocks available standalone, so it wouldn't be required to add them inside one of their parents. But yes, it looks like the issue is not only with the three blocks I reported, but with all atomic blocks. There still seems to be something different in those three blocks because I get a 404 requests when they are in a post or page and I don't get the same errors with other atomic blocks (ie: Product Price).

In any case, and given that these blocks are available as standalone blocks only in dev builds, it's probably low priority issue. 👍

[tomasztunik]

@Aljullu this is because when block is lazy fetched it expects the -frontend.js variant to be available - this one is present only if block has a frontend.js/ts file present in its component directory to represent client side version of the component.

If you look into atomic components folders you'll see that a lot of them don't have it.

[Aljullu]

Right, none of the atomic blocks renders in the frontend if added standalone, but the 404 error only happens in three of them. Ie: if you add the Product Price block to a post or page and visit the frontend, you won't see any 404 requests even though it doesn't have a -frontend file; but if you do the same with Product Title, there is a 404 error.

I didn't do much research, but might it be related with the fact that we register ProductTitle, ProductSummary and ProductStockIndicator in the PHP side? They inherit from the AbstractBlock class, which by default enqueues frontend scripts.

In any case, that's very low priority because those blocks are only available in dev builds and we don't know if they will ever be available in production as standalone blocks. 🙂

[tomasztunik]

This is partially fixed by #5989 - when requested the blocks will have its code properly loaded on demand.

[github-actions]

This issue has been marked as stale because it has not seen any activity within the past 60 days. Our team uses this tool to help surface issues for review. If you are the author of the issue there's no need to comment as it will be looked at.

Internal: After 10 days with no activity this issue will be automatically be closed.

[Aljullu]

I'm going to close this issue, as the future way to use these blocks is inside the Single Product block (#8610).