Shopify heavily uses <template> elements with their Storefront Web Components project, except the templates themselves are passed as a child to the web component, that dynamically queries the data necessary to render the template, before mounting the element to the DOM: https://shopify.dev/docs/api/storefront-web-components
I'm on the dev team that built this. Happy to answer any questions!
We essentially use web components as a templating language to dynamically generate a GraphQL query to Shopify. Then render the data as text nodes inside the web components. This is powerful because the components don't include shadow roots. So you can come with your own HTML and CSS.
Most web component libraries are opinionated about design, and give you many CSS custom properties or CSS parts to customize. We tried really hard to invert that, and instead give you the design control. Most of our web components just produce a text node, with no shadow root!
There's a few exceptions, like the cart for example, where it's easier to just have an out of the box component that does it all for you `<shopify-cart>`. Though...you can actually build the entire cart component with the lower level primitives!
This looks great, glad to see this project and congrats on the launch. Having said that, how does this project fit in with the Shopify Hydrogen effort using Remix / React? There seems to be an ever growing number of ways to build a shopify storefront these days (ie, native templates, remix/hydrogen, web components, Shopify JS Buy SDK, etc.) so it's not clear what technology to "bet on" from a developer perspective.
Separately, nice touch adding the refined LLM instructions, this looks like a nice pattern for other UI frameworks to follow.
I'm a big fan of web components, and this seems like a very cool project. I'm curious about how it fits into the broader frontend ethos at Shopify. I remember the Shopify team being one of the earliest proponents of React Server Components, for example. Is the team still working in that direction as well, or does this represent a new direction org-wide?
I'm also on the hydrogen team. Today we also shipped support for Hydrogen on React Router 7, which has experimental support for RSC: https://remix.run/blog/rsc-preview
Awesome! I appreciate all the open work your team does. A couple years ago, I was staffed on a project that was adopting RSC super early on, and I vividly remember crawling through Shopify blogs/code as one of the few solid resources available.
I'm excited to see more Web Component libraries in the wild eschewing the Shadow DOM. I don't think enough developers have yet caught the message that the Shadow DOM is optional and Web Components are simpler and especially simpler to style if they skip it.
How are these order annotated in Shopify admin? Thinking specifically about various types of partnerships? Could a flow automation be set up to: pay commission (for the influencer model), pay inverse wholesale pricing (for dropshippers), etc.
This seems super powerful. Would you recommend that an app developer who is creating App Blocks for PLPs (Search, Collections, etc.) use these new Web Components instead of building everything themselves?
This is primarily for embedding in 3p sites, Shopify already has liquid for hosted storefronts. As for search and collections, we don't quite yet have support for search and filters. Though we do support pagination.
I like Remix's paradigm of waiting to stream until the primary content is rendered and available, and then only streaming secondary content. So for example, on an e-commerce product page, all the markup representing the product would not stream. Secondary content like related products would. This allows you to 500 error if the primary content fails rendering for one reason or another. And if the secondary content fails to render during streaming, you can easily hide the content or render a placeholder.
I’m not familiar with shopify but I’m about to start a shopify project for a client.
Can you elaborate on what the difference is between Hydrogen and a custom theme? Other than the tooling and template language I’m struggling to understand the conceptual differences.
Hydrogen is essentially a headless storefront, you have complete control over how your storefront is rendered, but it does come with boilerplate and helpers for some standard primitives that most people will want (e.g. carts).
Custom themes allow you to template on top of the Shopify front end, giving you less control.
If liquid is what you know and love, 100% stick with it. Liquid isn't going away, and there are plenty of opportunities to build out liquid storefronts. Hydrogen is built for custom storefronts that need more flexibility than what is available in a liquid theme. It's entirely customizable. Hydrogen has better performance capabilities as well, because it can be stream rendered to the client.
"Why shouldn't I stick to server side rendered pages?"
Hydrogen is still server rendered. Server components themselves never execute in the browser.
Hi! Great work so far. Does the team have a vision for a way to standardize the front-end part of shopify apps? That seems to be the really tricky part of a appstore-based platform going headless.
Hi, do you think is the right time to start developing an ecommerce with Hydrogen? It sounds you're still in a beta phase where api may change frequently.
