Hoppa till huvudinnehållet

Integrera med en AI-kodningsassistent

Den rekommenderade integrationen är @openstaticfish/chattybox npm-paketet. Det låter applikationskod konfigurera den offentliga nyckeln och API-URL:en, ladda den underhållna flytande ChattyBox-widgeten från en beständig webbläsarlayout eller använda den headless-klienten för ett helt eget gränssnitt.

Det fristående widget.js-skriptet dokumenteras sist som en reservlösning utan byggsteg för webbplatser som inte kan installera npm-paket.

Innan du börjar​

Slutför chattbotens konfiguration innan du ber en assistent redigera din applikation:

  • Verifiera representativa svar och källhänvisningar under Testa chatbot.
  • Under Installera → Nycklar & domäner granskar eller skapar du en offentlig webbläsarnyckel och kontrollerar dess origininställningar. En nyckel som förberetts för en webbplats kan redan vara begränsad; nycklar utan begränsningar fungerar från alla origins. Originbegränsningar är ett valfritt extra skydd och autentiserar inte besökare.
  • Under Installera → Installation på webbplatsen väljer du en lämplig nyckel och kopierar kodsnutten. Använd dess data-api-url om den finns; annars hämtar du rätt widget-HTTP-endpoint från distributionens konfiguration.
  • Avgör om en beständig flytande widget passar i applikationen eller om du behöver ett anpassat gränssnitt med placering och teardown per route.

Detta är offentliga webbläsaruppgifter, men undvik ändå att committa miljöspecifika värden. Ge aldrig en distributions-token för konfiguration, administratörsuppgifter eller en orelaterad miljöfil till assistenten.

Rekommenderas: Montera det underhållna gränssnittet från npm​

Detta är standardprompten för React, Next.js, Vite och andra paketbaserade webbläsarapplikationer.

Instruktion
Integrera ChattyBox npm-paketet

Integrera ChattyBox i den här applikationen med npm-paketet @openstaticfish/chattybox.

Offentlig webbläsarkonfiguration:
- API-nyckel: [PASTE PUBLIC WIDGET KEY]
- API-URL: [PASTE WIDGET API URL]

Använd de aktuella dashboardetiketterna: **Testa chatbot**; **Installera → Nycklar & domäner** för att granska eller skapa en nyckel och dess origininställningar; **Installera → Installation på webbplatsen** för installationssnutten. Originbegränsningar är ett valfritt extra skydd och autentiserar inte besökare; en nyckel som förberetts för en webbplats kan redan vara begränsad. Dela aldrig en konfigurationsdistributions-token, administratörsuppgifter eller en privat miljöfil.

Inspektera först ramverket, routningsmodellen, pakethanteraren, konventionerna för miljövariabler och applikationens beständiga layout. Berätta vilka filer du planerar att ändra innan du redigerar. Fråga mig om rutterna där ChattyBox ska visas är oklara.

