Shrinath Prabhu — Blog

SEO for Vite SPAs Without Next.js

2026-05-05T00:00:00Z

Everyone will tell you the same thing, if you need SEO in a React app, use Next.js. I needed SEO in a React app and I chose not to use Next.js. Here is why, and how I built a custom solution that achieves the same result with dramatically less complexity.

The problem

I was building Nexus Fastbridge at Avail, a cross-chain bridge UI where users swap and bridge assets between rollups. The app needed individual, search-engine indexable pages for each supported chain. When someone searches “bridge to Arbitrum” or “Optimism bridge,” our chain-specific page should appear in results with proper titles, descriptions, and Open Graph images.

A standard Vite + React SPA renders everything client-side. When Google’s crawler or a social media link preview bot hits the page, it sees an empty <div id="root"></div> and a JavaScript bundle. No title, no description, no Open Graph tags. The page is invisible to search engines and renders a blank preview on Twitter and Slack.

The obvious solution is Next.js. It builds static sites or server-renders pages on request, giving crawlers fully rendered HTML. But Next.js brings significant overhead that I did not want for this project.

Why I did not use Next.js

This is not an anti Next.js take. Next.js is a great framework for many use cases. But for Fastbridge specifically, it was the wrong tool for three reasons.

First, the bridge UI is a highly interactive, state-heavy application. Transaction status polling, real-time balance updates, wallet connection state, chain switching, all of this is client-side logic that does not benefit from server rendering. The “page” is really an app, and the only thing that needs to be server-friendly is the initial HTML shell with meta tags.

Second, deploying a Next.js app means running a Node.js server or using Vercel’s serverless functions. Our infrastructure was already set up for static deployment on Vercel. Adding a server runtime for the sole purpose of rendering meta tags felt like driving a truck to deliver a letter.

Third, the development experience. Vite’s hot module replacement is near-instant. Next.js has improved significantly, but the development feedback loop for a complex SPA is still faster with Vite. For a small frontend team, developer velocity matters.

So I needed a way to get proper <title>, <meta>, and Open Graph tags into the initial HTML, but only for specific chain pages, and without a server runtime.

The solution: a post-build script

The core idea is simple: after Vite builds the SPA, a Node.js script reads the generated index.html, creates a copy for each chain with that chain’s specific meta tags injected, and writes each copy into a slug-based directory. When a crawler or link preview bot hits /arbitrum, Vercel serves the pre-built arbitrum/index.html with correct meta tags. Then the React SPA hydrates and takes over as a normal client-side app.

Not a Vite plugin. Not a framework. A single .mjs script that runs after vite build.

{
  "scripts": {
    "build": "vite build && node scripts/generate-route-html.mjs"
  }
}

Here is how it works step by step.

Step 1: Define the chain metadata

Each chain has a slug, title, description, OG image URL, canonical URL, theme color, and favicon. This is the single source of truth for all SEO content:

const CHAIN_META = [
  {
    slug: "arbitrum",
    title:
      "Arbitrum FastBridge by Avail | Unified Cross-Chain Swaps and Transfers on Arbitrum",
    description:
      "Bridge USDC, USDT, ETH, and other tokens from major EVM chains to Arbitrum in one transaction. FastBridge is a fast, secure cross-chain bridge powered by Avail Nexus.",
    imageUrl: "https://cdn.dev/nexus/meta/arbitrum.jpg",
    canonicalUrl: "https://fastbridge.availproject.org/arbitrum/",
    themeColor: "#0164E9",
    faviconUrl: "/avail_logo.svg",
  },
  {
    slug: "ethereum",
    title:
      "Ethereum FastBridge by Avail | Unified Cross-Chain Swaps and Transfers on Ethereum",
    description:
      "Bridge USDC, USDT, ETH, and other tokens from major EVM chains to Ethereum in one transaction. FastBridge is a fast, secure cross-chain bridge powered by Avail Nexus.",
    imageUrl: "https://cdn.dev/nexus/meta/ethereum.jpg",
    canonicalUrl: "https://fastbridge.availproject.org/ethereum/",
    themeColor: "#8891AE",
    faviconUrl: "/avail_logo.svg",
  },
  // ... 11 more chains (MegaETH, Monad, Citrea, Polygon, Base,
  //     OP Mainnet, Scroll, Kaia, BNB Smart Chain, HyperEVM, Avalanche)
];

