DEV Community: JanaSundar

Building Ovio: A React Component Registry That Balances Creativity and Practicality

JanaSundar — Sat, 10 Oct 2026 12:47:27 +0000

Developer websites often share a familiar set of elements: GitHub contribution graphs, repository statistics, npm downloads, changelogs, and project cards.

These components serve a purpose. They help developers communicate what they're building and give visitors a quick overview of their work.

But I noticed something interesting: while the information varies from project to project, the way we present it often feels repetitive.

I wanted to explore a different approach.

That led me to build Ovio, a collection of animated React components designed for developer websites.

The project became an exploration of two challenges: building reusable components that developers can customize and creating visually distinctive interfaces that remain useful beyond a demo.

The Challenge of Building Reusable Components

Reusability is one of the core ideas behind component-driven development.

We extract common patterns into components so we can maintain them in one place and reuse them across an application.

But visual components introduce an interesting challenge.

A component might work perfectly in isolation and still feel out of place when someone integrates it into their website.

Different projects have different typography, spacing, colors, layouts, and visual identities. A component that looks great in one context might need substantial customization in another.

This became an important consideration while building Ovio.

I wanted developers to have components they could adapt to their own projects rather than treating the original design as a fixed set of rules.

Why I Chose a shadcn-Style Registry

Ovio uses a shadcn-style registry approach.

Instead of treating components as black boxes that developers can only customize through a predefined API, this approach lets developers work directly with the component source code.

That changes the relationship between the library and its users.

Developers can inspect how a component works, modify its styling, adjust its behavior, and integrate it into their existing design system.

For a collection focused on visual experimentation, this flexibility is particularly useful.

Someone might like a component's interaction but prefer different typography. Another developer might want to adapt its layout to match a personal portfolio.

The goal is to provide a useful starting point without taking away the developer's control.

Four Visual Directions for Developer Websites

One of the ideas behind Ovio is that the same kind of information can be presented through different visual styles.

The collection explores four directions:

1. Minimal

A restrained visual style that prioritizes clarity and content.

2. Craft

A more tactile and deliberately designed aesthetic.

3. Retro

A visual direction inspired by older digital interfaces.

4. Toy

A playful approach that gives components more personality.

These aren't intended to be merely four color palettes.

Each direction explores a different visual character, giving developers more flexibility when choosing components for their websites.

The challenge is maintaining clarity across those styles. A component should still communicate its information effectively, regardless of its appearance.

When Does a Creative Component Become Useful?

This is one of the most interesting questions I've encountered while building Ovio.

It's easy to create a component that looks impressive in a controlled demo. It's harder to create something that feels natural inside a real project.

Consider a few questions:

Does the component communicate its information clearly?
Can developers customize it without fighting the original design?
Does the interaction serve a purpose?
Does the component fit into different layouts?
Is the animation comfortable to use repeatedly?

These questions matter because visual appeal and practical utility aren't the same thing.

A component can be visually interesting without solving a meaningful problem.

At the same time, a practical component doesn't have to look generic.

I want Ovio to explore the space between those two extremes: components with personality that developers can still adapt to real projects.

Animation Should Have a Purpose

Animation can make an interface feel responsive and expressive.

It can communicate a state change, provide feedback, or make an interaction feel more tangible.

But motion can also become distracting.

For example, a GitHub contribution graph should remain easy to understand. A repository card should make its information easy to scan. An animated counter shouldn't make the number itself harder to read.

The animation should support the content rather than compete with it.

Accessibility is part of this consideration, too. Ovio respects reduced-motion preferences for people who prefer less animation.

The principle is simple: motion should improve the experience, not demand attention for its own sake.

What I'm Learning from Building Ovio

Building Ovio has made me think more carefully about the difference between designing a component and designing a component that other developers can use.

A successful component needs more than a good appearance.

It needs a clear purpose, sensible customization options, understandable behavior, and enough flexibility to work in different contexts.

