Building custom storefronts on Shopify with Hydrogen

Alright cool, well welcome everybody. As the title slide says, and I'm sure you know since you signed up for this workshop, we're going to be going over building headless storefronts using shopify's new tool called hydrogen. We'll kind of get some hands-on coding today, but I'm super excited to be sharing this workshop with you because it's kind of the latest and greatest from shopify and react. But first, before we kind of dive right in, let's do some introductions. I'm Megan. You can find me on Discord, Twitter, YouTube. I'm a dev advocate here at shopify, so I'm pretty active in the community, so feel free to say hi if you kind of see me around. Mostly my team focuses on kind of bringing you guys to workshops like this one and highlighting some of the other cool things that shopify is doing, as well as kind of hearing from you guys and understanding what you're interested in shopify doing and seeing all the cool stuff that the community is building. And I'm Abe. I'm also a developer advocate at shopify. My job is mostly to let Megan do her job and then show up to actually give the talk and act like I did any of the work to prepare for it. Similarly, I float around on various socials. I do have a Twitter account and things like that, but I wouldn't recommend following me because I don't tweet anything interesting. But I'm around. You'll see me pop up in all sorts of different shopify-related resources. And of course, you can always shoot me an email if you have any specific questions or thoughts either about the workshop or anything shopify developer-related in general. Always happy to chat or route your question to someone who has a better answer than I do. Cool. So today we'll be using hydrogen to build a product page. What you'll learn is some major features that hydrogen has developed to help you ship and build fast. And by the end of the workshop, we'll get hands-on. We'll do some coding. You'll check out some of the tools that shopify has developed to help you rapidly build a custom storefront. And hopefully by the end, there'll be some time for Q&A. But if you have any questions, feel free to put them in the chat as we go through and we'll try to tag team and get through them there as well. So let's get into it. Abe, you want to kick us off? Yeah. So for anyone who's not familiar, hydrogen is a framework that shopify recently released. Basically what it is, is a way for you to put a head on top of the headless APIs that shopify offers. When a lot of people see shopify, they think of people who go into our public interface and design a shop using the drag and drop interface and pick a theme from the store, things like that. Just customizing off the shelf e-commerce experiences. But hydrogen is a very different approach. We offer all these APIs that basically let you do everything that we can do with your store, you can do through an api. And then hydrogen lets you build any UI you want on top of that. So we're going to get into it a bit here, but the important parts are it's a react based framework. So it'll be familiar to anyone who's worked with react, but with a bunch of cool helpers and utilities to help building a shopify powered store. e-commerce in general is like super hard. And you'll see here that we've tried to pull together a bunch of utilities and helpers and things that are kind of like the common use cases for building a store. You need like a cart, you need product pages, you need all these different little components, like different versions or variants that we'll talk about. So if you have a product that have different colors or things like that, all of this is pretty generic to e-commerce. And this is kind of the problem hydrogen is hoping to solve. Simplify the problem, make building an e-commerce store easier, but still give you the absolute maximum amount of power you can need to do whatever crazy type of store you want to do. Yeah. So as Abe was just saying, hydrogen is built to power personalized dynamic commerce sites. And to do this, we have three separate strategies that kind of work together. They are react server components, streaming server-side rendering, which for me is a mouthful. So if I start slurring that, I apologize. That's what I mean streaming server-side rendering. And the final one is flexible cash policies. Let's talk details about each of these. So react server components. Maybe you heard about this with react 18. It's prominently featured in hydrogen and it's like kind of the new up and coming react topic. It's not the same as server side rendering. I know it's like a little bit confusing. I actually thought they were the same thing for a while until I started digging into hydrogen and how we make use of it. But server components allow both the server and the client, meaning the browser, to collaborate together when rendering your react application. So if you think about your typical react application, this is like an element tree of react components that are including more react components and it's all kind of loaded and done on the browser side. react server components make it possible for some of those components in the tree instead to be rendered by the server. And then you can push off some of the work to the server side and still have some client rendered components by the browser. This has a couple of advantages. The first one is, of course, your server has more direct access to your data sources. So things like your database, graphql endpoints, or even your file system, things like that. The server can directly fetch the data that you need and it doesn't have to go through an api endpoint like your client side would normally have to. So this makes your app faster and also more secure because you don't have to go through that api layer. And if you have a lot of heavy code modules, so maybe, for example, you have an expensive date formatting library or something like that, you can use that on your server component. So that means the library that you're using that might be a little big and bloated stays on your server, doesn't ever need to be transferred to your client. So you reduce your overall bundle size and also help the speediness of the loading. One thing to understand while we're kind of talking about this topic is server components, like we said, can fetch data and access the system or maybe your file system, but you cannot store state or have any context in these components. So if you need access to state or context or anything like that, that's when you would have to bring in a client component because that work is obviously done on the browser. This next topic that we have included, the streaming server-side rendering. Server-side rendering is not itself a new component, but in react 18, there's a new ssr api powered by Suspense. And this really kind of unlocks a lot of cool features for server-side rendering. So it eliminates data fetching waterfalls. So if you think of the old kind of way, waterfall is where each request, you have to wait for the prior one to complete before you can kick off the next one. If you use the streaming ssr and Suspense architecture, you can kind of chunk up and tuck away a lot of those data fetches in your server-rendered application without having to use the waterfall or without having to wait for the waterfall. This gives you really fast first byte on your client side. So your shell can render. react 18 starts streaming your html to the browser. While this happens, your data in the background is being fetched. So you can have various load states for each of your different components. Whereas prior to this, you had to either render everything on the server, which is the waterfall way. It's a very slow time to first byte. Or before we introduce this architecture, you would have to kind of do everything on the client, which maybe that was fast time to first byte, but it introduced a lot of back and forth between your client and your server. You had to fetch everything in different requests. This strategy helps us kind of eliminate both of those problems. And finally, with ssr, we have progressive hydration. So this is a streamed response that comes to the client. This means that you don't have to wait for all of your requests to be resolved, like we mentioned, and each component can be rendered at a different time. So for example, a buy button can be interactive and loaded on the page before maybe your product reviews load if those are taking a little longer. And the last thing that we're going to talk about is flexible cash policies. So hydrogen ships with some clever caching mechanisms. You can either cache entire pages or even down to individual requests. So if you think about an overall e-commerce product page, this probably needs multiple requests to get all the information that you need. Maybe product details, product reviews, maybe you're pulling in social media or something like that. You can cache each of those requests individually as you see fit. So maybe you want the product details to say super fresh, so you only cache those for one minute, whereas maybe you don't get product reviews that often, so you could stretch out that cash for that specific call a little bit longer. And if you have a page that doesn't change often at all, so think like blog post about us, contact us, anything that's a little bit more static, you can cache that entire page if you want to using some of our hydrogen built-in policies. And the last thing on this point is we have also included a Stalewell revalidate option, which this means you can return the stale data immediately so the client doesn't have to wait for an api call to finish. And then in the background, you can asynchronously regenerate the fresh data and reload the page once it's done. So that way you kind of get the balance of speed where your page loads right away. And then in the background, you get that freshness covered as well. So not only have we made hydrogen fast for your clients, so for the customers who are loading your hydrogen sites, we've also tried to make hydrogen development fast for developers. We kind of included some foundational tech stack pieces and have provided some quick start guides so that you can get started fast and get building right away. We've also included some specific components like hooks and utilities and things that work really well with react so that you don't have to kind of reinvent the wheel every time. We've covered some of those common use cases for you as well. All right, let's do some coding. Let me do a very smooth transition here over to our doc of steps. I'll go ahead and share this link in the chat. And if we can mirror that over to the Discord, that would be great. So this doc is pretty much what we're going to go through. It should have links to everything, all the code snippets you need. You can follow along as we will talk through it and everything. But this is pretty much a standalone tutorial. You could just read and do yourself. But we'll be going through here and walking through it for the rest of the workshop. But feel free to come back to this later, Bookmark, whatever. It's not going anywhere. So like we talked about at the beginning of this workshop, we're basically going to go and build up a very simple custom storefront. We're going to use hydrogen, our react-based framework. We're going to build a head for the headless APIs. That's all things we've already said. The important parts for what you actually need if you want to follow along and not just listen is this SymChrome-based browser, Chromium-based browser, which we all probably have. And then this little link down here to the actual StackBlitz project. There is also a version, a newer version, that has some change dependencies and stuff. We're just going to work off of this one right here. You can try the newer version, but you might hit some things. As we were talking about right before this call, things have been changing very quickly with hydrogen in the last hours and days. So we pinned our versions just to make sure that they're working. And then we're going to go ahead and our versions just to make sure things are exactly as we would hope with minimal room for error. But there is always a chance that something will get updated that we didn't hear was coming down the pipeline. So yeah, if you want to follow along, this one is the safe one to use. So let's head over. We can click that open. You'll see it'll go ahead and spin up an environment for us. We have our little web browser over here. If you haven't used StackBlitz before, the gist is that it's a very nice way to just get everything running in the browser really quickly. So we've already pulled down a little boilerplate piece of code over here. We've got our code here, our terminal down here, and then our program running right over here. You can open this out into a new window. You can open this browser tab out into a new window, which is nice if you want to check network requests and things like that. We won't really be doing that, but just if you need more space, you can hit that button up there. I'll go ahead and pop this out just so I don't keep skipping back and forth for y'all. There you go. Cool. And I was just typing an answer in the chat, but I'll just say it verbally. typescript support is something that the hydrogen team gets asked about a lot. I believe the idea is that we'll go to GA with just javascript and then quickly follow with some typescript support as well. So good question. I know the team gets asked that quite often. Go ahead. Sorry. I said we all love typescript. Yes, I know. I'm a fan. No, you don't need Ruby on your machine. Unlike some other shopify projects, we're not going to touch Ruby today. Actually, StackBlitz lets you manage all the dependencies and everything in your browser as well, so you don't have to clone anything down locally or have anything set up. And if you do want to go and build off of this in your own time, you'll just need Node and that normal toolchain. We'll cover some next steps at the end for how to get things out of StackBlitz and actually go and build a real thing. But for now, yeah, you don't need anything besides clicking that link in a compatible browser and you can follow along. Cool. So as everyone gets that pulled up, let's start with some of the intro, get familiar with what we have here. The first thing to kind of look at is the hydrogen config.js. This is where we hook up to a hydrogen demo store. So there are api key and I believe it's like the domain. This points back to a demo store that shopify has created for you guys to use and kind of poke around as you're trying out hydrogen for the first time. So that is the file that defines which store is backed by this hydrogen app. And then next is the app server component. So of course, in like any react app, this is kind of the entry point into the application. You can see here that we have suspense included and the shopify provider is wrapped around all of our files. This is just using that config that we just talked about and creating the react context to be able to connect back to the storefront and the background. So a lot of the boilerplate is kind of covered by this template here. And it'll be the same thing if you kind of clone on your own, if you're using like our yard command or anything like that. We've tried to make it pretty easy to just jump in and get started. So like Megan said, there's this kind of router in here and you can kind of guess based on the name. So what hydrogen does is it uses a type of routing called file-based routing, which is basically a way where we map the actual files that are in your source code directory to the URLs that people will be accessing. So it's a very simple kind of like logical way to map what code rewrite to like how it displays on the page. Right now, if we open up our routes folder, the only thing in here is an index.server.jsx and that says it's just a function that returns hello world. And you can see over here, we're on the like slash or homepage of our website and it just says hello world. Now, throughout this, we're going to be seeing a bunch of different files. Some of them will be called index or like something.server.jsx. Some will be called something.client.jsx. And in a hydrogen project in general, sometimes you'll see something, something, just jsx. No client, no server. There are some pretty strict rules here about what those names mean. A server.jsx file is always rendered on the server. Client.jsx is done on the client. And there's some pretty clear splits about like what those two things can access. The important thing is for this tutorial that the client.jsx files can access state. So if you wanted something like selecting a color for a product, that's client side state. So you would need a client side component. And then the server components, the important part for this tutorial is that a new page is a new server component. So if we want to go create a new product page, we need to create a new server component. There's some other fine details about these two types of components and when they can interact. There's a link in the page to more docs about this, but we won't dive too much into it. But the important part here is that if our goal is to make a product page, we need to go make a folder structure that represents what we want our page route to be. So we can go over into routes and we can create a new folder and we can call it products. And that's just hard coding a product just to get going with. So we'll make a new file called example.server.jsx. And if we hop back over to our doc, you'll see we have a little snippet in there that we can copy and paste. And you'll see my cursor copy and pasting it. And all this is, is a bit of, it looks exactly like the index page, which is a hello world, except this one says example product. You notice when I saved that, everything kind of refreshed. There was a little message down here that said we had forked the project. So that might, if you're following along, that might have crashed your server down here. So if you get like, I can't connect kind of a command over here, what you can do is rerun npm install and then yarn. And then you can have your server again. So I just killed it. So you will get unable to connect. So if you get that, just rerun this command. Also it's in the doc. You'll see it. But anyway, so at this point, we have a route that we just set up that's products slash example. And we can go over here and we can change this URL products slash example. And we get our example product exactly as we would expect. And that's all it takes to do a static route. If we wanted to do like an about page or something like that, this would be a great way to do it. You can just create the file and go ahead and put whatever you want, but that doesn't really work if we have thousands of products. So let's talk about dynamic routes. Yeah. So of course, if we have thousands of products, we don't want to just create thousands of pages for each one. So we can update the file name to be able to accept a parameter. And how we do that is just by putting square brackets around the name of the variable that we want to declare. So here we'll call it handle. That means the handle for the product. And now that we have that file name defined, we can actually grab those params from the argument for this component here. And then if we want to use them inside that component, we just pull the handle off that params object. So again, just a reminder, this is javascript, so that the names here matter. That handle that we're pulling out in the curly brackets is the same as the variable name that we've declared in the square brackets of the file name. So now everything is connected. You've got your handle specified in the file name. We're pulling in the params in the component and pulling off the handle from that object. And now when you, when Abe updates the URL, you can see it does pull that param off and it updates the page to show that dynamic name. Easy. Never seen anything more natural or easy in my decades of programming. On top of this, the handle is great, right? So we've grabbed a little bit of information from the URL. You can obviously expand this. You can put multiple fields in the URL, do whatever you want, whatever floats your boat. We're not going to go any deeper on that, but what we do need to do is take that handle that we just pulled out of the URL and do something cool with it. In this case, since, as Megan mentioned, we already have this connected to a demo store, we know we can go and query using that handle to pull product-specific information from our api. However, we don't really know how to do that. We don't have any example api calls in here. You probably never looked at the api documentation. So the api we're going to be using is called the Storefront api. And as the name implies, it represents basically everything about a shopify store. And there's multiple ways to learn about this and figure out what data you can access. One is you can go look on the docs. You can go to, I believe it's hydrogen.shopify.dev, and you can read all you want about all the nitty gritty. Or since it's a graphql-based api, we can go and use that interactive tool that comes with most graphql APIs, and we can go to GraphiQL. So if you want, you can just kind of expand this or do it in a new window. I'm expanding it because if I do it in a new window, I have to flip back and forth. But we can go to slash graph iql. And once you actually build your site, this will be disabled. But since we're in developer mode, it shows up. And if you're not familiar with graphql, that's okay. I'm no graphql expert either. So don't stress too much. The important part is that this is a really cool interface that lets us test a query against that Storefront api and see what we get back. So the simplest query we can get going is this one that's in the doc, which is just a query for the shop name. So we'll paste that in. Again, you don't have to be an expert at the syntax. We'll explain what you need. So don't stress. But basically, we're going, we're looking at the shop object, and we're grabbing the name off of it. So we can hit run. And we realize that our shop name is Snowdevil. And that's configured in the shopify admin panel back on the dashboard for the person who's actually maintaining this site. This is cool. But the really valuable part about GraphiQL is that we can figure out more about the api and we can learn about it. So if you hit new line, and then you go and do like a control space, it brings up the auto completion. So we get a whole bunch of other fields here that we might want to pull down. So if we wanted to, for example, grab like the, I don't know, grab the store description. That's a good one. We can now run that. And we get back the description of our store, which is a custom storefront powered by Hydro. And that's super duper easy. Obviously, there's a ton of other information here. This is just like one category, the shop info, but we can also query for products. So let's go ahead and pull out a product. And this query, there's a link in the docs to this query. Sorry, I just lost my window. There's a link to the docs and you can find this query and you can go and actually like dig through. There's a ton of example queries on shopify.gov, because we know not everyone's a graphql expert, but I'll copy and paste this one in here. And basically what we're saying is we want to look at the products. We want to grab the first 10 products, edges nodes, ignore those words in their graphql crap. And then we want the ID and the handle for that product. The ID is a shopify internal ID. They tend to look pretty crazy. And then the handle is just like a human readable ID. And notice we also are using the word handle in our page. So that's what we're going to end up linking and querying on. So let's run this query. And we're just getting back here a list of 10 products. You can see each product kind of looks like this. We have, you know, the node and then we have an ID and a handle, a node ID and a handle. So you can see we have a bunch of weird named stuff, a bunch of different snowboards, different things, the oxygen, mail it freestyle, snowboard, whatever. We can just go with the top level, like most generic handle, snowboard. And we can use this for the rest of the tutorial as just kind of a backbone for doing our queries. The product page will build up. We'll be querying for this snowboard product. And you can do that. So we're right here. We're just getting a list. We're getting a list of the first 10, but we can change this query pretty easily to allow us to query for a specific product instead of just the list. And that query is again in the doc and in the tutorial. So you'll notice we change it from, you know, I'll actually paste this right after it so you can see it. We go from querying products plural and putting some, and asking for the first 10 to querying a single product that has a handle snowboard. So we'll drop that off, run this, and now we'll get just one product back. And again, just like we did before, you can hit control space. You can see what other information is on here. We can grab the description. We can rerun that. We can grab whatever other useful stuff is in here. And a lot of this gets pretty deep. Like we can grab images. And under images, there's another set of edges and nodes. And so those have like URLs. And we can go, and we can go, and you can grab all this stuff. We'll talk about this a little bit more in a minute. Oops, I messed that up, but ignore my bad graphql. But the point is you can get very deep with this because of how graphql works. We don't want to go too far into it. We will be using some advanced queries in a little bit. But like I said, it's not terribly important you understand it, because hydrogen will tell you if you get something wrong. If you're missing data that it needs, it'll let you know. And we'll see that in a bit. But anyway, we can now take that and we can query for a specific handled item. We're querying for a snowboard, which would be fine. But again, this is a dynamic page. We're not always going to want to pull forward just the snowboard. So we can change this query one more time. And we can actually make it a query that can take a variable. So again, I'll paste it right below so we can see. We're changing the type of query definition, I suppose we would call it, and setting it up to take a dollar sign handle variable. And then we're passing that handle down into our query. So that'll just let us pass in whatever string we want to be able to query for that product. So whatever is in our URL, we'll pass in as an argument. You can't really see it here. But down here, there's this little query variables thing that if you're very careful, you can actually drag it up. And this is a little area that takes some JSON that fulfills the variables of the query we have up top. And again, it's really smart, which is cool. So I can start typing, and it'll say, oh, you obviously need to supply us the variable handle because it's defined in our query. And here we can type snowboard. And we can run that. And it looks exactly the same, except I took out description, but it looks exactly the same. We can change that now to the oxygen or whatever. If we query for a product that doesn't exist, it just gives back null. So this is us now having a hard coded query that we can then pass in a dynamic variable to. So with that, we can then take that and actually put it in the product page. Yeah, so in our product page, hydrogen comes with a use shop query hook, which essentially we can take the query that we just wrote in the graphical and translate it to our react code to essentially do the same thing that we were just trying out. So to try this, let's first import the use shop query hook and the graphql tag library. And I just want to point out here that the graphical and this graphql tag library are pretty common if you're comfortable working with graphql applications elsewhere. This isn't specific to hydrogen. The use shop query is obviously specific, but if you're comfortable with graphql, this should all look pretty familiar. And if you're like, oh my gosh, I don't know what is happening. A lot of this stuff is just some basic graphql. So you can learn more about that in like graphql specific resources, not so much shopify. Okay, so using that use shop query hook, we can paste in that same query that we just had in the graphical on the left. Here, we're just using that shop query hook. It accepts two items, the query, which is the same query that we just had, and then the variables, which are the same as the variables that we saw in the query variables at the bottom. And that const data is just going to take the data back. Once that hook has completed, we store it in a data object. And yeah, essentially, we've just kind of copied from the graphical and translated it to our react code. If we check out the products slash example page, that is going to execute this hook now. And you can see because in the URL, it is example, we know that's not actually a valid product handle. So we're getting a null back in the server terminal. If we update the URL to something that we know exists, like that snowboard that we just saw before, we should be able to get both the ID and the title logged in the server terminal there. So essentially, same thing that we were doing before, we had it working in the graphical, now we've just translated it down to our react component. One thing to do while we're kind of in this area is we're going to extract out that graphql query. Queries can get pretty large and unwieldy and spoiler alert, they will for us when we get to more product information. So we're just going to extract it to a variable and stick at the bottom of the page so it's kind of out of our way. Nice. So now that we have some data being queried, we're pulling something from the URL, we have some data being queried, we're not really doing anything with the data, but we do have it. This is where we can start getting into client side components and things that are actually like more interesting on the page. So in this specific case, we're going to make just like a product details component, and then we're going to go ahead and use this thing called a product options provider, which is basically a way for us to pass down the context of the product we're looking at, which the server provides to product details, and then enable it to be used through the use product options hook, which a bunch of hydrogen components use, but then we can also create custom components, which use product options, and then it handles a bunch of stuff automatically, variants and things like that, which we'll talk about in a moment. But for now, we can just go ahead and create this client side component. In real life, you might want to make like a source components folder for your client side component. We're just going to put it right next to the page, just to keep it simple. But if you look at some of the other examples, you see they're a little bit organized. I might sneeze, and I apologize for that. I can feel it. It's an inch away. Wait for it. Nope, no sneeze. All right, so we're going to put in a product detail dot client dot JSX. And remember, dot client means this is going to actually render on the client, so we can do things like have state. And then we'll go here and say, function product details, it's going to take a prop that is a product. And we're just going to render out basically the same thing. It's a slightly different wording, but it's the same result that we're currently rendering out. So we'll go here, and we'll change this from just a p tag to go in and say product details. Details. And we'll close that out. But if we run this now, it's going to break because we need to pass it in that product. So we can say product equals data. And there we go. And did I mess that up? Product equals data, product, product. Whoops, oh no. Project page four, product dot title. I think the prop is data dot product from the source component. You're correct, you're correct. That's what I get for thinking I've seen this code enough to get it without looking at the doc. Anyway, so there you go. So you can see it's now rendering properly. And the important distinction here is that now that we're doing this product details, we're using this client component, that means we can do interactive things. So let me look back to our doc real quick. So we have this product option provider that I mentioned earlier. And it's one of the ways we can display product details on the page. We don't have to use it. There are some options. So for example, right now, we're already displaying product information. We're displaying the title. But this other component is a lot richer and allows us to do a lot cooler stuff. So I'm just going to copy and paste again from my little workshop doc. And it looked like it changed a lot, but it really didn't. We still have our product title here. And then we just add in this new product options provider component. And we pass that the data and that data is the product. So what we're saying here is the server actually requests the data, passes to product details. Then on the client, we set up this product options provider and we give that product. And now that product options provider gives that context to anyone who wants to use the use product options hook down the road, whether it be a built-in component in hydrogen or something specific we read. So we can save this and it's not going to go very well for us because it says product option providers require product.variance.node. In other words, the product data that we're providing is not complete. And it's not complete because the query we're using down here is just that little test query. It doesn't actually have enough information to qualify itself as a whole product in the product options provider context. So you'll see in the doc, we have two things linked. We have both the actual page on shopify.dev, but we also have just a link to a gist under the text of this larger query. And when you click on it, you will find it is in fact a larger query. It is a much larger query and we can replace all of this. And it gets real big. It's a whole bunch of graphql. It's a whole bunch of crap. It's a very productive way to code because we jump from having like 10 lines of code to having 300. All of this is not really that important for you to understand. There's a reason this is in the docs. It's a reason it's linked because you don't have to have all the information about all the details here. The only thing you might care about is there's things like how many images to fetch here. So you could like change that or, you know, different little fields if you're like, oh, I really only want three images to get pulled down. I don't need 10 or whatever. But for our case, all those variables are hard coded. The only thing this query is expecting, just like the other one, is that handle variable. And then it goes and fetches it. And you'll notice that when I saved this and I replaced this query from our old simpler one, the page re-rendered, it's still not doing anything different, but at least it re-rendered and it doesn't throw in air anymore. So we're at a point where that provider is saying, yeah, you're giving me enough information that I'm not actively upset with you. So that's cool. But there's one more thing we want to talk about before we really get into use product options too much, which is that there are still some components which hydrogen provides for accessing details on this product, now that it's a complete product object, that don't necessarily use use product options or things that don't change between variants and don't need that context. So the first one of those I want to talk about is just as like, well, actually, let me take a step back. There's kind of three types of ways to access data off of your product for image. The first one is what we're already doing. And you can see over here where we just access the data directly. Then the second one is using product options and using it to use that use product options hook. And then the third is to do these other components that, like I said, exist outside of the use product options, but still expect a full product. So one of those is product price. So we can import that and product price looks a lot like the other ones. It takes data, which is a product. And this literally just goes and pulls out the price. It does exactly what you would expect. Oh, it's also worth noting, because we changed that query to be so much bigger, this console log is now spinning out a ton of stuff down here. So this is like the entire product option that we're passing around. So that's another way we know that we're getting a more rich object back. But anyway, so that's the second option is to just do this like product price, pass it in data and get that to this place. There's a bunch of those built in product, different fields and stuff, just so you can easily do that without having to know exactly what field you're looking for. Then the other option is to do like other hydrogen components that use use product hooks or use custom components that use use product hook yourself. So let's talk about using custom components and actually go and like create some using this product options provided and do some fun stuff there. Yeah, so we're going to create a custom component. For us today, I think a cool use case would be maybe creating a product image component. So you can see in the doc that we've kind of scaffold out some product image. It's just using an image tag that's also built into hydrogen. But you can see at the first line there inside the component, we're using that use product options hook that we've been talking about so much. So we have the context set up. Now we can access that context using this hook. And what we're going to pull out of that hook is what we're calling the selected variant, the selected variant object. If you were to dig into that console log, you could see a thing called selected variant, and you would then see inside that object, it has something, an image in it. So that's what we're doing there on line 26, digging into the selected variant and pulling off the image from there. And this is all already set up for us because we have the provider configured and we already queried all that data on the server side. So we don't have to do much else here besides just include the product image itself. And if you're familiar with react context at all, you know that you have to wrap the provider around the children that need the context. So we're going to add it there. And yeah, we're missing an import for that use product options hook. So there on the page, pretty simply now you can see the image for the selected variant displayed on the page. We didn't have to do anything too crazy or fancy. And that's because that use product option hook is just pulling the selected variant and image from the provider that we've already set up prior to this. To make this a little bit more interesting, we can use this context to do something that's a little bit more fun. So the purpose of this context is to be able to keep track of things like the selected variant. So variants are kind of a concept in shopify stores, products have variants, right? So maybe think like different sizes, different colors. In our case, these snowboards have different sizes and colors. So we can print out the different options that are available to us in this component that I've grabbed from the docs, just product options. It's not doing anything too complicated here. This is just basic react, again, pulling the selected variant and list of variants out from that hook. The use product options, which again is just set up in context for us, mapping over it, displaying it on the page in a select, also known as a dropdown. And then the interesting part here is that as you change the selected item in the dropdown, we'll call the set selected variant callback, which again is just coming from that used product options hook. This is all defined by hydrogen. We don't have to do anything fancy here. And we pass in the variant that matches the item that we've selected from the dropdown. Again, in order to see this, we just need to include it in our page at the top, again, with the inside the provider. So we have access to that context. And now you can see that this select dropdown is there and it has all the different variant options for us. And when you switch the item from the dropdown, because it's connected to that same context and we're using that use options hook to set the selected variant, the image, the product image itself updates automatically because it's all hooked up to the same context. We didn't have to do any extra code. We're just relying on the state of the selected variant to be able to update that image pretty dynamically. I just happened to see someone in a comment ask if there was a way to not do these incredibly long graphql queries. And it's funny that you mention that because that is, Megan knows exactly, but I know it's something that is either coming soon or has came this week. Yes, the answer is if it's not possible right now, it will very soon be possible to not have to stress about these huge things. Because we know it's a bit much. Yeah, definitely. And even when we were making this tutorial yesterday, I was like, oh man, this is not great. So I was kind of chatting with the team and they're like, yeah, we know we really should provide some examples of what exactly this use product hook needs and provide a query for that. Because right now we're just getting the whole kitchen sink, which totally is not necessary for every use case. So coming soon, we'll improve these queries and make this a little better for you guys. Yeah, it also it kind of defeats the point of having this query language that lets you be hyper specific about what you request. And then we're just like, yeah, just grab everything. But it's getting it's getting worked out. So the last thing we want to do before we take like a quick like five minute break is do use actually another provider that we haven't talked about yet, which is the add to the card provider. So like I said at the beginning, there's a bunch of concepts that kind of every ecommerce store has one of those as a cart, right, like you have to be able to go and actually, you know, add things to a cart to then eventually check out and do things like that. So we're going to use the cart provider, and then we're going to add an add to cart button. Now we don't have time today to actually go into like making a UI to see everything in the cart and like removing what's in the cart. So that's going to be kind of left up to an exercise for y'all. But it's going to use this cool use cart hook and you can go and dig into the docs and set it up. It's just as simple as, you know, showing variants or doing anything like that. But let's go ahead and add this button. So we can add the cart provider in here, and it doesn't need cart provider. It doesn't actually need anything special. It doesn't need any arguments or anything. You can close that out. Again, we'll save it and it just doesn't do anything. And then the other thing we want to do is get this add to cart button. And we can go down here and say add to cart button. And we'll just say add to cart and close that out. And you can see it appears over here. I'll put another break because I'm a designer. Look at that. So we can hit this button now. And you'll see it kind of goes like, it kind of goes like, like it delays. It's clearly doing something. And I promise you, it is doing something. But we can't see it because we're not displaying anything. But that data is there and the product is being added to the cart. Like I said, we'll kind of leave that up to an exercise. One of the funny things is a complete tangent that I actually saw was because there's features in Chrome that remind people if they've forgotten to go and like finish a checkout process, you might see when you open a new Chrome tab in that like blank screen and it'll be like, hey, you left a snowboard in your cart. And that's actually because this is all automatically integrating not only with shopify, but with like best standards for e-commerce like across the board, which is super cool. Even though, you know, the snowboard we're buying is like a weird JPEG of a made up snowboard. Chrome doesn't know that. But yeah, so that's all we had to do to actually add it to the cart. Like I said, you can go and do more there if you'd like. We're going to take a break now. And I think, yeah, I think that's all we want to cover about the cart provider. Yeah, so we'll take a few minute break. If you are so inclined during this break, you can try to implement a feature where the add to cart button would be disabled if the selected variant is out of stock. So we gave you the doc, which will of course have the code solution, but maybe a challenge to not take a look at that and use a couple minutes to try and set up some functionality to disable that add to cart button. Yeah, if the thing was not available. Yeah, and that's also a good time to just try to catch up if you've fallen behind at any point, because we only have about one more segment after we come back. So try to catch up if you have questions or concerns or anything like that. We'll have room for questions at the end. But yeah, you can either poke around or take a break or whatever. I'm going to go blow my nose. So I'll be back in just a moment. So I'm hoping everybody is kind of making their way back from the break. As I said, we've provided the doc. So this code solution is already there. But it's you can see it's pretty simple to kind of do the logic to disable this cart button. For the purpose of this workshop, we're just going to add another component to this same file that we've kind of been working in. We'll call this the add to cart markup. Again, we're just using this use product or use product options hook to grab that same selected variant. This is the same one that we've been using in our other components. And inside that selected variant object is an attribute called available for sale. So just like we can pull the image out of that graphql query with that huge data object that we were looking at, there's also a flag in there called available for sale. And we can then use that to just create some logic to either disable or not disable the add to cart button based on that field. So pretty simple there, again, to just pull some information from that hook. And that's really kind of what we wanted to communicate with this workshop is hydrogen provides you a lot of these really nice to have utilities and sets up does the hard work of like setting up context and keeping track of state and things like that for you. So you can focus on developing your things that make your shop unique. Like our great styling. Yes, everyone's going to want to use this site for sure. I was going to get a snowboard, like the local store. But when I saw that white website with the Ariel font, I was like, oh, you got it. So the last thing we wanted to talk about before we wrap up and take any questions is just to kind of remind folks that like, although hydrogen is obviously very shopify specific, it's tied very closely into our ecosystem. It doesn't mean you can't do other things. If you wanted to, you could build out all sorts of custom APIs here. You could do whatever type of interesting additional services you need. So just real quick, I just wanted to show how to make your own api on top of hydrogen that you can then go do whatever with. And it's super duper simple. All we have to do is go into our routes, add a new file. We'll just call it api.server.jsx. And then the code again is in the doc, just like everything else. And we can just set it up to return a little bit of JSON. And if we go over here, we change our URL. Whoops, that's not what I called it. api. There you go. We got JSON back. And you can do any normal JavaScripty type scripty kind of magic you want to do in here. And yeah, it's very straightforward. One of the things we didn't really get a chance to talk about that we mentioned in the beginning is just some of the really advanced caching options that exist within hydrogen. You can do caching on a bunch of different levels. I'm not going to actually show the code here because it's on the doc and I want to stay in alignment with what we have written down. But you can go and cache an entire request. So we could make this, for example, cache for a minute or an hour or whatever. But you can also go into just about any of the hook or the query calls, I should say, and you can cache those. So I think it's just called cache. Yeah. So you can basically cache any call you make to shopify to make that faster. You can cache different elements of the page differently if you want to. So like Megan was talking about where you're pulling data from reviews and you're pulling data from the shop and all of these things. We do a really good job of helping you make a performance service and really get control over every element of how things are cached and served. And hopefully at the end of the day, you'll end up with a really performant website because that's a big part of the goal of hydrogen is to let merchants who are very focused on customization and performance and milliseconds matter kind of vibes really get as much control as they could possibly want in order to build out whatever cool storefront they want to make. So with that, we can kind of open it up to questions. Is there any other closing notes you want to make, Megan? The only thing maybe before we jump into questions is we would love if you all that attended the workshop today wanted to kind of follow up with a code challenge. We implemented that add to cart button and we updated some of the logic there to either display or enable or not enable it. But we didn't get a chance in this workshop to create a UI element that actually showed the cart. So for those that are in this workshop today, if you want to kind of take that home, build some client component or some UI to show items that are in the cart, we would love to see it. So if you follow us on Twitter at shopify devs and then you hashtag shopify code intro, you might hear from us once you've kind of completed that extra challenge. But that's it. Ready for questions. And one last little note, we'll go back to the slides just to close this out. Here's the hashtag. Again, it's in the doc as well. If you do want to, you know, continue your hydrogen journey, here are the commands. Just use our basic, you know, create react app kind of vibe where you can make your own hydrogen app or you can go to hydrogen.new that gives a more complete template than what we have in the tutorial we gave you. This one over here has all sorts of once it boots up, you'll see like an account page and everything like that. Once it loads, there you go. So you can see we have a bunch of different options, different products, you know, it's a very complete demo as opposed to ours, which is like the most minimal possible thing. So that's over at the hydrogen.new if you want to fiddle around with that or create something locally, whatever floats your boat. But yeah, any questions, feel free to post them in the chat. Also, just feel free to talk if you want to talk, whatever feels right in your heart. We're happy to do our best. If no one asks any question, I'm going to be sad. We need at least one question. Yeah, I have a question. Does hydrogen provide some non-hooks utility function to fetch the api so that we can use hydrogen in our framework, like Next, so we can use a fetching function and get some side props or in the loader function of remix. Great question. Megan, do you know? I think that because we rely on that hydrogen config to point back to a specific domain, it might be possible to kind of pull in some of this to a different framework. I haven't seen anybody try that out yet. Again, this is just in developer preview, so maybe in the future we'll kind of allow the ability to use this in some other ways. But yeah, I'm not sure I've seen that or if it's possible. So far, we're really just kind of relying on the react ecosystem, especially because react 18 is the one that supports the server-side rendering. It's also worth noting that, like Megan said, we're in developer preview. This whole thing is still an early project, so if you do see things like that that are important to you that seem out of alignment with what we're doing, like file something on GitHub, reach out to us on Twitter, because that feedback can definitely go back and make a difference in the product. Totally, yeah. Okay, thank you. Yeah, thank you. Thanks for coming. Any other questions, concerns? What can people do with the outcome? You can become a millionaire. You can sell. You can thrive. So somebody asked, what can people do with the outcome? The answer is you can take your app, you can host it, and take it as far as you want. That's one of the really cool things with hydrogen versus shopify's normal offering, which can be a bit limiting as your company grows or if you're working for someone like Kylie Cosmetics or some large store. You can really scale this up to be huge, and that's the goal of hydrogen is that there isn't a ceiling of how far it can go, and it's something that as the framework matures, we want to recommend to our biggest, most demanding merchants. So yeah, you can do a lot. Yeah, I think just to add to that, some of the feedback that we've heard in general with the shopify ecosystem and definitely when shopify started, it was meant for entrepreneur, mom, and pop type smaller use cases, and that's all well and good. It's a really great site. People find it easy to get started and things like that, but we were a little bit struggling with larger use cases. So even B2B or Apeside, Kylie Cosmetics, stores that have large sales and need to handle a lot of traffic, that's where hydrogen fits in to the ecosystem. So becoming like a hydrogen developer opens the door to move away from mom and pop type development and work on larger, more complicated stores and clients that need more customization. I have another question. There was another workshop about shopify three days ago. I didn't have a chance to attend to it, but it was building a shopify app with react and Node. Can you explain what is the difference between this way they explain the hydrogen? Yeah, so hydrogen is kind of like I was mentioning, a different use case almost altogether. So if you were building a hydrogen store, you would use shopify kind of in the backend and you would create your own UI. I'm sorry, in the backend meaning like you would use shopify as your source of truth, your database, you'd configure your products there in the UI and everything like that, and you'd access it through the APIs like we were talking about today in our hydrogen workshop. Whereas earlier this week, the Node workshop, which I also ran, is for if you're using shopify kind of end to end. So if you are in the use case of maybe an entrepreneur shop, a local kind of store like that, there are still extension points that shopify provides within the shopify ecosystem if you're using it back a house and as the front end, that we allow apps to be able to kind of build in that ecosystem. So instead of creating a full new front end that you would host and customers would interact with like you would with hydrogen, building an app would be kind of in the backend of shopify for the actual owner of the store. We call them the merchants. They have their own specific needs that we as shopify don't build into our backend, which is where app developers come in. So maybe a use case is like you need some special type of fulfillment flow. A app developer can go in to the shopify kind of backend, create a fulfillment app to customize the fulfillment flow for a merchant, and then plug it into shopify in the backend. So you can use similar tools like Node and react. We have a component library called Polaris that's built with react, but where those apps live is very different. So if you're handling back of house, kind of maybe more nuts and bolts of the business, that's where the apps that we talked about earlier this week would come in, whereas hydrogen is very much like the person who's making the purchase focused, so building the front end for the backend of shopify. Does that make sense? Yeah, totally. Thank you. It's also worth noting if you're an entrepreneurial-minded person who isn't running an e-commerce store, there's a lot of interesting opportunities building apps for shopify. Just like an iPhone or any other app store, shopify has an ecosystem of third-party developers who build and sell tools and interesting additions to our ecosystem through the shopify app store. I don't know the exact number offhand, but hundreds of millions of dollars of revenue that gets paid out to third parties who are building apps that our merchants then use. So it's a really interesting space, and Megan's workshop goes through touching into that. And then we also have, again, I'm assuming you've never heard of the shopify ecosystem, put any effort into reading about it, but the theme space is also super interesting. There's a whole ecosystem of people who build and sell themes, just like html. We use a custom templating language called Liquid, but they make themes and sell them to people who make shopify stores. And there's a whole series of businesses around people doing that. So there's a lot of different interesting technical ways you can engage with the shopify e-commerce ecosystem. This is one, apps is one, themes is one. And yeah, it's really cool. There's a lot of fun ways to be involved. So an app is like a wordpress plugin? Basically, yeah. Okay. Okay. Thank you. This is my cat, Chonky. Question in the chat, Polaris is largely centered around shopify apps. Yeah. So Polaris is a design system for shopify apps. You would not use Polaris to show anything to the purchasing customer. So the people who interact with Polaris are the merchants on the backend inside your shopify admin page. Polaris is not meant to be used on your front end for people who are trying to buy the products. Yeah. And for what it's worth, we have two implementations of Polaris we use internally that the entire shopify dashboard is built out of. So if you go and use those components, your app and extension are going to feel exactly natural in our dashboard and control panels and stuff like that. And you don't have to be a designer, which as an engineer, I appreciate. As you can see from our demo today, we're not the most designer minded. Can hydrogen hooks and components be used in next.js? I think the answer is no, or we don't know. Yeah, I think that is the question that we were kind of talking about at the beginning. So my answer is that, yeah, I actually don't know. I haven't seen anyone do this. My inkling is probably not just due to it kind of being reliant on some of the things that react comes with, but maybe you could put next.js in there too. I don't know. I just haven't seen it. Sorry. It's open source, so anything's possible. I think the main intent is that your entire app is built with hydrogen. But like we said earlier, the hydrogen is still early. Are the images optimized like gatsby images or next.js? Oh, that's a great question. I don't know. Abe, do you know? So let me actually look, because I think it is. And I think that's why when we render an image, we use hydrogen's image tag instead of the normal html image tag. So I know that data that comes back on the image is super interesting and much more complicated than you would imagine. So I'll actually just go ahead and log this out and see, because if we see a bunch of different sizes of the image and stuff like that, that'll give us a good hint that the images are all optimized. So let me go ahead and say product slash snowboard. I'm going to go down here. Yeah. So if you look at this image object, it looks like we're only serving up a single size version of it. So in this case, it doesn't look like we're optimizing that much for it. But there might be other stuff here that I'm not familiar with. I would say, I would be amazed if we didn't do some level of optimization there. But I'm not seeing it immediately here. So I don't know. Yeah, I just dug through the docs quickly. It doesn't say anything specifically. It does say it's served from shopify CDN. I don't know. I didn't get any extra details, though, from this doc about what exactly that means. Yeah, it may just be another thing on the list, the nature of a pre-release framework. But obviously, images are low hanging for optimization. So if it's a framework built to be fast, I'm sure that is on the roadmap if not already being implemented. Anything else? Yeah. Does using hydrogen makes it different for fees as an entrepreneur, as a seller, than using the full stack shopify? That's a great question. I do not think it makes any difference on the fees. The only situation that might be different is, I believe, shopify.com. I believe there is a plan that is an api-only plan. Do you know what I'm talking about, Megan? shopify Lite. I'm not sure if shopify Lite has api access. I'm guessing it does. But if there was a big value prop here, it would be by being able to use shopify Lite, which is the version of our plan that is normally just for adding a single buy button onto your website. But I am not 100% sure. I think how I would answer that would be, as a developer, it doesn't make a difference in fees-wise or what shopify would cut from. I think as a merchant, there is a pricing difference if you are going with a custom storefront versus the shopify drag-and-drop WYSIWYG storefront that's available to you out of the box. I think that is the latest answer. Again, things are changing quite rapidly. I find it difficult to keep up with where we land with some of this stuff. But definitely, these are details that will be ironed out by the time we hit global release for sure. Thank you. It is worth noting, you don't get charged for api requests at all. I don't think there's any quota or anything like that. As far as I'm aware, it's not tiered in any way. If you are a shopify store, you get the api. Yeah, I think that's true. It's throttled, obviously. But if you make too many requests at once, it will block you. Is there a timeline for the release? I have not heard what the time frame is. Yes, I do not know. I know we had announced this last... Unite, was it, or something? And the idea was sometime this year. But I don't really have a more specific time frame than that. I will say hydrogen is one of the most important projects to shopify. It is a huge priority with a bunch of engineering behind it. So yeah, even if we don't know the timeline, I can tell you that it is a huge effort that we're working very hard on. I will also take the time now to plug our shopify Discord. If you're really interested in hydrogen and keeping up with all the latest and greatest releases and stuff, they release constantly. Just yesterday, they had a pretty major release. If you join our shopify Discord and then there's a channel called Custom Storefronts, there is a feed of all the latest hydrogen releases with release notes. I believe they keep that up to date with more targeted, this is what we're doing next and this is how we're feeling about a release. I'm just not completely up to date with everything that goes on in that channel because it's such active development. All right, everybody, thanks for the time today. Thanks for coming, asking good questions, paying attention.