Azure Bot Service Web Chat控件使用及密钥选择技术咨询

Hey Sam, let's break down your questions one by one based on my hands-on experience with Azure Bot Service and Web Chat:

Is your current UI implementation reasonable? #

Absolutely—your current approach (using the pre-built botchat.js with custom CSS) is totally valid for initial development and scenarios where you need quick setup with basic customization. It lets you get a functional chat UI up and running fast, and tweaking styles is a straightforward way to match your site's branding.

That said, your plan to move to custom builds from the Web Chat source code is a smart long-term move. The pre-built botchat.js includes all features (even ones you might not use), so building from source lets you tree-shake unused modules to drastically reduce bundle size. It also unlocks deep customization options—like adding custom message renderers or modifying core chat behavior—that aren't possible with just CSS tweaks.

Best Practices & Lessons Learned #

Here are some key tips to make your implementation more robust and maintainable:

• Don't edit botchat.css directly: Instead, create a separate custom CSS file that overrides default classes or uses Web Chat's built-in CSS variables (e.g., --webchat-background-color, --webchat-bubble-user-background). This way, you can upgrade Web Chat to newer versions without overwriting your custom styles.
• Secure your credentials at all costs: Hardcoding any channel key in client-side HTML/JS is a huge security risk—anyone can inspect your page and steal the key to abuse your bot. Instead, set up a backend endpoint that uses your Direct Line key to generate a short-lived token via the Direct Line API's /tokens/generate endpoint. Pass this token to your frontend Web Chat control instead of the raw key.
• Optimize custom builds: When working with the Web Chat source, use the official build tools to import only the modules you need. For example, if you don't use adaptive cards or speech features, exclude them from your bundle to cut down on load time.
• Test responsiveness: Web Chat is designed to be responsive, but custom styles can break this. Always test your chat UI on mobile, tablet, and desktop to ensure a consistent experience.

Alternative UI Implementation Options #

If you're open to alternatives beyond the vanilla botchat.js, here are a few options that support rich response types (text, video, hero cards, etc.):

• React-based Web Chat: The official Web Chat offers a React component that's far more flexible than the vanilla JS version. If your site uses React, this integrates seamlessly with your existing component tree. You can easily extend it with custom hooks, override default renderers for specific message types, or add custom UI elements.
• Build a fully custom UI: Use the Direct Line API directly to handle message sending/receiving, then build your own UI components to render different response types. This gives you complete control over every aspect of the chat experience, but it requires more development work—you'll need to handle message parsing, state management, and rendering for all card types.
• Third-party chat UI libraries: There are open-source chat UI kits that you can pair with the Direct Line API. You'll need to write adapters to map Bot Framework's response types to the library's component structure, but this can be a good middle ground if you want pre-built UI components without being tied to Web Chat.

Which Key Should You Use? #

Short and clear: Use the Direct Line Channel key.

The Web Chat Channel is essentially a pre-configured wrapper around Direct Line—when you use the Web Chat control directly, it communicates with your bot via the Direct Line API. The Web Chat Channel's main purpose is to generate quick embed code for your bot, but for custom integrations like yours, the Direct Line key is the right choice.

Again, remember: never expose this key in client-side code. Always generate a temporary token via your backend and use that token in your Web Chat control.

内容的提问来源于stack exchange，提问作者Sam