DEV Community: TOMAS E GIL AMOEDO

Verifying Your Shopify App Embed is Actually Enabled with Remix: A Step-by-Step Guide

TOMAS E GIL AMOEDO — Sun, 05 Jan 2025 21:44:33 +0000

Programmatically Checking a Shopify App Embed with Remix

How do we, as Shopify app developers, confirm programmatically that our theme app embed is truly switched on? Shopify provides a toggle in the theme editor, but there’s no official “Check if embed is active” endpoint. For all we know, the merchant could have disabled our block—or never enabled it—in their main theme.

In this tutorial, we’ll walk through a practical solution using Remix:

We’ll query the store’s main theme
Retrieve and parse settings_data.json (while stripping out comment blocks)
Verify that our embed block isn’t set to disabled: true By the end, we’ll be able to confirm—directly from our code—that the app embed is actually running for every merchant who installs it.

Context

If the Embed Is Off

Merchants end up with a “half-installed” app. That can lead to confusion or missing features

No Direct “Check Embed” Endpoint

Shopify doesn’t offer /is-embed-enabled, so we must verify—manually—that the block is disabled: false in the main theme.

The Remix + GraphQL Approach

We’ll fetch and parse settings_data.json, strip out comment blocks, and check if our block is enabled. This gives us a simple boolean: if true, it’s disabled; if false, it’s active.

Requirements & Setup

Note: Ensure your app has read_themes scope (and write_themes if you plan on modifying theme files).

Steps in a Nutshell

1.Identify the store’s main theme.
2.Fetch and parse settings_data.json.
3.Check if our app embed block is marked disabled: false.

With that covered, let’s jump right into the code!

Step-by-Step Solution

4.1 Identify the Main Theme

Query All Themes

We call Shopify’s Admin API (GraphQL) to retrieve a list of themes. Only one theme should have role: MAIN, which is the published or currently live theme.

Extract id

