
Welcome to the new year, ✨ **2023** ✨. Just before 2022 ended, Sanity took Sanity Studio v3 out of beta. It was perfect timing for me, as I was working on the launch of this very site.

I used the new Sanity CLI to generate my site's CMS as usual, with a few new steps from v3. The CLI was able to pre-generate a lot of the common schema you'd find in a blog thanks to Sanity's template - `Post`, `Author`, and `Category` were mostly ready to go.

One of the things that is a must-have in a coding blog is, well, the ability to display code in a blog post. This was something I needed to create that wasn't added out of the box. Depending on how you look at it, it is the joy and the peril of having a highly customizable headless CMS.

As someone that only had rudimentary Sanity knowledge and which was only limited Studio v2, it proved to be more difficult than I thought.

Although I find Sanity's documentation great 90% of the time, I find that their how-tos can assume a lot about the knowledge you hold going into it. Sometimes, they can only get you part of the way to a solution if you're new. Plus, as with any software overhaul and launch, Google and their site have a spattering of deprecated docs. Some of the new ways of doing things can be a bit hard to find.

So, let's put the pieces together to add the Code Input block to your Sanity v3 project's Block content schema.

## Prerequisites

- Basic knowledge of [npm packages](https://nodesource.com/blog/an-absolute-beginners-guide-to-using-npm/), [NextJS](https://nextjs.org/) and its dynamic routing, and [Tailwind CSS](https://tailwindcss.com/).
- Familiarity with [Sanity v3](https://www.sanity.io/blog/sanity-studio-v3-simplified-yet-powerful-customization). Specifically:
  - Schemas & the new-ish way of [registering schemas with helper functions](https://www.sanity.io/docs/schema-field-types)
  - Querying data with GROQ and your fetch method of choice. Generally working within the Sanity Content Lake.
  - Basics of working with [Portable Text](https://www.sanity.io/docs/block-content) (we'll cover some of this)
- ⭐️ Your project already set up with Sanity.io v3. [Here's how to do that](https://www.sanity.io/docs/create-a-sanity-project) if you haven't already. This article also assumes you're using NextJS with [dynamic routing](https://nextjs.org/docs/routing/dynamic-routes) to render your blog posts from Sanity.

## Feature Requirements

What we need to do to know that work is done.

- **Code Input Block:** There must be a way that I can easily add raw code to my blog posts in Sanity Studio when writing, as a block in the WYSIWYG editor. In Sanity terms, this is known as the [Block](https://www.sanity.io/docs/block-type) type schema.
- **Syntax Highlighting w/ Language Support:** This is a readability essential to me. I need syntax highlighting to be automatically applied according to the language I specify. At minimum I know I will need JavaScript, JSX, HTML, CSS, Liquid, and SASS support. Bonus points for being able to pick the theme, lol.
- **Maintainable & customizable:** The way I write this new feature must fit in with my project structure, offer custom styling, and full control over how it renders on the front end.

Now to break those down, while thinking in code:

```javascript
// Get the right tools for the job.
// A Sanity plugin for a Code Input block.
// A package to render the data (portable text) from that block.
// A package to render the syntax highlighting.

// Register the new Code Input block inside our Block Content schema and define options.

// Create the React component that our blog post raw code will render inside of.
// Configure syntax highlighting.

// Add that new component to the PortableText component that is rendering our blog post.
```

## the Tools for the Job

We'll need 3 external tools to help us with this as outlined above.

The plugin for the Code Input block we'll be using is [@sanity/code-input](https://github.com/sanity-io/code-input#sanitycode-input). It's official and quite fantastic. We'll also be referencing that readme a lot.

The best package for rendering portable text in React is [@portabletext/react](https://www.sanity.io/docs/portable-text-to-react).

Overall, this process is straightforward. But I had a lot trouble with rendering the Code Input in NextJS, and it took me much too long to realize I was using the wrong npm package that was commonly used in V2. The bottom line is make sure your project is using [@portabletext/react](https://www.sanity.io/docs/portable-text-to-react) to render any and all portable text on your blog post.

The context for above is that I started building my new site and learning Sanity in general before V3 was released, but after V2 had been out for quite some time. I found this [plugin page](https://www.sanity.io/plugins/react-portable-text) on Sanity's site when it came time to render my posts and began to use it. It is called `react-portable-text` and it worked for my needs in V2.

The correct package to use for rendering all portable text in V3 is `@portabletext/react`. I mistakenly thought they were the same thing, as they have near identical ways of calling the rendering `PortableText` component and passing it the same `components` prop (more on this later). I was able to swap packages once I realized.

The package I'll be using for syntax highlighting is [refractor](https://github.com/wooorm/refractor#refractor), since it was referenced in the @sanity/code-input readme example. If you have another you like to use, go for it - just make sure it's compatible with @sanity/code-input.

## Registering the Code Input inside our Content Block Schema

Navigate to your project's Sanity folder and install the Code Input plugin.

```bash
// my-project/my-sanity-folder

npm i @sanity/code-input
```

Now to register that newly installed plugin inside our Sanity config, in the `plugins` array in the `defineConfig()` function. This will expose the plugin to our schema so it can use it.

```javascript
// sanity.config.js

//....
import { codeInput } from "@sanity/code-input";

export default defineConfig({
  // ....
  dataset: 'production',
  plugins: [deskTool(), visionTool(), codeInput()],

  // ....
  },
})
```

Let's open up our blog post schema. Mine was conveniently pre-generated by Sanity CLI and looks something like this:

```javascript
// my-project/my-sanity-folder/schemas/blockContent.js

import { defineType, defineArrayMember } from 'sanity'

export default defineType({
  title: 'Block Content',
  name: 'blockContent',
  type: 'array',
  of: [
    defineArrayMember({
      title: 'Block',
      //....
    }),

    defineArrayMember({
      type: 'image',
      options: { hotspot: true },
    }),
  ],
})
```

Below the second `defineArrayMember()` function, we're going to add another call of it to register the Code Input component in the block editor.

```javascript
// my-project/my-sanity-folder/schemas/blockContent.js

import { defineType, defineArrayMember } from 'sanity'

export default defineType({
//....

    defineArrayMember({
      type: 'image',
      options: { hotspot: true },
    }),
    defineArrayMember({
      type: 'code',
      options: {
        language: 'JavaScript',
        languageAlternatives: [
          { title: 'HTML', value: 'html' },
          { title: 'CSS', value: 'css' },
          { title: 'JavaScript', value: 'js' },
          { title: 'JSX', value: 'jsx' },
          { title: 'SASS', value: 'sass' },
          { title: 'Liquid', value: 'liquid' },
          { title: 'Bash', value: 'bash' },
        ]
      }
    }),
  ],
})

```

What this does is register a new plugin whose type is `code`. I've included some options while following the documentation on the [Code Inputs page](https://www.sanity.io/plugins/code-input). `language` just defines what default language will be selected when you add a new code input block. The `languageAlternatives` is important - this is where we are defining which languages we want to support. Add in whichever languages you'd like to, which are supported by your syntax highlighter.

You can find a list of languages refractor supports [here](https://github.com/wooorm/refractor/tree/main/lang).

At this point, run `npm run dev` in your Sanity folder and poke around. Navigate to a post in Sanity Studio and your code block option should show up! Fantastic.

Now, let's work on rendering our post, along with the code inputs, in our NextJS front end.

## Rendering Code Inputs on the Page

Now, this is where your process may slightly deviate from mine, especially if you aren't using NextJS. That's okay. Our main goal is taking the portable text data of our raw code content that Sanity is generating, and control how it renders to the page.

I am using [dynamic routing](https://nextjs.org/docs/routing/dynamic-routes) in NextJS to create my post pages from a file named `[slug].js`.

Here's a basic example of how the blog post content is currently being rendered on the page:

```jsx
import { PortableText } from '@portabletext/react'

const Post = ({ post }) => {
  return (
    <>
      <header>
        <h1>{post?.title}</h1>
      </header>
      <section>
        <PortableText value={post.body} />
      </section>
    </>
  )
}
```

Here, we're using the `PortableText` component imported from the package mentioned earlier. This code is assuming you've already passed in your post data from Sanity as props.

You may notice your code either is rendering with no styling as text, or possibly not rendering at all. First, we must create a component that will handle the rendering of our code. Second, we must utilize the `PortableText` `components` functionality.

## Creating the `Code` Component

This is the component that will render once `PortableText` finds a code input in your content.

In whichever folder you have that holds your front end components, create `Code.js`. Below is what mine looks like. Let's go through it piece by piece.

```jsx
// components/Code.js

import React from 'react'
import Refractor from 'react-refractor'
import markdown from 'refractor/lang/markdown.js'
import jsx from 'refractor/lang/jsx.js'
import liquid from 'refractor/lang/liquid.js'
import css from 'refractor/lang/css.js'
import js from 'refractor/lang/javascript.js'
import sass from 'refractor/lang/sass.js'
import bash from 'refractor/lang/bash.js'

const languages = [jsx, markdown, liquid, js, css, sass, bash]

languages.forEach((language) => {
  Refractor.registerLanguage(language)
})

export function Code({ language, code, highlightedLines }) {
  return (
    <Refractor language={language} value={code} markers={highlightedLines} />
  )
}
```

I've imported all of the files of common languages I use at the top of this file and the main `Refractor` component from Refractor. The imported languages are the same languages we registered in `my-project/my-sanity-folder/schemas/blockContent.js`.

Then I created an array `languages` to hold all of these variables, which will be iterated over and registered with Refractor's `registerLanguage()` function.

Then you'll pass the Refractor props, which are actually the content of your Code input. For more context, view the tutorial in the Code Inputs [readme here](https://github.com/sanity-io/code-input#example-usage-in-frontend-react).

## Rendering your New `Code` Component

Alright, now it's time to go back to our `Post` page component and let the `PortableText` rendering component know we want to use `Code` for code input blocks.

First, import your `Code` component at the top of the file.

Then, let's create a constant called `components`. It will be an object accepting a key `types` with a value of another object, which will be the name of the HTML element you'd like to control. In this case, that will be `code`. The value will be a function returning your component with its needed props passed in from Sanity data.

You can read more about the `components` prop [here](https://www.sanity.io/docs/portable-text-to-react#customizing-components).

```jsx
// pages/post/[slug].js

import { PortableText } from '@portabletext/react'
import { Code } from '/./components/Code'

const components = {
  types: {
    code: (props) => {
      return (
        <Code
          language={props.value.language}
          code={props.value.code}
          highlightedLines={props.value.highlightedLines}
        />
      )
    },
  },
}

const Post = ({ post }) => {
  return (
    <>
      <header>
        <h1>{post?.title}</h1>
      </header>
      <section>
        <PortableText value={post.body} components={components} />
      </section>
    </>
  )
}
```

## Getting the Pretty Theme

Huzzah! Your code is rendering with indenting and all of the great formatting we're used to. Except, your favorite IDE themed syntax highlighting is missing even though we've passed `Refractor` the `highlightedLines` prop.

That's because we have to add the theme CSS! Refractor is built with Prism, so all Prism themes will apply nicely.

You can find a list of [Prism themes here](https://github.com/PrismJS/prism-themes), or [generate your own](http://k88hudson.github.io/syntax-highlighting-theme-generator/www/).

Once you get the raw CSS, you'll have to add it in whichever way you deem fit for your project. I've added mine via Sass and Tailwind. I created a Sass partial `_text-editor.scss` and pasted the code in there, along with some tweaks for font sizing, font family, and other things here and there.

Here's a snippet I add to all of my Prism themes that I've found helpful.

```scss
// your Prism theme CSS
// styles/customizations/_text-editor.scss

code,
pre span {
  font-family: Consolas, Monaco, 'Andale Mono', 'Ubuntu Mono', monospace
  font-size: 14px
  // Whatever font size you want and other updates, accordingly
}
```

Once the CSS is added to your site, that's it! ✨ Bam. You should have a perfectly working code snippet component. Go forth, and write about code.


Learn how to add support for displaying code in your blog posts using Sanity CMS. This includes support for language syntax highlighting, custom styling, and more.

Adding Code Snippets in Sanity Studio v3


Note as of May 2023: I wrote this post way back when my personal site was powered by [Jekyll](https://jekyllrb.com/). But this is still worth checking out if you're interested in Jekyll site creation.

Everywhere I’ve looked, many have been saying the same thing: “BUILD A BLOG. Document your process. Write things down. You’ll learn from it.” I’m not the best writer, but hey. Alright. I’ll give it a shot.

I asked myself the question we all dread - **so what tech am I going to use?**

Buzzwords like Jekyll, Gatsby, and Hugo were all over [/r/webdev](https://www.reddit.com/r/webdev). I had no idea what a static site generator was, much less which one was best to use. I poked around a bit, and determined that Jekyll was probably the best way to go for me - the documentation was clear and detailed, and the learning curve of React/Gatsby didn’t sound appealing in my rush to get started. Jekyll uses a templating language called Liquid, and accompanied with Markdown, makes for a pretty powerful CMS.

From here on, I will discuss Jekyll as it pertains to my personal site. The Jekyll Docs have a great [step-by-step setup tutorial](https://jekyllrb.com/docs/step-by-step/01-setup/) you can view if you want to know more about how it works, and what other features are available.

Right out of the box, Jekyll has some powerful tools available at our disposal. I didn’t have to fiddle with Gulp or any other task runners, because Jekyll already auto-compiles Sass and spins up a local development server using the CLI command `$ jekyll serve`. I’m such a fan of how easy it is to get up and going with this CMS.

The includes & layout features encouraged me to keep my code as modular as possible. I used 3 includes throughout my site: head.html, nav.html, and footer.html. The first file held the basic HTML heading - the doctype, the `<head>`, the various meta tags, and the opening body tag. This saved me a lot of code repetition. The second held my navigation bar, and the ul including all of my nav items. Finally, `footer.html` was… the footer. I also included the closing `</body>` tag; I wanted my footer on every page anyway, so I didn’t have to remember to close every body tag in the individual layout files.

So with the main HTML skeleton taken care of, I was able to focus entirely on main content. Now I’ll share some fun stuff Jekyll has to offer that helped me build my blog.

## Using Conditionals for Dynamic Navigation

My main goals for this site were documenting my learning process and branding myself into the dev world. So, keeping it simple would be my best bet, for the time being. I only had 2 pages (besides the home page) in mind. I should probably write a bit about who I actually am, and include a page on how to contact me in case any of my fans wanted to chitchat.

However, who knows if I wanted to expand on my site in the future. Maybe I would want to add a portfolio page sometime, with some projects. Maybe a gallery page for my film photography. Maybe a page just for my cat. Alas, I’m lazy. Every time I add a new page, I don’t want to add in a new `<li>` and edit my navigation file every time I expand. I want to focus on content. So, I discovered the power of conditionals and the front matter!

I headed on over to the [Liquid Control Flow docs page](https://shopify.github.io/liquid/tags/control-flow/) and checked out what I had at my disposal. Yay! For loops! No problem. I’ll generate some `<li>`s by looping through every page.

```plaintext
{% for page in site.pages %}
<li>
<a href="{{ page.url | prepend: site.baseurl }}">{{ page.title }}</a>
</li>
{% endfor %}
```

The above code basically says: for every single HTML page in my Jekyll site, make a list item with the linked title of the page, and display it in the navigation bar.

…but, it didn’t work. Not like I wanted it to. It literally put every page in the main navigation - including the archive pages for each of my tags. It looked something like this:

```plaintext
HOME ABOUT CONTACT HTML CSS JAVASCRIPT CONTENT-STRATEGY DESIGN
```

So on, and so forth. Definitely NOT what I wanted. I read a little more, and found a neat work around.

```plaintext
{% for page in site.pages %}
  {% if page.navi %}
    <li>
    <a href="{{ page.url | prepend: site.baseurl }}">{{ page.title }}</a>
    </li>
  {% endif %}
{% endfor %}
```

The key is this conditional if `page.navi`. Jekyll allows for custom variables in front matter - anything you want. navi is one of those custom variables. In the front matter of each page I wanted in the navigation, I set a custom variable navi: true. The code now will only make a `<li>` if the variable is present in the front matter.

Now, any time I create a new page, I can just put in that variable and I’m good to go!

## Yay Plugins!

My first impression of Jekyll was pretty positive, however, there are a few things missing. One is a decent archiving & tagging system.

I could define a tag variable in front matter, no problem. However, I wanted the tags to be clickable, and when clicked take you to a page that listed all the posts with that respective tag. So, I found a neat plugin called [jekyll-archives](https://github.com/jekyll/jekyll-archives) to do just that.

All I had to do was include the following in my config.yml file:

I defined a layout for each archive page, and specified the format and styling for which each post would be displayed. After a quick for loop, the plugin did the rest.

Even though ways to search by year, month, day, category, etc exists I’m pretty content with pages just for individual tags. As I write more posts, my plans are to add pagination, additional archive options, and a search feature. Until then, I’ll keep writing!

## A Note on Github Pages

It’s true that [Jekyll and Github Pages](https://help.github.com/articles/using-jekyll-as-a-static-site-generator-with-github-pages/) are quite a match. However, I chose to deploy my site with Netlify for a couple of reasons. One is that Github Pages does not support (most) Jekyll plugins - so I couldn’t get the archive feature I wanted. I felt that it limited me in a lot of ways.

Netlify also supports [continuous deployment](https://www.netlify.com/blog/2015/10/28/a-step-by-step-guide-jekyll-3.0-on-netlify/) which allowed it to integrate into my Git workflow seamlessly. I didn’t have to sacrifice that GitHub benefit. Every time I use git push, Netlify automatically builds a new version of my site. Second, Netlify has an awesome [form submission feature](https://www.netlify.com/docs/form-handling/). All I have to do is add a `netlify` attribute to my form HTML, and I can receive submissions, no back end or API required! So, that’s dang cool.

## Conclusion

Jekyll is a great and powerful tool that I’m happy I explored. I know I have only just barely scratched the surface; I’ve probably also used some things a bit wrong. I’m just excited to see what else it can do, and learn as much as I can. I wouldn’t personally use it for a freelance client’s website, as it’s a bit more developer oriented. However I can see it being great for micro sites, quick static mockups, and a variety of other possibilities.


An old post I wrote in 2018 chronicling my very first static site on Jekyll, and various problems I solved.

cool things i write about

Adding Code Snippets in Sanity Studio v3

My Personal Site & Jekyll