Expose `useErrorMessageId` hook necessary for importing the BasicSendbox component for customization

Is your feature request related to a problem?

Regarding IcM #414844341.

The customer is attempting to make some Web Chat customizations that pertain to integrating a validation box/toast notification into the BasicSendBox component. However, they are unable to move forward as the hook, useErrorMessageId, is inaccessible.

From the customer in an email thread:

We are looking into creating some minor customizations in-house in the interim. However, there appears to be one small issue standing in our way. Would you consider proceeding with a smaller fix in order to enable us to do some customizations on our own?

There is one hook that is not exposed in this sendbox, related to accessibility error messages: useErrorMessageId. Every other hook in the library is exposed, but this one is not exposed in the same path. It seems to be the last hurdle in allowing us to import the BasicSendbox component for customization, and we are hopeful it could be a quick fix from Microsoft’s end...

Describe the suggestion or request in detail

Expose the useErrorMessageId hook so it is accessible when imporing the BasicSendBox component.

From the customer:

Could you help us understand if the useErrorMessageId hook could be exposed allowing the customers to make the customizations for validation box? They are looking into creating some minor customizations in-house, however there is an issue there since useErrorMessageId hook is not exposed. Every other hook in the library is exposed, but this one is not exposed in the same path. It seems to be the last hurdle in allowing them to import the BasicSendbox component for customization.

Describe alternatives you have considered

The customer is unsure as to what other options, if any, are available to try. However, they are "open to other ideas or suggestions about a better approach."

Additional context

Customer's full email response regarding the inability to customize built-in Web Chat components:

I definitely understand your perspective in terms of not offering infinite customization, but from my perspective what is currently offered is really a “half-customizable” user interface. The webchat ui can be thought of in terms of input & output: output from the bot to the user, and input from the user to the bot. Since the “SendBox” component comprises the entire input section of the application, only half of the webchat application is actually customizable.

For example, the SendBox really includes: quick responses, text input area, send button, file upload button, microphone button, and dictation interims components. However, we are currently unable to modify, remove, or add to these inner components because the SendBox is not customizable. The naming of SendBox would lead you to believe this is a small area of the ui, but it’s not.

I have to say we have been impressed with the output half of the application, as it has a great deal of customizability included, and we have taken advantage of that attention to detail in several important cases. But it seems that the input half has been rather neglected.

While we still desire the ability of full customization of the input section, we are looking into creating some minor customizations in-house in the interim. However, there appears to be one small issue standing in our way. Would you consider proceeding with a smaller fix in order to enable us to do some customizations on our own?

There is one hook that is not exposed in this sendbox, related to accessibility error messages: useErrorMessageId. Every other hook in the library is exposed, but this one is not exposed in the same path. It seems to be the last hurdle in allowing us to import the BasicSendbox component for customization, and we are hopeful it could be a quick fix from Microsoft’s end, that would enable us to proceed in-house. We will present the path forward at today’s meeting.