Krav:
1. Installera @openstaticfish/chattybox med den pakethanterare som redan används i detta arkiv.
2. Lagra den offentliga API-nyckeln och API-URL:en enligt ramverkets konvention för miljövariabler som exponeras för webbläsaren. Lägg till platshållarnamn i en exempelmiljöfil, men committa inte riktiga värden.
3. Importera Chattybox från @openstaticfish/chattybox och skapa en klient med apiKey och baseUrl.
4. Anropa client.mountWidget() bara i webbläsarkod efter att document.body finns, från ett beständigt applikationsskal. Den laddar en flytande widget under document.body, inte i komponenten.
5. Behåll loadern under tillåtna SPA-navigeringar. Det publicerade SDK:t `0.1.4` delar endast ett skript som SDK:t självt äger när mount-alternativen är identiska; `mountWidget()` avvisar en ändrad nyckel, API-URL, scriptUrl, locale eller debug-inställning medan befintliga handtag finns. Anropa `remove()` på varje returnerat handtag vid avsiktlig teardown. I den aktuella källkoden tar det sista handtaget i den hostade `widget.js` v16 bort widgetens UI/stilar och avbryter väntande initiering, återförsök och pågående chatt; `window.ChattyBox.destroy()` är motsvarigheten för den hostade widgeten. Kontrollera att den distribuerade loader-versionen stöder teardown innan du förlitar dig på det: att dölja UI:t eller bara ta bort skripttaggen räcker inte. Ladda inte före nödvändigt samtycke eller på känsliga/privata rutter; gör aktiv teardown när en rutt undantas eller samtycke återkallas. Teardown kan inte ångra en begäran som servern redan har behandlat.
6. Injicera inte `widget.js` manuellt, skapa ingen backend-proxy och lägg inte till en andra loader. `mountWidget()` delar bara SDK-ägda mounts med identiska alternativ; en ändrad nyckel, API-URL, scriptUrl, locale eller debug-inställning avvisas tills alla befintliga handtag har tagits bort. Den behåller aldrig tyst gamla alternativ.
7. Bevara befintlig navigering, renderingsgränser, lokalisering, analys, samtycken och styling. SDK:t har inget reaktivt locale-API eller ready promise; locale-alternativet följer projektets policy för script-override. Den hostade widgeten i aktuell källkod, `widget.js` v16, kan uppdatera produktägda etiketter när den lösta lokalen ändras; kontrollera den distribuerade loader-versionen och projektets locale-policy innan du förlitar dig på det. Den hostade widgeten i aktuell källkod, `widget.js` v16, schemalägger högst 10 chattförsök inom ett 30-sekundersfönster för schemaläggning av återförsök; detta är inte en hård timeout för en begäran som redan pågår. Kontrollera den distribuerade loader-versionen innan du förlitar dig på widgetens återförsöksbeteende. Headless `sendMessage()` försöker inte automatiskt igen; SDK:ts `getWidgetConfig()` gör separat ett enda fallback-försök efter HTTP 400. Widgetens startup-GET-återförsök är en separat mekanism från chattförsöken. SDK:t validerar `baseUrl` och hanterar oläsbara svarskroppar.
8. Gör den minsta fokuserade ändringen och distribuera den inte.
9. Kör arkivets build, lint, typkontroll och relevanta tester.
10. Rapportera ändrade filer, miljövariabler jag måste ange, var gränssnittet monteras och hur det testas på den distribuerade webbplatsen.

Följande är ett illustrativt callback-exempel för webbläsarens livscykel, inte ett anrop på toppnivå under serverrendering. Anropa det först när document.body finns och spara handtaget för avsiktlig teardown:

import { Chattybox } from '@openstaticfish/chattybox';

const client = new Chattybox({
  apiKey: PUBLIC_CHATTYBOX_API_KEY,
  baseUrl: PUBLIC_CHATTYBOX_API_URL,
});

function mountInBrowserLifecycle() {
  if (typeof document === 'undefined' || !document.body) return;
  return client.mountWidget();
}

// Anropa från en effekt eller livscykelcallback som bara körs i webbläsaren; spara handtaget för teardown.

Bygg ett anpassat gränssnitt​

Välj detta när applikationen själv ska äga meddelandelista, inmatning, laddningstillstånd, fel, källhänvisningar och placering i stället för att montera det underhållna gränssnittet.

Instruktion
Bygg ett headless ChattyBox-gränssnitt

Bygg ett anpassat chattbotgränssnitt med npm-paketet @openstaticfish/chattybox och dess headless-klient.

Offentlig webbläsarkonfiguration:
- API-nyckel: [PASTE PUBLIC WIDGET KEY]
- API-URL: [PASTE WIDGET API URL]

Använd de aktuella dashboardetiketterna: **Testa chatbot**; **Installera → Nycklar & domäner** för att granska nyckeln och dess origininställningar; **Installera → Installation på webbplatsen** för installationssnutten. Originbegränsningar är ett valfritt extra skydd och autentiserar inte besökare; en nyckel som förberetts för en webbplats kan redan vara begränsad. Dela aldrig konfigurationsdistributions-token, administratörsuppgifter eller en privat miljöfil.

