Expose Oxygen headers

[davecyen]

Hydrogen should expose the following Oxygen variables so that they can be proxy'ed from client and server components. This would be impactful for internationalization when the Hydrogen app is hosted on Oxygen.

Long-term it'd be nice to have some type of adaptor that could be set in hydrogen.config and passed in server-side, but in the near-term developers could use API routes to parse these via HTTP headers.

 'oxygen-buyer-ip'
 'oxygen-buyer-latitude'
 'oxygen-buyer-longitude'
 'oxygen-buyer-continent'
 'oxygen-buyer-country'
 'oxygen-buyer-region'
 'oxygen-buyer-region-code'
 'oxygen-buyer-city'

[jplhomer]

All incoming Request HTTP headers should be available in HydrogenRequest.headers.get('<name>'), so if these aren't available in Oxygen, it's likely a bug.

[vlucas]

@davecyen Are you proposing we do something more with these headers, like parse them into a structured object? The raw header values themselves should be accessible like Josh commented.

[davecyen]

The raw oxygen headers aren't there (you can see this in chrome dev tools > network on an oxygen deployed site)

[jplhomer]

Ahh gotcha, I think we are talking about two different things:

Oxygen exposes headers on the incoming Request to the Hydrogen server. Developers can act on these headers to do i18n in server components. They can also proxy some of these values to specific client components if needed:

https://yc83jw1q2-9ab02eb2ed45627c8573.myshopify.dev/
https://github.com/Shopify/hydrogen/compare/jl-oxygen-headers-demo

Dave, what you're looking at is the outgoing Response from a Hydrogen storefront. The devs can set those headers on the outgoing response if they want, but I'm having trouble figuring out what we'd use those headers for specifically. Once you're executing in a browser, you can't really access the original response headers to make decisions. Do you think the demo above is sufficient?

Agreed that down the line, it would be good to explore an "adapter" pattern that normalizes these fields based on hosting runtime. We should probably let our eventual i18n utils dictate how and when that happens 👍

[frandiox]

Related to what Josh commented here.
We recently released an experimental feature useRequestContext that can be used to provide the requests headers down the tree:

function App({request}: HydrogenRouteProps) {
  const oxygenHeaderPrefix = 'oxygen-buyer-';
  const context = useRequestContext();
  context.location = {};

  request.headers.forEach(([value, key]) => {
    if (key.startsWith(oxygenHeaderPrefix)) {
      context.location[
        key
          .replace(oxygenHeaderPrefix, '')
          .replace(/-([a-z])/g, (_, char) => char.toUpperCase())
      ] = value;
    }
  });

  return  /* ... */;    
}

Then it can be accessed later anywhere with const {location: {city, regionCode}} = useRequestContext() and so on.