DEV Community: Devin Rasmussen

Setup Shopify GraphQL Admin API Client in Hydrogen

Devin Rasmussen — Wed, 15 Jan 2025 20:31:37 +0000

While Shopify's Storefront API is fairly powerful, it does leave some thing to be desired. One use case that we faced was needing to get data about a particular email address (without said email address being authenticated). To my knowledge, it’s impossible to do so without the Admin API.

Get an APP_TOKEN

In order to use the API we’ll need to get a token. The way to generate said token is to create a custom Shopify app. You can do that in Apps and sales channels by clicking “Develop apps”

Or if you know the name of your store, interpolate and use this URL: https://admin.shopify.com/store/{your_store}/settings/apps/development

From "API credentials" we will grab the Admin API access token. Be careful with this token. It gives access to everything. In the “Configuration” tab you’ll need to grant a few scopes. I’d start with the Principle of Least Privilege and go from there.

Add the API client to our Hydrogen Application

First let’s install the Admin Api Client library.

npm install @shopify/admin-api-clien -s

We will leverage this to add a client object to our Remix context that will make Admin Api requests very ergonomic:

// context.ts
export async function createAppLoadContext() {
  const hydrogenContext = createHydrogenContext({})
  return {
    ...hydrogenContext,
    shopifyAdminClient: createAdminApiClient({
      storeDomain: env.PUBLIC_STORE_DOMAIN,
      accessToken: env.SHOPIFY_CUSTOM_APP_TOKEN,
      apiVersion: '2025-10',
    }),
  }
}

Utilizing the client may look something like this:

export const GET_CUSTOMER = `#graphql
  query Customer($id: ID!) {
    customer(id: $id) {
      email
    }
  }
`;

const {data} = await context.shopifyAdminClient.request(GET_CUSTOMER, {
  variables: {id: `gid://shopify/Customer/${id}`},
});

Note: do not try to do this outside of loaders or server context. Remember that the Admin API is omnipotent so we don’t want to leak the key to the client.

What about types for the Admin API Schema?

Hydrogen generates its own types for the Storefront API and Customer Account API using this codegen. We have to do something similar to generate types for the Admin API.

First, install Shopify’s api-codegen-preset.

Then let's create or edit graphqlrc.ts (why graphqlrc.ts?) (note the hydrogen demo uses yml) to include admin types:

import type {IGraphQLConfig} from 'graphql-config';
import {getSchema, preset} from '@shopify/hydrogen-codegen';


import {ApiType, shopifyApiTypes} from '@shopify/api-codegen-preset';


/**
* GraphQL Config
* @see https://the-guild.dev/graphql/config/docs/user/usage
* @type {IGraphQLConfig}
*/
export default {
 projects: {
   ...shopifyApiTypes({
     apiType: ApiType.Admin,
     apiVersion: '2024-10',
     documents: ['./app/graphql/admin/*.{js,ts,jsx,tsx}'],
     outputDir: './types',
   }),


   // putting this second as having it first causes
   // VS Code to use the wrong schema in app/graphql/admin


   storefront: {
     schema: getSchema('storefront'),
     documents: [
       './*.{ts,tsx,js,jsx}',
       './app/**/*.{ts,tsx,js,jsx}',
       '!./app/graphql/**/*.{ts,tsx,js,jsx}',
     ],
   },
 },
} as IGraphQLConfig;

Notice that we’ll have to isolate our Admin graphql in its own directory. i.e.,

export const GET_CUSTOMER = {...}

needs to live at /app/graphql/admin/customer.ts. This discrimination is important because some fields are shared. For example, “customer” exists in both Admin API and Storefront API but has different attributes/parameters. If the types are generated for the latter, you’ll be confused trying to work with GET_CUSTOMER as the Storefront API expects a customerAccessToken parameter while the Admin API expects an ID.

Ensure codegen is triggered in your scripts:

"scripts": {
  "build": "shopify hydrogen build --codegen",
  "dev": "shopify hydrogen dev --codegen --host",
}

After adding our GET_CUSTOMER export to customer.ts, let’s trigger the codegen (npm run dev). We should see a new file types/admin.generated.d.ts which will contain a number of ClientQuery type exports as well as the declared module @shopify/admin-api-client