The registry approach gives developers access to the source code, but that alone doesn't guarantee a good developer experience. The components still need to be thoughtfully designed and easy to adapt.

I'm continuing to explore that balance as the collection evolves.

What's Next?

I want to keep exploring components that serve real developer use cases while leaving room for experimentation.

That means thinking about new ways to present repository activity, package information, release history, and community contributions.

It also means listening to developers and learning which components they'd actually use.

A component library shouldn't grow just to increase its component count. The goal should be to help developers build better experiences with less unnecessary work.

Final Thoughts

Ovio started with a question: what if developer websites could present familiar information through more expressive interfaces?

The project has become an opportunity to explore reusable architecture, visual consistency, animation, and practical utility.

I'm still learning where the balance lies, and I'd be interested in hearing how other developers approach similar challenges.

If you're building React components or design systems, how do you decide when a component needs more visual personality and when simplicity is the better choice?

I'd love to hear your perspective.

Intro to mdx-bundler with NextJs

JanaSundar — Sun, 24 Oct 2021 09:21:05 +0000

In this article, We'll see how to use mdx-bundler with Nextjs. MDX is the extension of markdown that allows us to write React Component inside markdown file. It helps us to make our content very interactive and dynamic. I got to know about the mdx-bundler package from Josh's blog post. Kent C Dodds created this package. In my opinion, mdx-bundler gives Superpowers to mdx.

Let's have a deeper look into mdx-bundler, and I'll guide you through all the features of this package.

Let's get started with mdx-bundler

mdx-bundler is an asynchronous function to compile and bundle our MDX files with their dependency. To compile mdx files, it uses XDM, a powerful MDX compiler with lots of features. mdx-bundler is best suited for the SSR framework. In this article, I'll be using NextJS.

To create a new NextJS project, run this command.

npx create-next-app@latest appname

or

yarn create next-app appname

Now run the following command to install mdx-bundler

npm install --save mdx-bundler esbuild

or

yarn add mdx-bundler esbuild

To compile and bundle our MDX files, we need to use the bundleMDX function in this package. It takes two parameters, the first parameter is our MDX code in a string format, and the second parameter accepts an options object.

import {bundleMDX} from 'mdx-bundler'

const mdxSource = `

title: Example Post published: 2021-02-13 description: This is some description

* * *

# Wahoo

import Demo from './demo'

Here's a **neat** demo:

<Demo /> `.trim()

const result = await bundleMDX(mdxSource, { files: { './demo.tsx': ` import \* as React from 'react'

function Demo() { return <div>Neat demo!</div> }

export default Demo `, }, })

const {code, frontmatter} = result

To render the bundled MDX code, we need to import getMDXComponent in the client

import * as React from 'react'

import {getMDXComponent} from 'mdx-bundler/client'

function Post({code, frontmatter}) {

const Component = React.useMemo(() => getMDXComponent(code), [code])

return ( 
<>
 <header>
  <h1>{frontmatter.title}</h1>
    <p>{frontmatter.description}</p>
 </header>
 <main>
 <Component />
 </main> 
</> ) }

Check out this link to find all available options.

Most of the mdx blogs are using local mdx files to store their blog contents. In my case, I'm using GraphCMS to store the mdx data. If you don't know what GraphCMS is? Check out my blog post where I explain how to get started with it.

Now we have the basic idea to use mdx-bundler. Let's breakdown down the code, and I'll guide you on how I used mdx-bundler in this blog.

export const getStaticProps = async (context) => {

if (process.platform === 'win32') { process.env.ESBUILD_BINARY_PATH = path.join(process.cwd(), 'node_modules', 'esbuild', 'esbuild.exe'); } else { process.env.ESBUILD_BINARY_PATH = path.join(process.cwd(), 'node_modules', 'esbuild', 'bin', 'esbuild'); }

const { slug } = context.params;

const post = await getSinglePost(slug);

const result = await bundleMDX(post.content, { 
  xdmOptions(options) {
   options.rehypePlugins = [...(options.rehypePlugins ?? []), rehypeMdxCodeMeta];
   options.remarkPlugins = [...(options.remarkPlugins ?? []), gfm, emoji];
 return options;
  },
 ...(post.files ? { files: post.files } : {}),
 });

return { props: { ...result, }, }; };