Inspektera först applikationens ramverk, komponentsystem, tillståndsmönster, styling, tillgänglighetskonventioner och testkonfiguration. Föreslå komponentgränser och filer innan du redigerar.

Krav:
1. Installera @openstaticfish/chattybox med arkivets befintliga pakethanterare.
2. Konfigurera en Chattybox-klient med apiKey och baseUrl genom webbläsarexponerade miljövariabler; committa inte riktiga värden.
3. Använd `sendMessage()` och behåll `conversationId` i besökar- och sessionsavgränsat tillstånd; nollställ det när användaren eller sessionen ändras. Dela aldrig ett ID mellan orelaterade besökare. Modellen får upp till 12 nyligen sparade meddelanden, vart och ett begränsat till 2 000 tecken, inte hela transkriptet eller permanent minne. Offentliga nycklar, originbegränsningar och konversations-ID:n autentiserar inte besökare eller skyddar privata konversationer. Undvik känsliga uppgifter: meddelanden kan sparas och visas för projektägare; att tömma lokalt tillstånd raderar inte serverposter.
4. Rendera svar säkert som text eller sanerad Markdown och rendera HTTP(S)-källor som tillgängliga länkar i samma ordning. Infoga aldrig otillförlitlig rå HTML eller osäkra länkscheman.
5. Implementera tillstånd för väntan, tomt läge, fel och försök igen. Reservsvar kan sakna källor; det finns ingen allmän `wasAnswered`-flagga. Om backend skickar `providerError`, avgränsa fältet säkert som valfritt och visa ett generiskt leverantörsfel i stället för ett normalt svar. Behandla inte en redan slutförd idempotent begäran som ett transportfel och spela inte upp den blint. Publicerat SDK `0.1.4` kanske inte typdeklarerar markörer från aktuell källkod, så hantera att de saknas. `productFallback` och `providerError` är valfria; hitta inte på ett generellt fallback-statusfält. Hantera både ChattyboxError och oinpackade nätverksfel; code är valfri.
6. Avvisa tomma eller efter trimning längre än 2 000 tecken, förhindra dubbla inskickningar och se till att tangentbord och skärmläsare fungerar. Headless `sendMessage()` försöker inte automatiskt igen: använd en unik `idempotencyKey` per logiskt meddelande och återanvänd exakt samma indata vid försök igen; gör inte blinda retries på varje HTTP 409. SDK `0.1.4` gör separat ett enda nytt försök med `getWidgetConfig()` efter HTTP 400; den hostade widgetens startup-GET-försök är en annan mekanism.
7. Montera gränssnittet endast på de rutter eller i den layout jag anger.
8. Följ befintliga komponenter och stilar i stället för att lägga till ett nytt designsystem.
9. Ladda inte widget.js och anropa inte mountWidget().
10. Kör build, lint, typkontroll och relevanta tester och rapportera sedan ändrade filer samt en verifieringsplan.

Ramverksanteckningar​

Ge assistenten ytterligare en mening vid behov:

  • Next.js App Router: ”Använd en liten Client Component i en beständig layout och anropa mountWidget() i en effekt som endast körs i webbläsaren, inte under rendering.”
  • React SPA: ”Montera från det beständiga applikationsskalet. Om komponenten äger SDK-handtag, returnera remove() som cleanup för varje handle vid avsiktlig teardown; annars behåll den delade loadern under tillåtna ruttbyten.”
  • Docusaurus: ”Initiera från src/theme/Root i webbläsarkod och behåll loadern under tillåten dokumentationsnavigering. Kontrollera den distribuerade loader-versionen och locale-beteendet innan du förlitar dig på språkbyten på klientsidan; dashboardkonfigurationsändringar kräver fortfarande ominitiering.”
  • Vue, Nuxt, Svelte eller annat ramverk: ”Använd den klientbaserade monteringslivscykeln i en beständig layout; välj ett headless-gränssnitt om motsvarande teardown krävs.”

Granska en befintlig SDK-integration​

Instruktion
Granska min ChattyBox SDK-integration

Granska denna ChattyBox-integration utan att distribuera eller ändra orelaterad kod.

