BotFramework-WebChat | customizable web-based client | Bot library

You can accomplish this by filtering the activities that pass thru Web Chat's store. As you can see below, I first query for the attachment button's elements - there are two, a hidden input field and the button.

Next, I check if the activity has an attachment and if that attachment's contentType matches "application/vnd.microsoft.card.adaptive". If it does, then the attachment input & button is enabled. Otherwise, the attachment input & button is disabled for all other activities.

The whole if statement is wrapped in a time out. This is necessary because the check on the contentType of the attachment will complete before the store has finished rendering the activity resulting in a persistently disabled button. Setting a time out of ~300 ms allows the store to complete its rendering action. You can adjust the time out, but less than ~50 ms and the above will start occurring. Longer than ~500 ms and it will start to be noticeable to users.

Please note, isolating the input & button elements relies on attributes and classes defined by Web Chat. While it is unlikely to be an issue, it's possible those definitions could change in future releases resulting in breaking changes and requiring updates to your code.

Instead of initializing and using the useSendMessage hook, replace it with useSendPostBack. Using useSendPostBack will generate a postBack message activity which simply sends a value back to the bot without displaying it to the user. The value sent to the bot should be located in the value property of the associated activity.

I was able to get it to work using the below code:

I've been aware of you have followed up the suggested link https://www.gatsbyjs.com/docs/debugging-html-builds/#fixing-third-party-modules to fix window issue.

BUT it this way is likely to prevent webpack compile the commonjs web chat packages properly which ended up with the issue.

I was also aware of the configuration the stage of build-html isn't called during dev that's why you wouldn't see the error as you yarn start // gatsby develop.

However, the document also suggests another way to fix is to use code splitting technique by using loadable-component. Personally, I think this way is best for you project since the chat is supposed to be rendered at the client side only.

Here's a few thing you would change:

• Remove your configuration in gatsby-node:

The issue with your particular implementation is, while you have set up an API for generating and serving a token back to Web Chat, you are failing to actually call that endpoint. Instead of

const res = await fetch('https://directline.botframework.com/v3/directline/tokens/generate', { method: 'POST' });

you should have

const res = await fetch('http://localhost:3978/directline/token', { method: 'POST' });

It is this that will make the call to exchange the Direct Line secret for a token and, in turn, will return the token back to your Web Chat instance.

I think your best bet going forward is to use the samples provided by the webchat team. The minimizable webchat sample is a good example.

Because Web Chat converts all cards to Adaptive Cards, you will need to solve this issue using Adaptive Cards. You can see here that the Adaptive Cards SDK that Web Chat is using converts all anchors to "_blank" after Markdown is applied.

If the ib and ob values displayed by the *.bot endpoint are false this means the bot and the Direct Line app service extension are unable to connect to each other.

Make sure you verify below things:

1. Double check the code for using named pipes has been added to the bot.
2. Confirm the bot is able to start up and run at all. Useful tools are Test in WebChat, connecting an additional channel, remote debugging, or logging.
3. Restart the entire Azure App Service the bot is hosted within, to ensure a clean start up of all processes.

Please check troubleshooting guide, it seems updated today. (still old date reflected some how, not sure why)

It isn't documented anywhere, but best practice is what is demonstrated via the samples, by use of the Web Chat redux store and its list of available actions.

Essentially, Web Chat v4 is built on top of BotFramework-DirectlineJS which does use observables. Web Chat then translates the Direct Line observables into its own methods for consumption internally and by the user.

As you noted, it is possible to use the Direct Line observables in Web Chat but it is neither the best method nor the best practice to do so. Primarily, because Web Chat wasn't specifically designed around their use, except internally. It can work, but it opens you up to potentially curious behavior.