Once we find the main theme, we’ll grab its id (e.g., gid://shopify/OnlineStoreTheme/123456789). This will be crucial for the next step when we fetch settings_data.json.

const GET_THEMES = `
  query {
    themes(first: 20) {
      edges {
        node {
          id
          role
          name
        }
      }
    }
  }
`;

export async function getMainThemeId(admin: any) {
  const response = await admin.graphql(GET_THEMES);
  const responseJson = await response.json();

  const themes = responseJson.data.themes.edges;
  const mainTheme = themes.find((t: any) => t.node.role === "MAIN");

  return mainTheme ? mainTheme.node.id : undefined;
}

4.2 Fetch `settings_data.json`

Use the Theme ID
With the ID from above, we craft another query to specifically retrieve settings_data.json from that theme’s files.

Strip Comment Blocks
settings_data.json often contains a multi-line comment (the big /* ... */ at the top). We remove it before parsing, because it breaks JSON.parse.

Parse the JSON
After removing the comment block, convert the remainder into a JavaScript object so we can inspect the blocks.

const GET_THEME_FILE = `
  query getThemeFile($id: ID!) {
    theme(id: $id) {
      files(filenames: ["config/settings_data.json"], first: 1) {
        nodes {
          filename
          body {
            ... on OnlineStoreThemeFileBodyText {
              content
            }
          }
        }
      }
    }
  }
`;

export async function getSettingsData(admin: any, themeId: string) {
  const response = await admin.graphql(GET_THEME_FILE, { variables: { id: themeId } });
  const result = await response.json();

  const rawContent = result.data.theme.files.nodes[0]?.body?.content ?? "";
  const cleaned = rawContent.replace(/\/\*[\s\S]*?\*\//, ""); // remove multi-line comment

  return JSON.parse(cleaned);
}

4.3 Check for Your App Embed Block

Locate the "blocks"
Inside the parsed JSON, we typically look at parsedData.current.blocks.

Find the Block Matching Your App
The block type might look like shopify://apps/dev-storelock/blocks/country-blocking/.... Use something like block.type.includes("dev-storelock") (or your own app handle) to confirm it’s yours.

Verify disabled
If disabled is false, that means the embed is actually enabled. If the block is missing or set to disabled: true, the embed is off.

export function isAppEmbedDisabled(parsedData: any, appHandle: string): boolean {
  const blocks = parsedData?.current?.blocks;
  if (!blocks) return true; // If no blocks exist, treat as disabled.

  // Loop over block keys
  for (const blockId of Object.keys(blocks)) {
    const block = blocks[blockId];
    if (block?.type?.includes(appHandle)) {
      return block.disabled === true;
    }
  }

  // If we never found our block, assume disabled.
  return true;
}

4.4 Putting It All Together (Remix Loader Example)

Below is a skeletal Remix loader showing how we might fetch both the main theme and then settings_data.json, and finally check if the app embed is active:

import { json } from "@remix-run/node";
import type { LoaderFunction } from "@remix-run/node";

// Utility functions from above
import { getMainThemeId, getSettingsData, isAppEmbedDisabled } from "~/lib/shopify.server";

export const loader: LoaderFunction = async ({ request }) => {
  // auth, create `admin` client, etc. omitted for brevity
  const themeId = await getMainThemeId(admin);

  let embedDisabled = true; // default to "embed off"

  if (themeId) {
    const settingsData = await getSettingsData(admin, themeId);
    embedDisabled = isAppEmbedDisabled(settingsData, "dev-storelock");
  }

  return json({ embedDisabled });
};

In our Remix route, we end up with a simple boolean embedDisabled. Our React component can conditionally render a warning or skip certain features if the embed is off.

Recap

Find main theme → fetch settings_data.json → strip comment → check block type and disabled.
Once we have that result, we can react accordingly in our UI or logs. That’s how we confirm, programmatically, that our Shopify embed is truly enabled—no guesswork needed.

Want the Full Snippet?

For a consolidated version of all these steps, check out the Gist:

https://gist.github.com/Tommydemian/fe5896c66b5cba6b5b4a5139362758df
Happy coding and don't forget to leave a star if the code is useful, thanks!

Conclusion & Next Steps

This is a little guidance on how to integrate a working solution into a Remix environment. This tutorial covers the gap left by Shopify’s lack of a direct endpoint. With a short Remix loader (or custom hook—which I personally prefer, given my strong React background—and a bit of parsing), we get a clean, reliable way to verify the app embed’s status—no guesswork required.

Workflow Recap:
1.Locate the main theme
2.Fetch settings_data.json
3.Strip out comment blocks
4.Check the type and disabled fields

By following these steps, our block is truly active in the storefront—essential if the app handles security or other high-priority features.

Optional Enhancements:

Alerts: Consider logging a warning or showing a banner in your admin UI if the embed is off.
Caching: If you frequently call the Shopify Admin API, think about caching settings_data.json to avoid repeated fetches.

If you have questions or tips, feel free to share them in the comments.
Happy coding!

JavaScript Closures and Custom Iterators: A Comprehensive Guide.

TOMAS E GIL AMOEDO — Fri, 17 Feb 2023 16:20:51 +0000

Demystifying Closures in JavaScript

Closures are one of the most elegant and powerful features of JavaScript, allowing developers to write expressive and concise code. However, despite their potential, closures are often misunderstood and widely misinterpreted. In this blog, we will demystify closures, taking a deep dive into their inner workings and exploring how to create iterators using closures. By the end, you'll be equipped to harness the full power of closures in your own projects.

Let's start with the basics:

JavaScript and Lexical Scoping

JavaScript is a lexically scoped language, which fundamentally means that the data available when calling a function is determined by where it was originally defined. In other words, where the function was defined is what determines the data it has access to. If the available information varies depending on where it is called, we would be talking about a dynamic scope... but this is not the case.

Once this concept is understood, we can proceed with closures.

How closures work

Closures are formed from a function that returns a function, which is where functional programmers would be delighted with me. The inner function in this case is able to access variables and parameters from the outer function, even after the outer function has returned. This is possible because the inner function has formed a bond with its surrounding data, called closure or lexical closure.

In other words, the inner function has its own backpack, in which it carries around the data from its surrounding scope. When the inner function is returned, it retains access to that backpack, allowing it to access the same variables and parameters from the outer function whenever it is called.

To illustrate this concept, let's take a look at an example:

In this example, outerFunc defines a variable outerVar, and then returns the innerFunc. When innerFun is called, it logs the value of outerVar, even though it is no longer in the scope of outerFunc.

With closures, we can create powerful and flexible code. One example of this is the ability to create custom iterators, which allow us to iterate over data in a flexible and efficient way. With custom iterators, we can create complex operations on data with ease, giving JavaScript the full power of classic iteration libraries like Python's itertools.

But that's just the tip of the iceberg. With closures, you have infinite possibilities. You can create reusable functions that are tailored to your specific needs, or you can create encapsulated modules that protect your code from global namespace pollution. The only limit is your imagination.

In the next section, we'll explore how to create custom iterators using closures. Get ready to harness the full power of closures!

Let's take a look at a code example:


function createFlow(array) {
    let i = 0;
    function inner(){
        const element = array[i];
        i++;
        return element;
    }
    return inner;    
};

const returnNextElement = createFlow([4,5,6]);

const element1 = returnNextElement()
const element2 = returnNextElement()

Now things get interesting because element1 is calling returnNextElement(), which has the following functionality within it:


function inner() {
    const element = array[i];
    i++;
    return element;
}

But where is the array? We haven't defined it anywhere in the current execution context, so it should be undefined, right?

Here's where closures come in. As soon as we defined inner() inside createFlow(), it formed a bond with all the surrounding live memory, in other words, the surrounding data. When we returned that function, we returned in its backpack all of its surrounding data, which in this case happens to be the array [4,5,6], giving us access to its indexes.

So instead of looking for the array in the global memory, we look in the backpack of our returned function.

By the way, the posh name for returnNextElement is iterator. Iterators turn our collection data into streams, i.e., flows of actual values that we can access one after another.

With closures, we have the ability to create custom iterators, giving JavaScript the full power of classic iteration libraries like Python's itertools.

Creating Custom Iterators with Closures

In JavaScript, iterators are objects that provide a sequence of values from a collection. An iterator has a method called next which returns an object with two properties: value and done. The value property contains the next value in the sequence, and the done property is a boolean value that indicates whether the iterator has reached the end of the sequence.

With closures, we can easily create custom iterators that can iterate over any data type. Here's an example:

function returnIterator(arr) {
  let i = 0;
  function indIterator(){
    const element = arr[i];
    i ++;
    return element;
  }
  return indIterator;
}

const array = ['a', 'b', 'c', 'd'];
const myIterator = returnIterator(array);
console.log(myIterator()); // -> should log 'a'
console.log(myIterator()); // -> should log 'b'
console.log(myIterator()); // -> should log 'c'
console.log(myIterator()); // -> should log 'd'

In this example, returnIterator is a function that takes an array and returns an iterator function. The iterator function indIterator has access to the arr variable in its closure and returns the next element of the array each time it is called.

We can also create an object with a next method to make our custom iterator more precise. Here's an example:

function nextIterator(arr) {
  let i = 0;
  const iterator = {
    next: function () {
      const value = arr[i];
      i++;
      return {
        value: value,
        done: i > arr.length
      };
    }
  };
  return iterator;
}

const array = ['a', 'b', 'c', 'd'];
const myIterator = nextIterator(array);
console.log(myIterator.next()); // -> should log { value: 'a', done: false }
console.log(myIterator.next()); // -> should log { value: 'b', done: false }
console.log(myIterator.next()); // -> should log { value: 'c', done: false }
console.log(myIterator.next()); // -> should log { value: 'd', done: false }
console.log(myIterator.next()); // -> should log { value: undefined, done: true }

In this example, nextIterator returns an object with a next method. Each time the next method is called, it returns an object with a value property and a done property. The value property is the next element in the array, and the done property is a boolean value that indicates whether the iterator has reached the end of the array.

Conclusion

Closures are a powerful feature in JavaScript that allow us to write more expressive and concise code. They enable us to create custom iterators, which are essential for many programming tasks. With closures, we can create reusable functions that are tailored to our specific needs, or we can create encapsulated modules that protect our code from global namespace pollution. The only limit is our imagination.