The source code for this blog is available on GitHub.
Note
Top

Sanity Hack with Some Practical Usages

Cover Image for Sanity Hack with Some Practical Usages
Han Chen
Han Chen

Preview

{
  ...,
  preview: {
    select: { title: "url", media: "seoImage" },
    prepare(selection) {
      const { title, media } = selection
      console.log("media:", media)

      return {
        ...selection,
        subtitle: title && `by ${title}`,
        media: media ? media : <img src="https://cdn11.bigcommerce.com/s-k28u1tc9ki/product_images/uploaded_images/hyte-open-graph-logo.png?t=1630467744&_gl=1*1ihe6d*_ga*MjAxODM2MTgwNS4xNjI1ODYyMjkz*_ga_WS2VZYPC6G*MTYzMDQ2MjY3NC4xMDQuMS4xNjMwNDY3Nzc1LjY" alt="" />  // Here is where you set the hardcoded URL
      }
    },
  }
}

and that's how you can use it internally

  • COPY the link you want to use on the sanity
  • PASTE here
{
  ...,
      return {
        ...,
        media: media ? media : <img src="https://cdn.sanity.io/images/mqc7p4g4/staging/3f1384dff16bc4e1e24aea329110a4e8a5ce0b14-1200x630.webp" alt="" />  // Here is where you set the hardcoded URL
      }
    },
  }
}

Image

How you can place default image on Sanity

It's doable, yet tf you need to add an extra environment for image-asset-id, it's not worth it anyway. Thinking of you need to add environment variable on Sanity, Vercel platform for just doing that is too boilerplate.

{
  name: "seoImage",
  title: "Seo Image",
  type: "image",
  options: {
    hotspot: true
  },
  defaultValue: {
    asset: {
      _ref: "image-asset-id"  // Replace "image-asset-id" with the actual ID of the default image asset
    }
  }
}

Environment Variables

The problem may not be with Sanity, but with the way environment variables are used in scripts on macOS. The way you're setting the DEPLOYMENT_ENV variable is correct for a single command in a Unix-based system (like macOS or Linux), but it's not correct for a sequence of commands. Here's why:

In your script:

DEPLOYMENT_ENV=staging && node setup.js && sanity start

DEPLOYMENT_ENV=staging is only set for the first command (node setup.js), not for the subsequent commands. So when you run sanity start, the DEPLOYMENT_ENV environment variable is not set.

You can confirm this by running the following command:

DEPLOYMENT_ENV=staging && echo $DEPLOYMENT_ENV

This will output nothing, confirming that the environment variable is not set for subsequent commands.

To set the environment variable for all commands in the script, you need to export it:

export DEPLOYMENT_ENV=staging &amp;&amp; node setup.js &amp;&amp; sanity start

This way, DEPLOYMENT_ENV is set for all commands in the script.

Alternatively, you could use the dotenv package if you're using Node.js. This package allows you to set environment variables in a .env file, which will be loaded when your application starts. Here's how you would use it:

  1. Install dotenv with npm:

    npm install dotenv
    
  2. Create a .env file in your project's root directory and set your environment variables there:

    DEPLOYMENT_ENV=staging
    
  3. At the top of your setup.js script (or any other script that needs to use the environment variables), require and configure dotenv:

    require('dotenv').config();
    console.log(process.env.DEPLOYMENT_ENV);  // Should output "staging"
    

Then, you can start your application with just node setup.js && sanity start, and the environment variables will be loaded from the .env file.

Please note that .env files should not be committed to source control for security reasons. Instead, you should create a .env.example file with dummy data to show the required structure and document the needed environment variables in the README. Each developer (or the deployment system) should then create their own .env file based on .env.example.

© 2024 WOOTHINK. All Rights Reserved.
Site MapTerms and ConditionsPrivacy PolicyCookie Policy