Sometimes Nextjs don't find the exact path of esbuild. Due to this reason, We might get this ENOENT(Error No Entry) error. To resolve this issue, we are manually adding the executable path.

 if (process.platform === 'win32') {
    process.env.ESBUILD_BINARY_PATH = path.join(process.cwd(), 'node_modules', 'esbuild', 'esbuild.exe');
  } else {
    process.env.ESBUILD_BINARY_PATH = path.join(process.cwd(), 'node_modules', 'esbuild', 'bin', 'esbuild');
  }

Reference

https://www.alaycock.co.uk/2021/03/mdx-bundler#esbuild-executable

To add the custom remark and rehype plugins to our bundler, use the xdmOptions object to achieve this behavior.

 xdmOptions(options) {
      options.rehypePlugins = [...(options.rehypePlugins ?? []), rehypeMdxCodeMeta];
      options.remarkPlugins = [...(options.remarkPlugins ?? []), gfm, emoji];
      return options;
 }

Want to create a custom plugin? Check this post where Pedro Duarte explained everything in detail.

Reference

The main difference between mdx-bundler and other libraries are most of the library does not bundle mdx code. They also don't have the option to add the dependency to our mdx code. We can achieve this dependency import feature using both files and the CWD option. In this blog, I used files to add the dependency code.

...(post.files ? { files: post.files } : {}),

I hope that you have learned how to use mdx-bundler with Nextjs. Thanks for reading ✌️ and if you enjoyed this article, share it with your friends and colleagues.

How to generate dynamic open graph images

JanaSundar — Sun, 17 Oct 2021 11:17:29 +0000

This post was originally published at this blog

Introduction

In this article, we will see how to generate dynamic open graph images. You might be wondering what an open graph image is? Whenever you share a link in Twitter, Discord, or other applications. A fancy card image / link preview is displayed and that image is called an open graph image / OG image.

Requirements

To generate an OG image, we'll be using these npm packages.

Installing Requirements

Do you have yarn? If not, then install it and run the below command or else use npm

yarn add puppeteer-core chrome-aws-lambda

Creating your OG Image

Before creating this function, If you're planning to deploy this project in vercel. I'll suggest everyone create a separate project. Otherwise, we may face this issue 👇

If we integrate this function with our existing project and deploy it in vercel. There is a chance that we might get an error message that the serverless function dependency package compressed size exceeds 50Mb, and then it stops the deployment process.

To get an idea, we'll see how our final output looks like

https://og-image.janasundar.dev/api/ogimage?title=How i built my blog with Next Js&tags=javascript,jsx,nextjs

From the above Url and image, we understand that the dynamic data are passed as the query parameters to generate an image.

So now we need a function that takes a screenshot of our content and passes it as a response. This can be achieved as follows

import chalk from 'chalk';
import { getContent, getCss } from '../../utils/getContent';
import { getPage } from '../../utils/getPage';
import puppeteer from 'puppeteer-core';
import chrome from 'chrome-aws-lambda';

let page;

const isDev = process.env.NODE_ENV === 'development';

const exePath =
  process.platform === 'win32'
    ? 'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe'
    : process.platform === 'linux'
    ? '/usr/bin/google-chrome'
    : '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome';

export const getPage = async () => {
  if (page) {
    return page;
  }

  const getOptions = async () => {
    let options;
    if (isDev) {
      options = {
        args: [],
        executablePath: exePath,
        headless: true,
      };
    } else {
      options = {
        args: chrome.args,
        executablePath: await chrome.executablePath,
        headless: chrome.headless,
      };
    }

    return options;
  };

  const options = await getOptions();
  const browser = await puppeteer.launch({
    ...options,
  });
  page = await browser.newPage();

  return page;
};