Now try out the shopfiyAdminClient

export const loader = async ({request, context}: LoaderFunctionArgs) => {
 const id = 123;


 const {data} = await context.shopifyAdminClient.request(GET_CUSTOMER, {
   variables: {id: `gid://shopify/Customer/${id}`},
 });

If all is working according to plan, you should have VS Code's autocomplete showing customer

If you have further questions or need help with Hydrogen or Shopify, hit us up at EM marketing. We have an array of experts in Shopify Hydrogen.

Create a navbar with gradient

Devin Rasmussen — Fri, 26 Jan 2024 05:38:01 +0000

TL;DR codepen

I was hanging out at fly.io and noticed this sweet top navigation bar

so I had to machete through all the tailwind to replicate.

First we pick three colors: lightskyblue rebeccapurple sandybrown

Let's introduce a nav with a height

<nav>
</nav>

nav {
  height: 80px;

Now let's introduce the gradient from top left to bottom right

nav {
  background: 
    linear-gradient(to bottom right 
      lightskyblue rebeccapurple sandybrown
    );
}

We need to reduce the opacity on lightskyblue and sandybrown so let's get their HSL using shift click like so

With reduced opacity (0.25), our code may look something like

nav {
  background: linear-gradient(
    to bottom right,
    hsla(203, 92%, 75.5%, 0.25),
    rebeccapurple,
    hsla(27.6, 87.1%, 66.7%, 0.25)
  );
}

Now let's add a background to the whole thing

nav {
  background-color: rebeccapurple;
}

I didn't love this so I went ahead and abstracted the rebeccapurple to HSL so I could darken it significantly (lightness in HSL from 40 to 15). It's in a CSS variable because we'll use it twice.

nav {
/* --rebecca-purple: hsl(270, 50%, 40%); */
  --rebecca-purple: hsl(270, 60%, 15%);

Almost there. A good gradient doesn't look like a gradient. So let's bring the lightness of the first and last colors down to 35% for the final result.

nav {
  --rebecca-purple: hsl(270, 60%, 15%);
  background-image: linear-gradient(
    to bottom right, 
    hsla(203, 92%, 35.5%, 0.25), 
    var(--rebecca-purple), 
    hsla(27.6, 87.1%, 35.7%, 0.25)
  );
  background-color: var(--rebecca-purple);
}

A case for 1 commit per pull request

Devin Rasmussen — Thu, 09 Mar 2023 04:02:20 +0000

Recently I had a coworker introduce the mental model of one pull request containing a single commit. At first I immediately rejected it as heretical. Such an idea seemed to be in opposition to many "best practices" we're taught in learning git. Nonetheless, I heard him out and there are some interesting advantages.

Address future maintainers while fresh

It's worth asking: what is the purpose of a commit? Here are some real life commit messages from a PR of mine:

- Introduce tooltip for Change Lead Time
- Apply text changes proposed by product
- Include small typo fix in admin

While these commits may communicate something to an immediate observer of a PR, they may be useless if not confusing months down the road when someone looks at a particular line's commit message with GitLens.

Compare that to the following (shortened significantly for brevity)

Force a browser hard navigation if the app is stale

Since we introduced code splitting via splitVendorChunkPlugin() 
with Vite (see PR 7420 19c7355), now Vue SFCs are lazily loaded.

Each module is hashed `[name]-[hash].js` according...

Writing a good commit message answers two important questions:

What is the overall objective of this PR?
How should a developer months/years from now interpret the 'why' of these code changes?

Arguably, these might often be the same question. Nonetheless for me both are easiest to articulate after the initial major code change (i.e., first commit). Waiting until approval to introduce a comprehensive squash commit message often means I may have to re-orient to context and recall the motivations for changes. Context switching is a heavy cost.

Switching to a model of one commit per PR forces one to think long term earlier and to provide helpful context in commit messages that will be available to developers even if version control cloud provider, issue tracker, etc. are changed.

Encourage better collaboration

One compelling argument for smaller commits is to be able to walk my peers through my process of code changes. This can be very useful for learning no doubt. But arguably it can be accomplished much better with other strategies:

Smaller pull requests
Comments (PR or in code)
Pair programming

Enabling your reviewer with the knowledge to comprehend and adequately review your code changes is important. Enabling your reviewer and your future maintainers is even better. Pairing, github commenting, and smaller PRs help in that they ideally improve your code coherence. But at the end of the day your maintainers (including you) are left with only one resource. The code commit. Why not treat the code commit as a first class equal partner to the code changes it describes?

If developers rely on the suggested tools rather than commit walkthroughs, they will become better collaborators and enablers on their teams.

My current git workflow

# zshrc
alias gcf='git commit --amend --reuse-message HEAD'
alias gpf='git push --force-with-lease'

branch from master and make a significant change
git commit -m 'long commit message'
make a change
gcf gpf
make a change that merits explanation to future maintainers:
git commit --amend gpf

Here is an example of how I am trying to write commits for better code maintenance. You can even see some of the earlier versions of that same commit in the timeline.

Potential Exceptions

Configuration migration

You're moving an entire configuration from one file to another but you also want to introduce some changes. This happened for my team when we wanted to move eslint config from package.json. Putting these in the same file first in one commit then noting the changes in another is preferable. See also git blame --ignore-rev

Branch off of non-trunk branch

Sometimes it makes sense to branch off of a non-trunk branch. For example, I work with a distributed team that sometimes doesn't get to my PRs for 12+ hours. Sometimes I want to introduce multiple PRs that will depend on changes in a previous. In this case, a tool like GitHub will intelligently watch and once a target branch is merged into main, it will update target of PR to main. Rewriting git history with something like git commit --amend can break this and will likely require some conflict resolution and manually updating the merge target.

text-overflow p in flex

Devin Rasmussen — Wed, 24 Mar 2021 01:00:03 +0000

I realize this topic has been visited elsewhere but I ran into this for the thousandth time and decided to make a post of it in the hope of locking it in memory (if not personal reference).

The situation is a dropdown list item that is wrapping the words from one line to another, making the UI less than balanced.

codepen

<div class='parent'>
  <input type='radio' />
  <div class='flex'>
    <p>first line</p>
    <div>🥱</div>
  </div>
</div>

No problem. Let's just add the recommended ellipsizing css to the p tag

p {
  text-overflow: ellipsis;
  overflow: hidden;
  white-space: nowrap;
}

Oh shoot, what have I done? Perhaps the div that surrounds the text and emoji needs a width 100%.

Ok, but what happened to the 24px of padding. Why is that not respected?

The flex div stays within the padding but its textual children do not.

If you inspect the computed browser styling of the flex child you'll notice something interesting:

If you follow the rabbit hole of the w3 spec for automatic minimum size of flex items you'll observe that the default min-width: auto ends up being either the specified or the content size suggestion. This, as I understand (and please enlighten me if you understand further) amounts essentially to the minimum width of the children text nodes.

In order to overcome this large minimum width we simply add in a min-width: 0 to the flex div (Note: this permits us to remove width: 100%;).

.flex {
  display: flex;
  align-items: center;
  min-width: 0;
}

Ignore react-router's basename

Devin Rasmussen — Wed, 18 Nov 2020 20:54:46 +0000

Suppose we have a routing tree like such in our notifications service

<HashRouter>
  <Switch>
    <Route path='/notifications/dashboard' component={A} />
    <Route path='/notifications/:id' component={A} />
    ...

If every path in this particular service contains notifications, it might be tempting to simply add a basename prop to HashRouter.

<HashRouter basename='notifications'>

This does make it really convenient when we have a link to a page in the same service. Instead of

<Link to='/notifications/dashboard' />

We can do

<Link to='/dashboard' />

The fundamental flaw with basename is its totality. There is no way to escape its effects (at least with react-router-dom components).

Say we want to direct the user out of the notification service with a URL, there is no way to do so with Link

<Link to='/tasks/123' />
// yields <a href="/notifications/tasks/123" />

This is also a hindrance to a Redirect

<Route path="/dashboard" 
  render={() => hasPermissions ? <Dashboard /> : <Redirect to="/403" 
/>
// redirects to "/notifications/403"

One should therefore proceed cautiously (probably never in the microservice case) with basename. As the documenation notes:

The base URL for all locations. If your app is served from a sub-directory on your server, you’ll want to set this to the sub-directory

Alternatively, we can nest routes like so

<Route path="/notifications"
  render={({match: {url} }) => (
    <>
      <Route path={`${url}/dashboard`} component={Dashboard}

But soon with react-router v6 nested routes will just work

<Route path="users" element={<Users />}>
  <Route path="/" element={<UsersIndex />} />
  <Route path=":id" element={<UserProfile />} />

button cannot appear as a descendant of button

Devin Rasmussen — Tue, 03 Nov 2020 19:49:12 +0000

Let's say we're given the following mock from a designer to list files in rows.

Each row should be clickable. There is also a button of "other options" on each row that triggers a different event. Therefore, there are two clickable elements, one which appears to encapsulate the other.

I'm trying to be better at semantic HTMl so I initially wrote out a <button>, stripped it of its default styling and made it into row. Then I nested another <button> inside. That is when I experienced the react warning <button> cannot appear as a descendant of <button>.

I learned that for the HTML button there must be no interactive content descendant. Interactive content is content that is specifically intended for user interaction.

We are left with two options:

Transform a non-semantic <div> into a clickable element
Use styling to place one <button> on top of another

The first is completely possible. We simply have to include a few aria attributes for accessibility. The div might look something like this

<div tabindex="0" role="button">
  <div>file title</div>
  <button>other options</button>
</div>

The other option was a little trickier but felt better to me. I don't claim to know all the ins and outs of semantic HTML but as I mentioned I'm increasingly trying to use the right tags wherever possible.

<div class='two-buttons'>
  <button class='row undo-button-styling'>
    <div>File 🤖 🎃</div>
  </button>
  <button class='other-options'>other options</button>
</div>

There are a number of styling changes that need to happen (position relative parent, position absolute child, undoing button styling) but here is the finished codepen.

https://codepen.io/devcon/pen/GRqGQxZ

useMemo in an application

Devin Rasmussen — Fri, 24 Jul 2020 00:19:31 +0000

There are a few hooks exposed by react that I don't reach for that much (if ever). This probably says more about my preferences and the applications I work on than the utility of the hook, but today I found an itch that useMemo scratched perfectly.

I wrote a fairly complex custom hook with Observables upon Observables that served the purpose of firing and organizing multiple network requests. I'm increasingly impressed with RxJS but that's not the purpose of this post.

Here is a simplified version of the custom hook.

export default function useGetTodoCountPerContact(contacts) {
  const [contactCounts, setContactCounts] = useState()
  const getSomeItems = () => networkRequestAsObs()...
  const getOtherItems = () => networkRequestAsObs()...
  const getCounts = id => forkJoin(getSomeItems(), getOtherItems())
    .pipe(map(([a, b]) => ({ [id]: a + b }))

  useEffect(() => {
    if (contacts) {
      forkJoin(contacts.map(contact => getCounts(contact.id)))
        .subscribe(res => setContactCounts(res))
    }
  ), [contacts] }
  return contactCounts
}

I proceed to consume this custom hook and everything is looking good.

const contactsTodos = useGetContactsTodosCount(contacts)

Then I realize the data includes the current contact. I need to filter that out because I already have the data for that particular contact. No problem.

const contactsTodos = 
  useGetContactsTodosCount(contacts.filter(c => c.id !== activeContact.id))

But now I start to notice something interesting in the network tab.

It appears to be an infinite loop!

When the custom hook returns its updated state, my consuming component is re-rendering and then telling the custom hook it has a new filtered list of contacts.

In order to make sure that react doesn't think there is a change in filtered contacts, I moved this filtering into a variable that is set with useMemo()

const excludeCurrent = 
  useMemo(() => contacts.filter(c => c.id !== activeContact.id), [contacts])

Now react is not diffing an array that is calculated on every render but is diffing the contacts from props which does indeed remain the same.

Why isn't event.stopPropagation() working?!

Devin Rasmussen — Thu, 09 Jul 2020 00:48:53 +0000

Today I spent a number of hours with a coworker trying to figure out why a dropdown component was unmounting on certain clicks.

There is a cool date-range picker built by another coworker that allows the user to select two different days like so:

Our QA had discovered a bug where clicking a day in June when looking at May caused the entire thing to close.

What? Why is that happening?

We had solved a similar problem a few months ago so we spent a minute tracking slack and git history to try and see what we had changed. Eventually my coworker discovered the problem: there was an event that was happening on click of document in which we were checking to see if the event's target was a child node and closing if not the case.

componentDidMount() {
  document.addEventListener('click', this.handlePageClick);
}

handlePageClick = e => {
  if (!this.myDiv.contains(e.target)) {
    this.hideChild();
  }
};

But myDiv does contain the target..? Well yes, in every case except the May example. You'll notice in the May example there is an extra row. That row disappears as soon as you click a day in June because our component is unmounting those nodes before the document click event listener is running. Watch what happens when I disable the click event.

If the document click event listener was active, it'd try and find the DOM node that is no longer there on that 6th row.

There are a few ways we could have approached this.

have a ghost 6th row that is always present but only sometimes visible
delay the removing of the row until the document click event fire finished (callback, timeout?)
add a property to the event.nativeEvent object that we could check for from the document event listener to conditionally unmount

We eventually decided to pursue event bubbling. It didn't make sense to have any click events bubbling out of the popup, so why not kill them? Problem is: they already were killed. We saw this all over the code:

<div onClick={e => e.stopPropagation()}>

So why then was it still firing? Why isn't event.stopPropagation() working?!

I came to the conclusion that the document event listener was indifferent to any children clicks after drafting a codesandbox that showed the document event listener firing regardless of stopPropagation.

But then my coworker tweeked w3school's sandbox to show me I was wrong. So I was then scratching my head.

Then it hit me. React's SyntheticEvent. I remembered that React uses a single event listener on the document. If we're adding others and trying to stop propagation, that's probably meaningless to other document event listeners because they're on the same node.

I learned that the workaround is to use window.addEventListener() instead which solved our problem instantly. Too many hours to learn a hard lesson: review and master the React docs.

componentDidMount() {
  // document.addEventListener('click', this.handlePageClick);
  window.addEventListener('click', this.handlePageClick);
}

Why list keys matter

Devin Rasmussen — Tue, 30 Jun 2020 02:51:57 +0000

As I was going through KCD's Beginner React course on egghead, I decided to explore more fully why the key matters in a React list.

Let's take as a quick example a list of inputs:

const [list, setList] = useState([
    {id: 1, value: 'agape'},
    {id: 2, value: 'philia'},
    {id: 3, value: 'storge'},
  ])
const remove = id => setList(list => list.filter(li => li.id !== id))
return <>
  {list.map(item => (
    <div style={{marginBottom: 20}}>
      <button onClick={() => remove(item.id)}>remove</button>
      <label>{item.value}</label>
      <input defaultValue={item.value} />
    </div>
  ))}
</>

codesandbox

We'll of course notice that familiar warning in the console because of the absence of a key to identify each item returned from map.

But precisely why?

If I click remove button on the bottom most item (storge) I notice it is removed appropriately from state and React removes it respectively from the DOM.

However, if I click to remove the second item (philia), something weird happens:

Our React dev tools show us that the remove function correctly adjusted our state.

So what is going on?

Well it's an indexing/state problem.

If you choose not to assign an explicit key to list items then React will default to using indexes as keys.

So if we are creating a list of items without keys:

<div>agape</div>
<div>philia</div>
<div>storge</div>

React has to think about these in some kind of order:

<div>agape</div> // key 0
<div>philia</div> // key 1
<div>storge</div> // key 2

But if we delete the second item, things get a little weird:

<div>agape</div> // key 0
<div>storge</div> // key 1

Now storge is at index 1 instead of 2. React says no problem. Index 1 from your JSX (storge) is the same as index 1 (philia) in the DOM. But that is not the case. This is why I said there is an index/state misalignment.

removes the third DOM element (because there are only two)
matches the "storge" JSX to the "philia" div and updates a portion of it that it sees is different (i.e., the label).

Optimally we want React to nuke the correct DOM element (philia) and then simply update the storge DOM element. If we provide each list item with a key, React can do that because now it isn't depending on unstable indexes.

Source/further reading

Lists and Keys
Reconciliation keys
Index as a key is an anti-pattern