We currently support 13 chains. Adding a new one means adding an object to this array and running the build. No framework changes, no routing configuration, no new components.

Step 2: Regex-based meta tag injection

The script reads the built index.html from the dist directory and replaces every meta tag using regex patterns. This is more robust than simple string replacement because it matches the tag structure regardless of the exact content that Vite’s build process inserts:

const RE_TITLE = /<title>[^<]*<\/title>/;
const RE_CANONICAL = /<link rel="canonical"[^>]*>/;
const RE_THEME_COLOR = /<meta name="theme-color"[^>]*>/;
const RE_META_DESCRIPTION = /<meta\s+name="description"[^>]*>/;
const RE_OG_TITLE = /<meta\s+property="og:title"[^>]*>/;
const RE_OG_DESCRIPTION = /<meta\s+property="og:description"[^>]*>/;
const RE_OG_URL = /<meta\s+property="og:url"[^>]*>/;
const RE_OG_IMAGE = /<meta\s+property="og:image"[^>]*>/;
const RE_TWITTER_TITLE = /<meta\s+name="twitter:title"[^>]*>/;
const RE_TWITTER_DESCRIPTION = /<meta\s+name="twitter:description"[^>]*>/;
const RE_TWITTER_IMAGE = /<meta\s+name="twitter:image"[^>]*>/;
const RE_TWITTER_SITE = /<meta\s+name="twitter:site"[^>]*>/;
const RE_ITEMPROP_IMAGE = /<meta\s+itemprop="image"[^>]*>/;
const RE_FAVICON = /<link\s+rel="icon"[^>]*>/;

function injectMeta(baseHtml, chain) {
  const { title, description, imageUrl, canonicalUrl, themeColor, faviconUrl } =
    chain;

  return baseHtml
    .replace(RE_TITLE, `<title>${title}</title>`)
    .replace(RE_CANONICAL, `<link rel="canonical" href="${canonicalUrl}">`)
    .replace(
      RE_FAVICON,
      `<link rel="icon" href="${faviconUrl}" type="image/svg+xml">`,
    )
    .replace(
      RE_THEME_COLOR,
      `<meta name="theme-color" content="${themeColor}">`,
    )
    .replace(
      RE_META_DESCRIPTION,
      `<meta name="description" content="${description}">`,
    )
    .replace(RE_OG_TITLE, `<meta property="og:title" content="${title}">`)
    .replace(
      RE_OG_DESCRIPTION,
      `<meta property="og:description" content="${description}">`,
    )
    .replace(RE_OG_URL, `<meta property="og:url" content="${canonicalUrl}">`)
    .replace(RE_OG_IMAGE, `<meta property="og:image" content="${imageUrl}">`)
    .replace(RE_ITEMPROP_IMAGE, `<meta itemprop="image" content="${imageUrl}">`)
    .replace(RE_TWITTER_TITLE, `<meta name="twitter:title" content="${title}">`)
    .replace(
      RE_TWITTER_DESCRIPTION,
      `<meta name="twitter:description" content="${description}">`,
    )
    .replace(
      RE_TWITTER_IMAGE,
      `<meta name="twitter:image" content="${imageUrl}">`,
    )
    .replace(
      RE_TWITTER_SITE,
      `<meta name="twitter:site" content="${canonicalUrl}">`,
    );
}

Every meta tag that matters for SEO and social previews gets replaced: title, description, canonical URL, Open Graph (title, description, URL, image), Twitter Card (title, description, image, site), theme color, favicon, and even itemprop="image" for Google’s structured data. That is 14 replacements per chain, all using regex to match tag structure rather than exact content strings.