export default async function handler(req, res) {
  console.info(chalk.cyan('info'), ` - Generating Opengraph images`);

  const { title, tags, handle, logo, debug, fontFamily, background, fontFamilyUrl } = req.query;

  const css = getCss(fontFamily, fontFamilyUrl, background);
  const html = getContent(tags, title, handle, logo, css);

  if (debug === 'true') {
    res.setHeader('Content-Type', 'text/html');
    res.end(html);
    return;
  }

  try {
    const page = await getPage();
    await page.setViewport({ width: 1200, height: 630 });
    await page.setContent(html, { waitUntil: 'networkidle2', timeout: 15000 });

    await page.evaluateHandle('document.fonts.ready');

    const buffer = await page.screenshot({ type: 'png', clip: { x: 0, y: 0, width: 1200, height: 630 } });

    res.setHeader('Cache-Control', `public, immutable, no-transform, s-maxage=31536000, max-age=31536000`);
    res.setHeader('Content-Type', 'image/png');
    res.end(buffer);
  } catch (error) {
    console.error(error);

    res.statusCode = 500;
    res.setHeader('Content-Type', 'text/html');
    res.end('<h1>Internal Error</h1><p>Sorry, there was a problem</p>');
  }
}

Let's take a closer look at our code.

// getPage

import puppeteer from 'puppeteer-core';
import chrome from 'chrome-aws-lambda';

let page;

const isDev = process.env.NODE_ENV === 'development';

const exePath =
  process.platform === 'win32'
    ? 'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe'
    : process.platform === 'linux'
    ? '/usr/bin/google-chrome'
    : '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome';

export const getPage = async () => {
  if (page) {
    return page;
  }

  const getOptions = async () => {
    let options;
    if (isDev) {
      options = {
        args: [],
        executablePath: exePath,
        headless: true,
      };
    } else {
      options = {
        args: chrome.args,
        executablePath: await chrome.executablePath,
        headless: chrome.headless,
      };
    }

    return options;
  };

  const options = await getOptions();
  const browser = await puppeteer.launch({
    ...options,
  });
  page = await browser.newPage();

  return page;
};

Our getPage function launches the browser and gives us a reference to the browser page. To take a screenshot, we're using the puppeteer-core and chrome-aws-lambda package. If you don't know what puppeteer and chrome-aws-lambda are. Refer to the official docs link in the reference section.

Reference

export const getAbsoluteURL = (path) => {
  const baseURL = process.env.VERCEL_URL ? `https://${process.env.VERCEL_URL}` : 'http://localhost:3000';
  return baseURL + path;
};

// getCss

export const getCss = (fontFamily, fontFamilyUrl, background) => {
  return `
    ${fontFamilyUrl ?? "@import url('https://fonts.googleapis.com/css2?family=Nunito:wght@400;600&display=fallback');"}

    * {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
    font-family: ${
      fontFamily ?? 'Nunito'
    }, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, 'Open Sans','Helvetica Neue', sans-serif;
    color: white;
    }

    .container {
    width: 1200px;
    height: 630px;
    background: ${background ? background :  `url(${getAbsoluteURL('/ogbackground.svg')})`};
    padding:3rem;
    margin:0 auto;
    display: flex;
    flex-direction:column;
    }

    .content {
    padding: 3rem 5rem;
    display: flex;
    flex: 1;
    flex-direction: column;
    justify-content: space-between;
    }

    .title {
    display: flex;
    align-items: center;
    justify-content: center;
    max-width: 840px;
    flex: 1;
    margin:0 auto;
    text-align: center;
    }

    .title > h1 {
    font-size: 64px;
    line-height: 74px;
    font-weight: 600;
    font-style: normal;

    }

    .logo {
    justify-content: space-between;
    display: flex;
    align-items: center;
    padding: 1rem 3rem;
    }

    .tags {
    font-size: 1rem;
    display: flex;
    gap: 10px;
    justify-content: center;
    padding: 2rem 0;
    }

    .pill{
      background: #caa8ff33;
      color: white;
      padding: 0.25rem 1rem;
      border-radius: 50rem;
      text-transform: capitalize;
      box-shadow: 0 0 1rem rgba(0,0,0,0.1);
      font-weight: bold;
    }

    .handle{
      font-size: 24px;
      font-weight: 600;
    }

    `;
};

