WooCommerce Proof of Concept

👨‍💻 Framework Development » Framework Design
10

I’ve updated the README.md file in the repository with the changes we did yesterday.

Check it out:

1 Like
11

Would it be possible to use the Embedded mode in woocommerce.frontity.org and deploy the GitHub repo to Vercel? Or this would affect somehow the people using woocommerce.frontity.org to test it in Decoupled?

I ask because it could be nice that users can have a look at the status of the proof of concept directly in woocommerce.frontity.org.

12

It should work the same, as Frontity in decoupled mode only interacts with the REST API.

Just take in mind that the WordPress instance Luis deployed is restored every 24 hours so, if you want to add the embedded mode, you would have to talk first with him!

13

I have set it up in woocommerce.frontity.org as well. It should be working fine now.

I have also set up automatic deploys to Vercel and Changesets in that repo so we can have a changelog of the changes.

I think the proof of concept is good enough at this point to get some external feedback about it.

To be honest, we learned a lot and the Store API shows a lot of promise, so I think we can consider this research a success. Also, I think this opens an opportunity to collaborate more closely with the WooCommerce team :slightly_smiling_face:

Apart from that, these are my impressions.

Store API

These are the fixes that would make Frontity integration with the Store API easier.

Adding the slug field to the products

The response of the Store API doesn’t include the slug yet, which is something we use in Frontity.

For example: https://woocommerce.frontity.org/wp-json/wc/store/products/34

Filtering products by slug

The Store API has a lot of filters, but it doesn’t include a slug one yet. It would be great to have one as Frontity relies a lot on that to do the match between entities and frontend URLs.

Current filters: https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/trunk/src/StoreApi/docs/products.md#list-products

Renaming permalink to link

The WordPress REST API uses link in all their endpoints, but the Store API is using permalink.

For consistency with the regular REST API, and because Frontity does a transformation of those link fields to remove the domain so they can be used in decoupled mode, it would be great it the Store API would use link instead of permalink.

Remaining work in the package

This is non-exhaustive list of things we still need to do.

Prepare the package for optimistic updates

Right now we are copying everything that we get from the Store API into the state, but we should improve in this regard.

We should prepare the package (state and actions) for optimistic updates. That means that:

  • The information in the state should be only once. If some information can be derived from other parts of the state, it should be written as derived state. This is the “source of truth” principle.
  • Actions should update the state first, then send the request, then revert the state if the request failed.

For example, right now the total price is here:

const total = state.woocommerce.cart.totals.total_price;

But it can be derived from the sum of all the item totals. Something like this:

const total = ({ state }) =>
  state.woocommerce.cart.items.reduce(
    (total, item) => totel + item.totals.line_total,
    0
  );

And actually, the total of each item should also be derived from the price of that item, multiplied by the quantity, and so on…

The goal of having a single source of truth is that it simplifies state mutations a lot: if an action modifies a single part of the state, for example the quantity of a product, the rest of the fields will reflect that change immediatly in the UI.

It also means that the application will be less prone to bugs because the derived state is managed by the state manager and nothing can get out of sync.

Handle errors

We should add a way to handle errors, both in the interface and in the state.

Maybe for the interface this package could show some of the errors using toasts. As toasts are displayed on top of the theme, that would make things easier for theme developers. Of course that would need to be optional.

Support variable products

We should add support for variable products in the theme, to make sure there is no problem with that.

Create the commerce namespace

We should work on a common commerce package to allow people to use other implementations, like for example: https://github.com/wp-graphql/wp-graphql-woocommerce.

Make it work with nonces

We should add a way to make this work with nonces. Right now they are disabled.

We could use ajax. Actually, there is something in the WordPress Core already for that, I don’t know if we could use it: https://github.com/WordPress/wordpress-develop/blob/master/src/wp-admin/includes/ajax-actions.php#L5323-L5330

Handlers for the product taxonomies

We should add handlers for the product taxonomies: product categories and tags.

Handlers for the filtered products

We should add handlers for all the queries that WooCommerce supports. Thinkgs like /shop/?orderby=price and so on. That way, theme creators can add filters that simple use actions.router.set to render the new list.

Support all themes

For this proof of concept we made a “WooCommerce theme”, but this package should take care of adding the shop, product pages, cart, checkout and thank you pages with a default UI for themes that don’t have direct support for WooCommerce in the same way that you can use WooCommerce with a PHP theme that doesn’t have WooCommerce support.

Support WooCommerce Blocks

We should add support for the new WooCommerce Blocks. Things like capturing the “Add to cart” buttons with a processor and linking those buttons to our actions.woocommerce.addToCart() actions.

For now it seems like these blocks are not writing HTML to the database and they rely on React for client-side rendering, but I guess that will change at some point. We should ask the WooCommerce team about their plans :slightly_smiling_face:

Release some ready-to-use components

To facilitate the creation of WooCommerce themes, we could include React components for that can be reused for the common UI elements, like:

  • Filters for products: Price range, selectors…
  • The Cart.
  • The Checkout.
  • An Image slider with augmentation tool.
  • The Order info.
  • And so on.

Product Post Previews

Right now the post previews are not working because the Product handler is not using the standard REST API and therefore doesn’t have an endpoint to get the last revisions. We should look for a solution for this.