Step 3: Generate files and sitemap

The main loop reads the built index.html, runs the injection function for each chain, and writes the output to a slug-based directory:

const distDir = path.resolve(__dirname, "../apps/root/dist");
const baseHtml = fs.readFileSync(path.join(distDir, "index.html"), "utf-8");

for (const chain of CHAIN_META) {
  const outDir = path.join(distDir, chain.slug);
  fs.mkdirSync(outDir, { recursive: true });
  fs.writeFileSync(
    path.join(outDir, "index.html"),
    injectMeta(baseHtml, chain),
    "utf-8",
  );
}

The script also generates a sitemap.xml in the same pass, listing all chain pages alongside static pages (homepage, FAQ, contact) with appropriate priority values:

const allUrls = [
  { loc: `${baseUrl}/`, priority: "1.0" },
  { loc: `${baseUrl}/faq`, priority: "0.8" },
  { loc: `${baseUrl}/contact`, priority: "0.8" },
  ...CHAIN_META.map((chain) => ({
    loc: chain.canonicalUrl,
    priority: "0.9",
  })),
];

One script. Generates 13 chain-specific HTML files plus a sitemap. Runs in under a second.

Step 4: Vercel routing

This is where the approach differs from “just deploy static files.” Vercel does not automatically route /arbitrum to /arbitrum/index.html in a SPA context, as the SPA’s catch-all route would intercept it first. We need explicit rewrite rules in vercel.json:

{
  "rewrites": [
    {
      "source": "/:slug(megaeth|monad|citrea|arbitrum|ethereum|polygon|base|op-mainnet|scroll|kaia|bnb-smart-chain|hyperevm|avalanche)",
      "destination": "/:slug/index.html"
    },
    {
      "source": "/:slug(megaeth|monad|citrea|arbitrum|ethereum|polygon|base|op-mainnet|scroll|kaia|bnb-smart-chain|hyperevm|avalanche)/(.*)",
      "destination": "/:slug/index.html"
    },
    {
      "source": "/(.*)",
      "destination": "/"
    }
  ]
}

The first rewrite catches exact chain slugs and serves the pre-built HTML. The second catches any nested paths under a chain slug. The third is the SPA fallback, everything else goes to the root index.html where React Router handles client-side routing.

The order matters. Vercel evaluates rewrites top to bottom. Chain-specific routes match first and get the SEO-optimized HTML. Everything else falls through to the SPA. Crawlers and link preview bots always hit the first or second rule and receive fully-formed meta tags. Users navigating within the app hit the third rule after initial load and get the standard SPA experience.

Step 5: Client-side routing

On the client side, React Router handles navigation normally. When a user lands on /arbitrum, the pre-built HTML loads with Arbitrum-specific meta tags, theme color, and favicon. Then the React app mounts and React Router takes over. Subsequent navigation between chains happens client-side without page reloads, the user gets the SPA experience while crawlers get the static HTML experience.

The key insight is that the generated HTML files all load the same JavaScript bundle. The chain-specific content is only in the <head> meta tags. The <body> is identical across all generated pages, it contains the same <div id="root"></div> and the same script tags. React mounts, reads the current URL, and renders the correct chain UI.

A note on the monorepo structure

Fastbridge uses a monorepo with the main app living at apps/root/. The Vite config sets outDir: "apps/root/dist" and the post-build script resolves its paths relative to this directory. This means the script works regardless of where it is called from in the monorepo, it always finds the right dist/index.html and writes the chain directories alongside it. If you are adapting this pattern for a simpler project structure, just change the distDir path to your build output directory.

Why a post-build script and not a Vite plugin?

The chain metadata config in the actual codebase lives in a TypeScript file that imports from npm packages (@avail-project/nexus-core). A Vite plugin runs during the build process where these imports are resolved, but a standalone Node script running after the build cannot directly import TypeScript with npm dependencies without its own build step. So the script maintains a plain JavaScript mirror of the chain metadata.