Our getCss function gets all the styles of our og card. It'll take three optional parameters to generate CSS.

// getContent
export const getContent = (tags, title, handle, logo, css) => {
  return `
    <html>
    <meta charset="utf-8">
    <title>Generated Image</title>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <style>
       ${css}
    </style>
    <body>
        <div class='container'>

        <div class="content">
            <div class="title"><h1>${title ?? 'Welcome to this site'}</h1></div>
            ${
              tags
                ? `<div class="tags">
                  ${tags
                    .split(',')
                    .map((tag) => {
                      return `<span key=${tag} class="pill">${tag}</span>`;
                    })
                    .join('')}
                </div>`
                : ''
            }

        </div>
        <div class="logo">
            <img src="${logo ?? getAbsoluteURL(`/logo.svg`)}" alt="logo" width="100px" height="100px" >
            <div class="handle">${handle ?? '@Jana__Sundar'}</div>
        </div>
        </div>
    </body>
    </html>`;
};

Our getContent function generate Html based on the CSS, title, twitter handle, logo, and tags.

Generally, the most recommended dimensions to generate an OG image is 1200 x 630. These are not the perfect values. Check this link to find the different recommendations.

Reference

https://iamturns.com/open-graph-image-size/

  try {
    const page = await getPage();
    await page.setViewport({ width: 1200, height: 630 });
    await page.setContent(html, { waitUntil: 'networkidle2', timeout: 15000 });

    await page.evaluateHandle('document.fonts.ready');

    const buffer = await page.screenshot({ type: 'png', clip: { x: 0, y: 0, width: 1200, height: 630 } });

    res.setHeader('Cache-Control', `public, immutable, no-transform, s-maxage=31536000, max-age=31536000`);
    res.setHeader('Content-Type', 'image/png');
    res.end(buffer);
  } catch (error) {
    console.error(error);

    res.statusCode = 500;
    res.setHeader('Content-Type', 'text/html');
    res.end('<h1>Internal Error</h1><p>Sorry, there was a problem</p>');
  }

Now, we need to pass the generated Html to the set content function then take a screenshot by calling the screenshot function from puppeteer with filetype. Return the buffer value from the screenshot and send it as a response.

Reference

This project is open-source on GitHub. Have a closer look if you want.

Hopefully, you have learned how to generate a dynamic OG image. If you have any doubts, you can reach me at mailtojanasundar@gmail.com. Thanks for reading ✌️ and if you enjoyed this article, share it with your friends and colleagues.

How I built my blog with NextJs

JanaSundar — Fri, 02 Jul 2021 11:53:29 +0000

This post was originally published at janasundar.dev

Introduction

In this article, I'll guide you through all the tools and packages that I used in this blog. I'll also provide all the blog post links that I used as reference while creating this blog.

The Tech Stack used in this blog are NextJs, Chakra UI, MDX, Graph CMS

Next Js

Next Js is a react framework that offers SSG(static site generation) and SSR(server-side rendering).

SSG is used to create a static page. These pages are prefetched during the build time and use the static page until the next build. Pages like about us, contact us, and blog posts.

SSR is a technique where we process web pages on a server by prefetching after which the rendered HTML is passed to the browser. SSR allows our webpage to load quickly and increases user experience. SSR helps to increase the SEO scores as well.

Reference

Next.js by Vercel - The React Framework

Chakra UI

I used Chakra UI to style everything. It is a customisable, and reusable component-based library for reactjs. It follows the WAI-ARIA guidelines. Let's look at how to install and configure Chakra UI

Installing Chakra UI