Retrieval of orders by order_key

After a sucessful checkout we are showing the order information because it is stored in the state, but we don’t have access to it once the users refreshes the page. We need an endpoint where we can fetch the information of an order using the order_key to simulate what WooCommerce does in WordPress.

Support different payment methods

We should experiment with more realistic payment methods, like Stripe or Paypal.

Last but not least, the main drawback I see with the Store API is that they are not using the standard REST API endpoints for the products and product taxonomies. I am not sure if they studied that option and discarded it. It would be another interesting point to talk with them :slightly_smiling_face:

3 Likes
14

This is a demo and a bit of a summary as well of the current state of the proof-of-concept:

Feel free to share it :slight_smile:

5 Likes
15

WooCommerce has no ETA on the API shipping as stable…
And since we perhaps need to wait a long time before WooCommerce finish their own API. Perhaps even two years: https://github.com/woocommerce/woocommerce-gutenberg-products-block/tree/trunk/src/StoreApi

I think it’s smart to look at some alternatives…

You cannot wait two years or more on WooCommerce before implementing support for this… ECommerce is important for any framework! This should be prioritized and be implemented with the Frontity WordPress plugin.

I think it’s important for Frontity to add proper support for WooCommerce as soon as possible.

Have you looked into which of these that can be the best approach and that gives the most features?

or

2 Likes
16

Thanks a lot for the feedback :slightly_smiling_face: I agree that we have to keep in mind other alternatives to ease the WooCommerce integration, and the ones you shared look pretty interesting. Right now, it’s possible to build an ecommerce using WooCommerce and Frontity, but we would like to work on a package to make it easier, that is what the proof of concept was about.

As I said, you can still integrate WooCommerce yourself, just as you would do in a NextJS or Gatsby app, using whatever tools you prefer on top of Frontity and React.

Some members of the community have already tried WooCommerce in their Frontity projects, and some of them were able to integrate it using the CoCart plugin you suggest. Here you have some forum threads that might be useful → https://community.frontity.org/tag/woocommerce .

In addition, this is another good article on creating a React front end for WooCommerce that may help you with your project: https://www.joshuaiz.com/words/no-woocommerce-cart-api-no-problem.

If you try any of these alternatives, we would love to know your opinion :slightly_smiling_face:

3 Likes
17

This was made with Frontity and CoCart and it is quite impressive: https://www.texasmattressmakers.com/

There is another opportunity here: creating a commerce namespace.

Packages that would implement the commerce namespace should be interchangeable. After all, they all should do the same, they simply use different APIs to communicate with the backend.

The state and actions of that namespace would be things like:

  • state.commerce.cart
  • state.commerce.checkout
  • actions.commerce.addItemToCart()
  • actions.commerce.applyCoupon()
  • …

If there is someone willing to start working on a WooGraphQL or a CoCart package for Frontity, we could work with them on a standard @frontity/commerce namespace.

2 Likes
18

Hi Frontity. My name is Sébastien Dumont, creator of CoCart.

Happy to answer any questions or help collaborate on building any tools you need to help make CoCart work better with Frontity. I already have a JS library available

I’m still new to React so let me know if this enough or not.

I’m currently testing and fixing bugs in v3.0 of CoCart which will be out soon.

I look forward to helping the Frontity community any way I can.

4 Likes
19

That sounds awesome Sébastien! Thanks a lot for stopping by :slightly_smiling_face:

Yeah, I think so. It sounds like a cocart package for Frontity could be just a thin wrapper on top of that library to expose those actions and state in the Frontity store. Similar to what we did for the Store API proof of concept (this thread).

Awesome. Congratulations on CoCart by the way! :grinning_face_with_smiling_eyes:

3 Likes
20

CoCart v3 is currently in testing stages and your all welcome to try it. Once testing is complete and v3 is released, I will be focusing on finishing the checkout and customers dashboard ability.

Details about v3 of CoCart can be found here: CoCart v3 Preview - CoCart

I look forward to your feedback.

4 Likes
21

CoCart v3 is now released. :smiley:

4 Likes
22

Nice… looking forward to seeing this working with Frontity :smiley:

1 Like
23

Looks great! Congratulations :slightly_smiling_face:

1 Like
24

I realize this is not end of the world but just a FYI that the https://woocommerce.frontity.org/ site is showing SSL certificate expired. How did I even get to this url? After cloning the Proof of Concept on Github > running server on localhost > source defaults to https://woocommerce.frontity.org/

27

@simsev I’ve just checked and it works fine for me. What browser are you using?

28

The SSL works fine for me too :slightly_smiling_face:

How did I even get to this url?

You have a full explanation about the proof of concept and how to work with it in the Readme of this GitHub repo. I think it could be helpful :slightly_smiling_face:

1 Like
29

My apologies guys! Works now

30

Should be able to start working on a CoCart concept with Frontity soon but would like to know if the concept you created with WooCommerce API is a wrapper that can be applied to any theme or is it hard coded within a theme?

Just like to get a little feedback as I am still new to React.

Thank you.

2 Likes
31

Just released v3.1 beta 1 which introduces a setup wizard to help setup the headless environment and more. I’m hoping this release will help a little more for those who want to use Frontity with WooCommerce.

2 Likes