This is a deliberate tradeoff: a tiny bit of duplication (keeping the JS mirror in sync with the TS source) in exchange for zero build complexity. The script is a plain .mjs file that runs with node, no TypeScript compilation, no bundling, no dependencies beyond node:fs and node:path. When a new chain is added to the TypeScript config, the corresponding entry gets added to the script’s CHAIN_META array. It is a manual step, but it happens maybe once a month and takes 30 seconds.

A Vite plugin approach would eliminate the duplication but add complexity. For 13 chains that change infrequently, the simple approach wins.

What this approach handles

Search engine indexing. Googlebot hits /arbitrum, receives a fully formed HTML page with a proper <title>, meta description, canonical URL, and structured data. It indexes the page correctly. All 13 chain pages are individually discoverable in search results.

Social media link previews. When someone shares fastbridge.availproject.org/arbitrum on Twitter, Slack, or LinkedIn, the preview bot reads the Open Graph tags from the static HTML. Correct title, description, image, and even theme color render in the preview card. Each chain gets its own branded OG image and color scheme.

Performance. The page loads as a static HTML file, there is no server-side rendering step, no cold start, no compute cost per request. It is as fast as serving a static site can be. Landing assets get year-long immutable cache headers.

Development simplicity. No SSR hydration mismatches to debug. No server/client code splitting to manage. No getServerSideProps or getStaticProps to maintain. The entire SEO infrastructure is a single script under 200 lines, a Vercel config, and a build command.

What this approach does NOT handle

Dynamic SEO content. If you need meta tags that change based on real-time data (like a product page showing current price or inventory), this approach does not work, you need actual server rendering. Fastbridge’s chain data is relatively static (chain names and descriptions do not change every hour), so build-time generation is fine.

Pages that do not exist at build time. If you have user-generated content where new pages are created dynamically, you cannot generate HTML for them at build time. But for a known set of 13 chains, this is not a problem.

Full content indexing. Google will see the meta tags and a mostly empty body. If you need Google to index the actual page content (not just the title and description), you need SSR or pre-rendering. For Fastbridge, indexing the meta tags is sufficient, users do not search for the content inside the bridge UI, they search for “bridge to Arbitrum.”

Adding a new chain

The entire process for adding a new chain’s SEO page:

Add the chain entry to the TypeScript config (the app’s source of truth)
Add a matching entry to CHAIN_META in the post-build script
Add the chain slug to the Vercel rewrite regex pattern
Create the chain’s OG image and upload it to the CDN
Run npm run build

Five steps. No framework changes, no new routes to configure, no new components to create, no deployment configuration beyond updating the rewrite pattern. The build generates the new chain’s HTML automatically.

When to use this pattern

This approach works well when you have a known, finite set of pages that need SEO (chain pages, product categories, landing pages), when your content is relatively static and can be defined at build time, when you want to keep the simplicity of a Vite SPA without adding a framework, and when you are deploying to a static hosting platform like Vercel, Netlify, or Cloudflare Pages.

If you have hundreds of dynamic pages with frequently changing content, use Next.js or Astro. If you have 10-50 mostly-static pages that need meta tags, this post-build script approach is simpler, faster, and has zero runtime cost.

The result

Fastbridge’s 13 chain pages are fully indexed by Google with correct titles and descriptions. Social media previews render properly with chain-specific branding. The auto-generated sitemap keeps search engines up to date. The development experience remains pure Vite with fast HMR, simple build, and no SSR complexity. And the entire SEO infrastructure is a single post-build script, a Vercel config, and a one-line addition to package.json.

Sometimes the best architecture decision is the one that avoids adding complexity.

View Fastbridge →

Written by Shrinath Prabhu, Senior Staff Frontend Engineer at Avail Project. I build products from zero to launch with Vue, React, and TypeScript. More case studies at shrinath.me/work.

Vue 3 Composition API: Basics and Patterns

2023-06-15T00:00:00Z

