Split `hydrogen-ui` and `hydrogen` about hydrogen-v1

[ryanleichty]

• Any chance of a hydrogen-ui sandbox/demo store being propped up in the near future?

I'm not sure we'll do a full-on demo store, but I do actually plan on spinning up a different framework (Remix probably?) to use as an E2E test for hydrogen-ui, in order to ensure that things work well outside of hydrogen-framework.

A demo of hydrogen-ui with Next.js would be helpful! Currently reading through the docs and looking to build a site with that combo.

[frehner]

Congrats on 1.0 Hydrogen team 🎉

Thanks!

From the handy TODO list here #66 (comment) and the recent PRs from @frehner, I think I have a rough sense of how this effort is evolving.

Understood that the hydrogen + hydrogen-ui split is an ongoing affair, but had a few questions on general direction for this effort that weren't totally clear based on my reading of docs/decisions, PRs and issue threads. Many thanks in advance :)

• Certain functionality of hydrogen which currently seems bound up with Vite/RSC/Oxygen context would be well-suited for Nextjs, Gatsby, CRA or other SPA integration purposes (e.g. shopifyConfig, CSR graphql client calls, cart query/state). Is it anticipated that there will be any provided interface to tap into the non-Vite/Oxygen aspects of hydrogen for such use cases?

Forgive me if I don't completely understand what you're asking here, hopefully I answer it but if not feel free to ask again. But yes, we do hope to be able to pull as much as we can out of hydrogen-framework and into hydrogen-ui, including things like shopifyConfig, etc.

• Somewhat related, is it expected that hydrogen-ui will be completely stripped down presentational components or will they be handling things like cart state, queries and mutations?

The goal is to include things like Cart State, yeah! Things like queries/mutations are hopeful as well, but we're still a little less clear at the moment how to best include these things, and what they look like.

• Any chance of a hydrogen-ui sandbox/demo store being propped up in the near future?

I'm not sure we'll do a full-on demo store, but I do actually plan on spinning up a different framework (Remix probably?) to use as an E2E test for hydrogen-ui, in order to ensure that things work well outside of hydrogen-framework.

[edword]

Congrats on 1.0 Hydrogen team 🎉

From the handy TODO list here Shopify/hydrogen#66 (comment) and the recent PRs from @frehner, I think I have a rough sense of how this effort is evolving.

Understood that the hydrogen + hydrogen-ui split is an ongoing affair, but had a few questions on general direction for this effort that weren't totally clear based on my reading of docs/decisions, PRs and issue threads. Many thanks in advance :)

• Certain functionality of hydrogen which currently seems bound up with Vite/RSC/Oxygen context would be well-suited for Nextjs, Gatsby, CRA or other SPA integration purposes (e.g. shopifyConfig, CSR graphql client calls, cart query/state). Is it anticipated that there will be any provided interface to tap into the non-Vite/Oxygen aspects of hydrogen for such use cases?

• Somewhat related, is it expected that hydrogen-ui will be completely stripped down presentational components or will they be handling things like cart state, queries and mutations?

• Any chance of a hydrogen-ui sandbox/demo store being propped up in the near future?

Cheers!

[edword]

That pretty much answers all my questions, thanks @frehner!

Would be fantastic to see some sort of example non-hydrogen sandbox at some point. If Remix, I'd wager that'd probably be of interest to @wintersieck and followers of #1718

[jplhomer]

when you go to run/install/setup hydrogen, it's actually hydrogen the superset (i.e., framework + components)

The combo of these two (framework + components) will always be pulling from two separate packages. Throughout various files in the project you create (from whatever starter template), you will see references to both the framework package and the components package.

My initial proposal was to use @shopify/hydrogen as the package for components because:

• It's slightly shorter and easier to refer to in all of our docs & examples for using components
• It's likely to be used more than hydrogen-framework since the components can be added elsewhere (Next.js, etc)

But I like your proposal with a slight variation:

• @shopify/hydrogen is the React meta-framework
• @shopify/hydrogen-react is the React SDK (components + hooks)

This obviously leaves the door open for @shopify/hydrogen-vue.

What do you think?

[hi-im-si]

Would be fantastic to see some sort of example non-hydrogen sandbox at some point. If Remix, I'd wager that'd probably be of interest to @wintersieck and followers of #1718

This would be of interest 💯 We are currently using Remix and looking to begin a replatform project to Shopify and the hydrogen-ui would be something we would want to invest in.

[StewPoll]

Hey all, just having a read of this, am mostly interested in the Vue stuff mentioned earlier.

From what I can gather from the comments this is almost done, but a hydrogen-vue framework has not been started on?

[jplhomer]

LFG 🚀 🚀 🚀 🚀 🚀 🚀

[zkoch]

hey, can we actually reverse that to be: hydrogen and hydrogen-components?

and im assuming that when you go to run/install/setup hydrogen, it's actually hydrogen the superset (i.e., framework + components). is that right?

[jplhomer]

The proposal of @shopify/hydrogen + @shopify/hydrogen-react was clear to me till @shopify/hydrogen-vue is in the mix. In the world where @shopify/hydrogen-vue exist, it feels very strange that @shopify/hydrogen is React dependent?

I can see the source of confusion there. However, I'm OK with hydrogen being the reserved namespace for the original "Shopify Hydrogen framework," where React happens to be an implementation detail. I think folks will see their specific language/framework (e.g. vue) and gravitate towards that without wondering too much about what hydrogen proper is.

[jplhomer]

@morganmccunn and I aligned on the following:

