CustomizationProvider and available baseTheme properties

[LiYChristopher]

Hi team,

I was recently looking into using CustomizationProvider for an internal application we're working on, in order to modify some of the styles of Paste elements that do not expose style props.

Things worked as expected except that I found we can't use the twilio theme with CustomizationProvider - which specifically alters the appearance of the UserIcon we're using in our chat application.

I found this discussion that goes in-depth into why this theme is not select-able. I recognize that this provider isn't meant for internal use-cases:

The Customization Provider is only designed to be used in programmable, configurable apps that customers can customize. It's not for internal use. As such, we're only going to support default and dark on the customization provider.

Nonetheless I have two questions:

1. I see in the summary table in the linked discussion, that default will eventually be the same as the Twilio theme. What's the current status on this?
2. If CustomizationProvider isn't what we should be using to customize styles for specific elements e.g. CHAT_BUBBLE, what should we be using?

[TwilioPasteBot]

Disclaimer: This is a very experimental bot using OpenAI's GPT-4. The answers may not be correct, a human will review the answer and update it if necessary.

---

Hello,

1. The documentation does not provide a current status on whether the default theme will eventually be the same as the Twilio theme. I'm sorry, but I can't provide an update on this.

2. The CustomizationProvider is indeed the recommended way to customize styles for specific elements in your application. You can use it to customize individual components or create entirely new ones based on existing components. It integrates seamlessly with the current theme and allows you to choose either the default or dark themes as a base.

Here's an example of how you can use the CustomizationProvider to customize the CHAT_BUBBLE:

import {CustomizationProvider} from '@twilio-paste/core/customization';

const MyApp = () => (
  <CustomizationProvider
    baseTheme="default"
    elements={{
      CHAT_BUBBLE: {
        backgroundColor: 'colorBackground',
        borderRadius: 'borderRadius20',
        // other styles...
      },
    }}
  >
    rest of app
  </CustomizationProvider>
);

In this example, the CHAT_BUBBLE is customized with a background color and border radius. You can add other styles as needed.

I hope this helps! Let me know if you have any other questions.

I also did a search, and I managed to find these other Discussions that might be similar or related to your question. Give them a read to see if they answer your question. If they do, head back here and update this discussion and mark it as answered, pointing others to the related discussion:

• Preferred approach for styling in Flex 2.0 - Answer (updated: 06/28/2022, similarity score: 88%)
• CodeBlock Light Theme - Answer (updated: 01/30/2023, similarity score: 88%)
• How to pass a custom theme to CustomizationProvider within Flex.setProviders - Answer (updated: 10/25/2022, similarity score: 88%)

[SiTaggart]

Hi @LiYChristopher

For the first question, the timeline is undefined right now. It is largely tied to the Flex roadmap as it's mainly for Flex customers. When a new major release of Flex comes up, we'll sync updating the base theme in customization provider to that release to match the design language update. I don't think there are any timelines on that right now.

For the second question; "If CustomizationProvider isn't what we should be using to customize styles for specific elements e.g. CHAT_BUBBLE, what should we be using?": You should not be using anything to override the styles of Pate components for Twilio applications. We cover the reasons in more depth in this discussion

We generally want all User Interfaces, including conversational UIs, at Twilio to look and feel the same, regardless of application or team. So individual teams modifying the styles of design system components actively hinders that goal. As outlined in the discussion I link to above, it also makes it much harder to roll out updates to our applications, as you now need to triage Paste updates to make sure it doesn't have an adverse affect on what you changed, potentially slowing down adoption and updates.

We do want to know about new use cases, though, so your design partner should be encouraged to come to Design System Office Hours to discuss their needs. It might already be planned for and in the roadmap, or it might be something that everyone at Twilio who is building conversational UI might benefit from.