Originally published on the Arcana Network Blog in April 2022. Updated in April 2026 with modern patterns, <script setup> as the default syntax, and insights from 5 years of production Vue development.

The Composition API is how you write Vue in 2026. It is not an alternative to learn alongside another approach, it is the standard. Every major Vue ecosystem tool (Nuxt 3, VueUse, Pinia, Vuetify 3) is built on it, and every new Vue project should use it by default.

I have been using Vue professionally for over 5 years, building a Chrome Extension wallet, a developer dashboard, a cross-chain transfer app, and several other production applications. The Composition API fundamentally changed how I organize frontend code, and this guide covers the patterns I actually use every day.

Why the Composition API works

The core idea is simple: group code by what it does, not where Vue’s structure says it should go.

In a complex component say, an authentication configuration panel where a developer selects social login providers, sets redirect URLs, and previews the login flow, the logic for each of these features naturally involves some reactive state, a few methods, maybe a watcher, and a lifecycle hook. The Composition API lets you keep all of that together as a single logical block, or extract it into a reusable function called a composable.

The practical benefits after years of using it in production:

Readable components: When you revisit a 300-line component after 6 months, you can immediately find the search logic, the pagination logic, and the filter logic because each is a self-contained block, not scattered across different sections of the file.
Reusable logic: Composables let you extract and share stateful logic across components without the problems that mixins had (name conflicts, unclear data origins, no parameterization).
TypeScript integration: Vue 3 is written in TypeScript, and the Composition API was designed for full type inference. Your editor knows the types of your refs, computed properties, and composable return values without manual annotation.
Smaller bundles: Better tree-shaking support means unused APIs are not included in your production build.

The standard syntax: `<script setup>`

The <script setup> attribute is the recommended way to write Composition API components. It eliminates boilerplate, no setup() function, no return statement, no export default. Everything declared at the top level is automatically available in the template.

CounterExample.vue

<script setup>
import { ref, onMounted } from "vue";

// Reactive state
const count = ref(0);

// Methods
const increment = () => {
  count.value++;
};

// Lifecycle hooks
onMounted(() => {
  console.log("Component is ready!");
});
</script>

<template>
  <button @click="increment">Count is: </button>
</template>

Clean and minimal. The template has access to count and increment without you explicitly returning them. This is how you can write a new component.

Composables: reusable stateful logic

Composables are functions that encapsulate reactive state and logic. They are the replacement for mixins, and they solve every problem mixins had. By convention, composable names start with use.

Here is a basic example of a reusable counter:

useCounter.js

import { ref, computed } from "vue";

export function useCounter(initialValue = 0) {
  // Types are automatically inferred
  const count = ref(initialValue);
  const doubleCount = computed(() => count.value * 2);

  function increment() {
    count.value++;
  }

  function decrement() {
    count.value--;
  }

  function reset() {
    count.value = initialValue;
  }

  return { count, doubleCount, increment, decrement, reset };
}

Using it in a component:

CounterExample.vue

<script setup>
import { useCounter } from "./useCounter";

const { count, doubleCount, increment } = useCounter(10);
</script>

<template>
  <p>Value:  (Double: )</p>
  <button @click="increment">+1</button>
</template>

This pattern solves three real problems:

No name conflicts: Since you destructure what you need from the composable, there is no ambiguity about where a variable comes from. You can even use the same composable multiple times:

MultipleCounterExample.vue

<script setup>
import { useCounter } from "./useCounter";

const { count: likes, increment: addLike } = useCounter(0);
const { count: views, increment: addView } = useCounter(0);
</script>

Each instance maintains its own independent state. Something which mixins could not achieve.

Clear data origins: When a component uses three composables, every variable is explicitly imported and destructured. Six months later, you know exactly where isLoading comes from, it is not magically merged from some mixin buried in a different folder.

Parameterization: Composables accept arguments. You can pass initial values, configuration objects, API endpoints, or callback functions. Mixins could not do this, they were rigid, static blocks of logic.

What the Composition API exposes

The API surface is small and focused. Here is what you will use daily:

