@leadbot/vue

Vue 3 components for LeadBot: an AI agent chat, lead forms, callback/email requests, a WhatsApp handoff, and a full embedded flow — rendered into your own DOM and styled by your site.

Thin wrapper around @leadbot/components, which is where the theming reference, the token table and the class-name list live. Everything below is what is specific to Vue.

Install

npm install @leadbot/vue

Vue 3 is a peer dependency. The package is SSR-safe: every component renders an empty host <div> on the server and mounts in onMounted.

Usage

// main.ts
import { createApp } from "vue";
import { LeadBot } from "@leadbot/vue";
import "@leadbot/vue/styles.css";
import App from "./App.vue";

createApp(App)
  .use(LeadBot, {
    domainKey: "your-domain-key",
    leadbotId: 18,
  })
  .mount("#app");

<script setup lang="ts">
import { LeadBotAgent, LeadBotCallbackRequest, LeadBotForm } from "@leadbot/vue";
</script>

<template>
  <LeadBotAgent id="chat-step-uuid" initial-message="Hi! How can I help?" />
  <LeadBotCallbackRequest id="callback-step-uuid" />
  <LeadBotForm id="form-step-uuid" event-label="Homepage form" />
</template>

provideLeadBot(config) is the Composition-API alternative to the plugin, for scoping the configuration to one subtree.

import "@leadbot/vue/styles.css" is the default look; skip it entirely and style the plain light-DOM markup yourself. Both spellings resolve to the same stylesheet, but import it from the package you installed — importing @leadbot/components/styles.css only works while npm happens to hoist the transitive dependency, and breaks under pnpm's strict layout or Yarn PnP.

Configuration precedence

A prop on the component always wins over the plugin config. Every LeadbotComponentsConfig key (domainKey, apiHost, leadbotId, path, language, baseColor, preview, previewToken, debug) can be set in either place; app.use(LeadBot, …) (or provideLeadBot) is the default for everything under it, and a component that sets the same prop overrides it for itself only.

<LeadBotAgent id="chat-step-uuid" />                <!-- plugin's leadbotId -->
<LeadBotForm id="form-step-uuid" :leadbot-id="22" /><!-- 22 -->

So there is no need to repeat leadbot-id on every component — set it once in the plugin config, and override it only where a component belongs to a different bot.

Components

| Component | Renders | |---|---| | LeadBotAgent | AI agent chat | | LeadBotForm | Published lead form | | LeadBotCallbackRequest | Callback request (name + phone) | | LeadBotEmailRequest | Email request (name + email + message) | | LeadBotWhatsApp | WhatsApp handoff | | LeadBotFlow | A whole bot conversation, inline |

Forms also accept declarative fields — TextField, EmailField, PhoneField, NumberField, TextAreaField, SelectField, CheckboxField, RadioListField, CheckListField — as children, instead of the published form's fields.

Published steps

Every component is backed by a published step: id is that step's uuid, and the dashboard configures the component through it (fields, labels, WhatsApp number, agent). The flow is fetched once per bot per page and shared by every component; that request is also what counts the pageview.

Because the published flow is the source of truth, unpublishing a bot removes its components from every page. On localhost — or with debug — a component whose id matches no published step renders a visible placeholder instead of nothing.

Language

Components speak the language of the bot as published, which arrives with the boot fetch — not the page's <html lang>. Pass a labels object to a component to override any individual string.

Theming

See the @leadbot/components README for the full token table, dark mode, and the stable class names. The short version: override --leadbot-primary (or pass baseColor) in the plugin config or on any ancestor, and write plain unlayered CSS against the .leadbot-* classes to beat any default.

License

MIT