microsoft
An headless approach to this Library
Feature Request
Will it be more effective if this WebChat SDK just export Hooks or Redux Dispatches to the logic and all UI Components be created and customized by the developer? Is really a pain to make this WebChat looks good, using CSS is weird because overwrites leads to break in new releases as discussed the classes and html markup changes a lot and the code and stylesheet looks so dirty, the JSS approach leads to limited styling.
I know how important accessibility is and all the efforts from the core members of this project is doing but I think an headless approach will be better, providing logic via hooks and the style leaves to the developer using this lib to build, even handling accessibility.
I love how powerfull is the use of custom components, but I think the standard chat isnt customizible enough, even the sendinputBox is really dificult and weird to style and to add custom features to it.
Keep the great work on this SDK, this is just an idea that I think will make this lib even more powerful.
Thanks for your appreciations.
We refactored headless business logics into the botframework-webchat-api package (which our web UI is based on). It should be good for React Native but we haven't tested it yet.
You will need to bring-your-own UI. Top of my head, there are a few complex logics that are not included in the api package:
- Speech recognition and synthesis
- Activity grouping
- Grouping messages based on who send it, and when they send it
- (We should put it in
api, need to refactor out from our monster<BasicTranscript>)
- Some UI related logics
- E.g. no "send button click" hook, because "send button" is UI, not headless
You are right. Accessibility is very difficult to get it right. We keep learning and rewriting our DOM tree to make accessibility experience better, but IMO, we are not there yet. Lucky we have good set of E2E visual regression tests, so we are quite confident about our quality when rewriting DOM tree.
CSS is a difficult topic. There are few things in my head that need more thinking/experiments:
- Publish an official list of CSS class names that are good for extensibility (namely, "CSS insertion points")
- While adding features or making accessibility experience great, inevitably, we need to modify the DOM tree
- How can we look into the future and say... this CSS class name should be good for next 2 years even we added lot of features around it?
- Instead of style options, use CSS vars (need to figure out a story for IE11 or browser which doesn't support it yet)
- Goal: make CSS the first-class citizen for branding
- Some style options are not used for visualization (i.e. not really CSS), e.g. send timeout
Few more things in my head that need more thinking/experiments too:
- Ability to customize send box
- We have an input modality work item, which devs can set to use only speech or text. And while we work on that, we will make it customizable... 1P = 3P
- Move away or hide our Redux store... it should be internal
- A lot of devs want to receive trigger when an activity arrives, doing it with Redux is easy, doing it with hooks are not
- Move away from Observable (which
DirectLineJSuse). Instead, you can provide an activity array and let Web Chat render it out. Will be easier for you to use Web Chat on other chat platforms or rendering static transcript- 1 goal: support Azure Communication Services
- 1 hidden goal: support Azure Web PubSub
- Refactor out the middleware architecture into a separate package, and do some clean ups
- The middleware architecture is great, so we want to refactor it out to make it even cleaner
- Some middleware has poor API signature, cleaning them up is not trivial as a lot of devs relies on them
- More samples or put them on CodePen/CodeSandBox
- Reasons we didn't go CodePen/CodeSandBox: we can't integrate them with our CI/CD to programmatically publish samples there
- Or build a Jupyter notebook like playground, so you can test your code side-by-side with UI