• @shopify/hydrogen will be the React meta framework¹
• @shopify/hydrogen-react-sdk will the the React SDK

---

¹ We will investigate exposing the React SDK through the same package as the framework for maximum typability, e.g. @shopify/hydrogen/sdk or just re-exporting its entire contents in the framework package's index.js entrypoint.

[elisenyang]

An experimental version of Hydrogen UI is available at https://github.com/Shopify/hydrogen-ui

[michenly]

The proposal of @shopify/hydrogen + @shopify/hydrogen-react was clear to me till @shopify/hydrogen-vue is in the mix. In the world where @shopify/hydrogen-vue exist, it feels very strange that @shopify/hydrogen is React dependent?

[morganmccunn]

A couple questions/comments:

• I agree with the statement above. If the framework is the foundational piece I agree with calling this @shopify/hydrogen
• However, one concern with ^ is that when someone uses npm init @shopify/hydrogen aren't they are getting both /hydrogen and /hydrogen-react to get the full "playground" ? Perhaps we need to rename this?
• I would think that @shopify/hydrogen-react-sdk is more specific, and potentially less confusing since /hydrogen is also react-specific. I would vote for this over /hydrogen-react. Is the concern with the above simply the length of typing it out?

[jplhomer]

However, one concern with ^ is that when someone uses npm init @shopify/hydrogen aren't they are getting both /hydrogen and /hydrogen-react to get the full "playground" ? Perhaps we need to rename this?

Right. They're getting both hydrogen-react-framework and hydrogen-react. Short of a major rename for the framework part, I think folks are just going to "get" this after it happens. It's tough to envision now, but it makes sense to me as a developer, especially if we add the additional context to what hydrogen-react-sdk is.

Is the concern with the above simply the length of typing it out?

Yeah haha. It's a major bummer typing this out as a developer, especially since it's already namespaced with @shopify/. Typing e.g. next is super super nice when you're working in Next.js, and I wouldn't be opposed to finding a package name someday that doesn't have @shopify/ prefixed, since this needs to be repeated in code examples, tutorials, starter templates — everywhere.

[morganmccunn]

We've agreed to delay this work to post v1.0.0 given that we expect these to be tightly coupled on launch. So while this work is still valuable for future growth, it can be delayed until after official launch!

cc @jplhomer @heimidal @igrigorik @zkoch

[morganmccunn]

Update here: We decided we would separate the SDK and the framework before 1.0.0 to:

• Help folks better understand “what is hydrogen”
• Enable the community to use the parts that are relevant
• Not delay the inevitable (and potentially make it harder for us to do this in the future)

However, I want to be clear that we are building the hydrogen happy path which is framework + SDK together. If we do something that unintentionally breaks integration where perhaps they are only using the SDK, then we it will be on that group to address. Obviously we try to keep disruptions to a minimal as best as possible! :)

cc @elisenyang

[elisenyang]

Update: We've aligned on hydrogen-ui as the name for the package containing the components, hooks, and utilities

[frehner]

As part of the work done in #786 , we got rid of our custom graphql script (because it wasn't working and it wasn't documented).

Having looked into it a bit more, one of the things that script did was to pull the raw GraphQL queries / fragments from the .graphql files and put them into a file (called graphql-constants.ts) where they could be imported as normal strings. With that script removed, however, the graphql-constants.ts file isn't kept up-to-date with the changing queries anymore.

To solve this, we have a couple of options:

1. Finish the work to split hydrogen-ui and hydrogen, in which case we'll start using a real bundler (Vite) instead of TS to compile our code. Once that's done, we can use the Rollup graphql plugin - which coincidentally is already in our hydrogen package anyway. 🤔
2. Remove fragments altogether, which is something still being explored and tracked in #778

[jplhomer]

I thought @michenly just shipped work to export all these fragments from @shopify/hydrogen/fragments instead, which removes the need for a graphql-constants.ts file. Or am I confused?

[frehner]

I thought @michenly just shipped work to export all these fragments from @shopify/hydrogen/fragments instead, which removes the need for a graphql-constants.ts file. Or am I confused?

She's actually importing from the graphql-constants.ts file and having to manually copy over the fragments into that file in order for it to work. (Or using the existing ones in there, that are probably out of date). See #845 as an example

[frehner]

I made a list of things that could be worked on in #1060 , but let me put them here for better visibility:

• #1025
• #1074
• Update hydrogen-ui to SFAPI 2022-07? (Do we keep the components in hydrogen still at 2022-04 and don't change them, and only update things in h-ui to 07?)
• Maybe HMR for h-ui components updating while working on the demo store? Honestly not sure on this one For now, let's skip this.
• CI checks for package size? Maybe. for now, let's skip this
• #1071 this is a framework issue, not a hydrogen-ui issue, so I'm skipping this for now
• Testing:
  • #800
  • #670
  • #313
• Versioning and publishing to npm fully working.
• Maybe make a small Vite/Rollup plugin that ensures that if you're importing something from the index.client.ts entry file, that the imported file is also a .client.[t|j]sx? file? For now, let's skip this
• Add a /shared entry point
• Add typechecking as part of the PR process
• Maybe setup auto-dependency-PRs like Vite does so that we're always up-to-date

[benjaminsehl]

CI checks for package size? Maybe.

@cartogram — going to add this to our linting sprint.

[cartogram]

going to add this to our linting sprint.

@benjaminsehl For storefront code, great idea! I think @frehner is referring to the framework in his point though, and would make sense that we start there. I think most OS frameworks use https://github.com/ai/size-limit

[frehner]

The only work left to consider this done is

• Publishing to NPM
• #1154