Customizing WC is a pain because of the mix of data, layout and styling in templates and WC template functions. Dealing with API circumvents that by working only with data. But that creates a solution that is not compatible with the WC ecosystem of plugins and themes.
Not sure about performance - constructing a product list view or a shop landing page would require many API calls, with each API call loading WP, WC and fetching db data. When this happens in a normal PHP page view, this happens only once. That’s just my thinking, without measuring anything.
I think, as it is, PGWC gives a good compromise between using the official WC approach and giving flexibility.
@matjaz Thanks for the detailed answer. I wanted to know what areas I need to use jquery with Pinegrow woo elements. I am not loading jquery on the cart and checkout page as I use the gutenberg woo official blocks which have no dependency for the same. I will use PG woo elements on the rest of the pages (product loop, single product). So will I need jquery on those pages? I don’t use the default woo photo gallery as we have a different custom field for photos and gallery.
Thanks @matjaz. Everything is working fine and smooth. I am also looking for a way to use custom cpt (non woo) to add products to woo cart. They have a price custom field. I tried a few solutions but they turned out messy and didn’t work well. Do let me know if you know any way to achieve this.
@Pinegrow_Learner the solution looks like a hack, it would be super hard to maintain compatibility with WC. My take is that WC is not built to be used with non-product post types. There are many checks for “product” === post->post_type in the WC code.
It would be better to extend the Product post type with the features you need, instead of getting WC to work with CPT.