Reactivity

ref() creates a reactive reference for any value. Access and mutate via .value in JavaScript; the template unwraps it automatically.

UserProfile.vue

const name = ref("Shrinath");
console.log(name.value); // 'Shrinath'
name.value = "Updated";

reactive() creates a reactive object without the .value wrapper. Useful for complex state objects, but I recommend sticking to ref() for consistency. After 5+ years of using Vue, I use ref() for everything including objects. The mental model of “always use .value” is simpler than remembering which variables need it and which do not.

UserProfile.vue

// I prefer this:
const user = ref({ name: "Shrinath", role: "engineer" });
user.value.name = "Updated";

// Over this:
const user = reactive({ name: "Shrinath", role: "engineer" });
user.name = "Updated";

computed() derives reactive state that updates automatically when its dependencies change. Computed values are cached, they only get recalculated when dependencies change.

FullName.vue

const firstName = ref("Shrinath");
const lastName = ref("Prabhu");
const fullName = computed(() => `${firstName.value} ${lastName.value}`);

Watchers

watch() runs a callback when specific reactive sources change. Use it for side effects like API calls, localStorage updates, or analytics tracking.

SearchInput.vue

const searchQuery = ref("");

watch(searchQuery, async (newQuery, oldQuery) => {
  if (newQuery.length > 2) {
    const results = await fetchResults(newQuery);
    searchResults.value = results;
  }
});

watchEffect() automatically tracks every reactive dependency used inside its body. It runs immediately on setup and re-runs whenever any dependency changes. More concise than watch() when you do not need the old value.

SearchInput.vue

watchEffect(() => {
  console.log(`Search query is: ${searchQuery.value}`);
  // Automatically re-runs when searchQuery changes
});

One gotcha from production experience: be careful with watchEffect() and reactive dependencies that you also modify inside the callback. If the watcher reads and writes the same ref, you get an infinite loop. Use watch() with explicit sources when the callback needs to mutate watched state.

Lifecycle hooks

The Composition API lifecycle hooks mirror the component lifecycle but are called inside <script setup>:

AppLifecycle.vue

import { onMounted, onUnmounted, onUpdated } from "vue";

onMounted(() => {
  // DOM is ready, fetch data, set up event listeners
  window.addEventListener("resize", handleResize);
});

onUnmounted(() => {
  // Clean up event listeners, cancel timers, close connections
  window.removeEventListener("resize", handleResize);
});

Dependency injection

provide() and inject() enable deep component tree communication without prop drilling. This is how you pass theme configuration, authentication state, or API clients through your component tree.

// Parent component
import { provide, ref } from "vue";

const theme = ref<"light" | "dark">("dark");
provide("theme", theme);

// Any descendant component, no matter how deep
import { inject } from "vue";

const theme = inject("theme");

This is cleaner than passing props through 5 levels of intermediate components that do not use the data themselves. However in my experience I haven’t had many cases where I had to use these DI patterns.

TypeScript integration

Vue 3 was built with TypeScript, and the Composition API makes type safety straightforward. Props and emits use type-only declarations:

<script setup lang="ts">
interface Props {
  title: string;
  isActive?: boolean;
  tags?: string[];
}

// Props are fully typed — your editor autocompletes prop names
const props = withDefaults(defineProps<Props>(), {
  isActive: false,
  tags: () => [],
});

// Emits are typed — calling emit('update') without the id argument is a compile error
const emit = defineEmits<{
  update: [id: number];
  delete: [id: number, reason: string];
}>();
</script>

withDefaults() provides default values for optional props while preserving type inference. The defineEmits syntax with tuple types (introduced in Vue 3.3) is cleaner than the older function signature style.

Refs are automatically typed from their initial value, but you can explicitly type them when needed:

const count = ref(0); // type: Ref<number>
const user = ref<User | null>(null); // explicit type for nullable refs

const items = ref<string[]>([]); // typed array

Composable patterns from production

Beyond the basic counter example, here are patterns I use in real applications.