Kontrollera att:
1. @openstaticfish/chattybox är installerat och importerat i stället för att dess funktionalitet dupliceras.
2. En Chattybox-klient får den avsedda offentliga API-nyckeln och API-URL:en.
3. Webbläsarens miljövariabler följer ramverkets namnregler för offentliga variabler utan att privata autentiseringsuppgifter exponeras.
4. Den hostade widgeten använder ett beständigt skal och aktiv teardown med `remove()`/`window.ChattyBox.destroy()` vid ruttundantag efter SPA-navigering eller återkallat samtycke; den laddas inte på känsliga/privata rutter eller före nödvändigt samtycke. Att dölja UI:t eller bara ta bort skripttaggen räcker inte, och en redan serverbehandlad begäran kan inte ångras. Ett anpassat gränssnitt har riktig komponentstädning.
5. Klientsidig navigering och omladdningar under utveckling inte skapar dubbla instanser.
6. Befintliga renderingsgränser, lokalisering, analys, samtycke, tillgänglighet och layout förblir intakta. De aktuella dashboardvägarna är **Installera → Nycklar & domäner** och **Installera → Installation på webbplatsen**. Originbegränsningar är ett valfritt extra skydd och autentiserar inte besökare; en nyckel som förberetts för en webbplats kan redan vara begränsad. Begränsade nycklar kräver ett tillåtet ursprung för begäran, och Node fetch skickar inte automatiskt webbläsarens Origin-/Referer-headers. Exponera aldrig administrativa hemligheter eller konfigurationsdistributions-token.
7. Implementeringen har lämpliga tester och ingen orelaterad refaktorering.

Returnera resultat efter allvarlighetsgrad med filsökvägar och radreferenser. Föreslå endast de minsta säkra korrigeringarna och ge exakta verifieringskommandon.

Inget npm eller byggsteg?​

Använd installationsguiden för widget.js endast när webbplatsen inte kan använda npm-paketet — till exempel vanlig HTML, ett fält för anpassad CMS-kod eller Google Tag Manager.

Instruktion
Installera reservskriptet för widgeten

Installera den hostade ChattyBox-widgeten på den här webbplatsen med det exakta skript som genererats i **Installera → Installation på webbplatsen** i ChattyBox. Kontrollera den offentliga webbläsarnyckeln och dess origininställningar under **Installera → Nycklar & domäner**. Originbegränsningar är ett valfritt extra skydd och autentiserar inte besökare; en nyckel som förberetts för en webbplats kan redan vara begränsad. Ta aldrig med konfigurationsdistributions-token, administratörsuppgifter eller en privat miljöfil:

[PASTE COMPLETE WIDGET SCRIPT]

Inspektera webbplatsen först och identifiera den säkraste infogningsplatsen för offentliga sidor. Ladda det oförändrade skriptet exakt en gång och endast när nödvändigt samtycke finns; uteslut privata/admin-/kassasidor. Vid SPA-ruttbyte eller återkallat samtycke ska en initierad widget aktivt tas bort innan den går in i ett uteslutet läge och bara initieras igen när det är tillåtet. Kontrollera att den distribuerade loader-versionen stöder teardown; att dölja UI:t eller bara ta bort skripttaggen räcker inte, och teardown kan inte ångra redan behandlade begäranden. Bevara CSP-beteende, exponera inte privata autentiseringsuppgifter, administratörshemligheter eller konfigurationsdistributions-token, distribuera inte ändringen och rapportera den ändrade platsen samt en webbläsarbaserad testplan.

Testa resultatet​

  1. Granska diffen och bekräfta att inga riktiga autentiseringsuppgifter har committats.
  2. Kör projektets vanliga build, lint, typkontroll och tester.
  3. Distribuera genom den normala granskningsprocessen.
  4. Verifiera avsedda rutter i ett privat webbläsarfönster, inklusive klientsidig navigering.
  5. Ställ en fråga som stöds, följ en källhänvisning och testa reservbeteendet.
  6. Kontrollera mobil layout, tangentbordsanvändning och webbläsarkonsolen.

Fortsätt med SDK-referensen och lanseringschecklistan.