If you don't have a yarn package manager installed, install it by going to official site. Once you have it installed, run the below command to install Chakra UI

yarn add @chakra-ui/react @emotion/react @emotion/styled framer-motion

Configuring Chakra UI

After installing the chakra UI and its dependencies, we need to wrap our parent component with ChakraProvider component. Now, all the components present inside our parent can access the chakra UI components.

//pages/_app.tsx
import { ChakraProvider } from "@chakra-ui/react"
function MyApp({ Component, pageProps }) {
return (
    <ChakraProvider>
        <Component {...pageProps} />
    </ChakraProvider>
    )
}
export default MyApp

Creating custom themes

To override the default theme, we need to import the extendTheme function from @chakra-ui/react package.

import { extendTheme } from "@chakra-ui/react"

const theme = extendTheme({ colors: { brand: { 100: "#f7fafc", 900: "#1a202c", }, }, })

export default theme

Then import the custom theme from the theme.js file to _app.js and pass the new theme to chakraProvider

<ChakraProvider theme={theme}>
  <App />
</ChakraProvider>

Now these custom themes are available in your component.

function Usage() {
  return <Box bg="brand.100">Welcome</Box>
}

MDX

MDX is the extension of markdown that allows you to write React Component inside markdown file. Markdown is a markup language with plain text formatting syntax. It flawlessly converts text to HTML.

The data for the blog posts are written in markdown and served from GraphCMS. I used mdx-bundler to compile the mdx code. Josh Comeau recommended this package in his blog post.

To compile the MDX code, we need to import the bundleMDX function from mdx-bundler. As a result, we'll get the code and frontmatter of the MDX file. It has inbuilt support for xdm configuration. It allows us to use the remark and rehype plugins.

import {bundleMDX} from 'mdx-bundler'

bundleMDX(mdxString, { xdmOptions(options) { options.remarkPlugins = [...(options.remarkPlugins ?? []), myRemarkPlugin] options.rehypePlugins = [...(options.rehypePlugins ?? []), myRehypePlugin] return options }, })

To use the bundled MDX, we need to import the getMDXComponent function from mdx-bundler/client.

 import {getMDXComponent} from 'mdx-bundler/client' function MDXPage({code}) { const Component = React.useMemo( () => getMDXComponent(result.code), [result.code], )

return ( <main> <Component /> </main> ) }

Reference

https://github.com/kentcdodds/mdx-bundler

Graph CMS

Graph CMS is the headless CMS based on GraphQL Content API and delivers your content across platforms. The data for the blog posts are coming from Graph CMS. It has a lifelong free personal account with sufficient amount of data transfer limit. For further reference regarding pricing, visit the pricing page.

Getting Started With Graph CMS

Now, we will create a new project and assign it the name and description. Then set the region near to you. It's where our content will be.

Graph CMS sets all the project dependencies, and it'll take us to the dashboard page. For creating a new model, navigate to the schema section and click the add button to add a new Model. Inside the model, we need to add all the fields.

Now, we can start adding the content for our created model by navigating to the content section. By Clicking a create item button, we'll add new content for our model.

Add assets to our model, use the asset model it is the default system model present in the CMS. It supports all file formats.

To access data from API call, go to the endpoints section, which is present inside settings, then add data access permissions.

To fetch the data, copy the content API URL to access content from the graphQL call.

Pass the content URL to graphQL client to query data from Graph CMS. It looks like this

const client = new GraphQLClient(process.env.GRAPH_CMS_CONTENT\_API);

const query =gql`
    query Posts($slug: String!) {
    post(where: { slug: $slug }) {
        content
        files
            tags {
               tag  
            }   
        }   
    }
`;

const { post } = await client.request(query, { slug });

Reference

https://www.hostinger.in/tutorials/what-is-a-cms/ https://www.contentful.com/r/knowledgebase/what-is-headless-cms/

Thanks to Amelia Watternberger, Josh Comeau, Kent C Dodds, Brad Traversy, and Maxime Heckel for inspiring me to create my blog.