Async data fetching

import { ref, watchEffect } from "vue";

export function useFetch<T>(url: () => string) {
  const data = ref<T | null>(null);
  const error = ref<string | null>(null);
  const loading = ref(false);

  watchEffect(async () => {
    loading.value = true;
    error.value = null;
    try {
      const response = await fetch(url());
      if (!response.ok) throw new Error(`HTTP ${response.status}`);
      data.value = await response.json();
    } catch (e) {
      error.value = e instanceof Error ? e.message : "Unknown error";
    } finally {
      loading.value = false;
    }
  });

  return { data, error, loading };
}

Usage:

<script setup>
import { useFetch } from "./useFetch";

const { data: users, loading, error } = useFetch(() => "/api/users");
</script>

<template>
  <div v-if="loading">Loading...</div>
  <div v-else-if="error">Error: </div>
  <ul v-else>
    <li v-for="user in users" :key="user.id"></li>
  </ul>
</template>

Debounced search

import { ref, watch } from "vue";

export function useDebouncedRef<T>(initialValue: T, delay = 300) {
  const value = ref(initialValue) as Ref<T>;
  const debouncedValue = ref(initialValue) as Ref<T>;
  let timeout: ReturnType<typeof setTimeout>;

  watch(value, (newVal) => {
    clearTimeout(timeout);
    timeout = setTimeout(() => {
      debouncedValue.value = newVal;
    }, delay);
  });

  return { value, debouncedValue };
}

Local storage persistence

import { ref, watch } from "vue";

export function useLocalStorage<T>(key: string, defaultValue: T) {
  const stored = localStorage.getItem(key);
  const value = ref<T>(stored ? JSON.parse(stored) : defaultValue);

  watch(
    value,
    (newVal) => {
      localStorage.setItem(key, JSON.stringify(newVal));
    },
    { deep: true },
  );

  return value;
}

Usage:

<script setup>
const theme = useLocalStorage("theme", "light");
// Automatically persists to localStorage on every change
</script>

Quick reference

API	When to use
`ref()`	Any reactive value, primitives and objects
`reactive()`	Use instead of ref() for objects only
`computed()`	Derived state that should cache and auto-update
`watch()`	Side effects when you need old + new values
`watchEffect()`	Side effects that autotrack dependencies
`onMounted()`	DOM access, data fetching, event listeners
`onUnmounted()`	Cleanup, remove listeners, cancel timers
`provide() / inject()`	Deep component tree data passing

Summary

The Composition API is about organizing code by logical concern rather than by framework convention. Start with <script setup> for every new component. Extract repeated patterns into composables. Use ref() for everything (yes, even objects). Type your props and emits. And when a component starts feeling too long, that is your signal to extract a composable, not to add more sections to a growing file.

For detailed case studies of applications I have built with Vue 3, including a Chrome Extension wallet supporting 13 blockchains and a SendIt, visit shrinath.me/work.

Written by Shrinath Prabhu, Senior Staff Frontend Engineer. I build products from zero to launch with Vue, React, and TypeScript. Currently leading frontend architecture at Avail Project.

Shrinath Prabhu — Blog

SEO for Vite SPAs Without Next.js

The problem

Why I did not use Next.js

The solution: a post-build script

Step 1: Define the chain metadata

Step 2: Regex-based meta tag injection

Step 3: Generate files and sitemap

Step 4: Vercel routing

Step 5: Client-side routing

A note on the monorepo structure

Why a post-build script and not a Vite plugin?

What this approach handles

What this approach does NOT handle

Adding a new chain

When to use this pattern

The result

Vue 3 Composition API: Basics and Patterns

Why the Composition API works

The standard syntax: <script setup>

Composables: reusable stateful logic

What the Composition API exposes

Reactivity

Watchers

Lifecycle hooks

Dependency injection

TypeScript integration

Composable patterns from production

Async data fetching

Debounced search

Local storage persistence

Quick reference

Summary

The standard syntax: `<script setup>`