Archive: Flex Webchat release notes for past versions

Use this page to find historical information about older Flex Webchat releases. For up-to-date information on the latest Webchat version, see Flex Webchat UI release notes.

@twilio/flex-webchat-ui@1.2.0

release date JAN 11, 2019

• Values for multiple fields in the pre-engagement form cannot be set
• Name of the agent was not shown as message sender after the chat was completed
• TypeScript definitions for TS based projects are broken
• WebChat fails to load if the chat channel has been deleted

• You can now use a custom redux store with WebChat

1
const reducers = combineReducers({
2
    flex: WebchatReducer,
3
    app: appReducer
4
});
5

6
const store = createStore(
7
    reducers,
8
    compose(
9
        applyWebchatMiddleware()
10
    )
11
);
12

13
FlexWebChat.Manager.create(config, store)
14
    .then(manager => {
15
        ReactDOM.render(
16
            <Provider store={store}>
17
                <FlexWebChat.ContextProvider manager={manager}>
18
                    <FlexWebChat.RootContainer />
19
                </FlexWebChat.ContextProvider>
20
            </Provider>,
21
            document.getElementById("container")
22
        );
23
    });

@twilio/flex-webchat-ui@1.1.0

release date DEC 19, 2018

• Fixed selectItem type in pre-engagement form by passing the missing value prop to Select and fixed the styles for the same.
• Fixed the container width of DynamicFrom for webchat forms.

• The startEngagementOnInit option now disables pre-engagement form

• User's friendly name default to Anonymous and can be defined through context argument as friendlyName field

• New configuration options required in the application configuration:

  • accountSid - Account SID where Flex is running
  • flexFlowSid - Flex Flow SID created at onboarding for chat

• Configuration options startEngagementUrl and serviceBaseUrl

• Individual module files in the NPM module removed. All sources bundled into a single module bundle file referenced by the main field in package.json.

• Theming was reworked and config parameters changed. User now has 4 distinct levels available to theme their application.

  • Not specifying a predefined theme, in that case BlueMediumTheme is chosen automatically.

  • Specifying predefined theme - either colorTheme:"DarkTheme" or colorTheme: {name: "DarkTheme"}. Available themes are MediumTheme, DarkTheme, BlueMediumTheme and BlueDarkTheme. A predefined theme specifies base colors used and also whether the theme is considered light or dark, which influences text and hover colors unless they are specifically changed.

  • Overriding all or a selection of colors and/or the lightness of the theme that was set by the predefined theme (note, specifying predefined theme was not compulsory, but in BllueMediumTheme was then used as default).

    • colors - variables base1..base11 are colors provided by the predefined theme that set the tone of the theme. User can override all (preferred) or some of those colors. User can also override any of the theme independent hardcoded colors like for example the red color of hangup button.

      • Available colors to override are:

        Copy code block

        base1, base2, base3, base4, base5, base6, base7, base8, base9, base10, base11, defaultButtonColor, lightTextColor, darkTextColor, buttonHoverColor, tabSelectedColor, connectingColor, disconnectedColor, notificationBackgroundColorInformation, notificationBackgroundColorSuccess, notificationBackgroundColorError, notificationBackgroundColorWarning, notificationIconColorError, notificationIconColorWarning, userAvailableColor, userUnavailableColor, errorColor,

    • light - Default text color, hover colors and rule of which base color is chosen for SideNav and MainHeader depend on this Boolean.

  • The above mentioned parameters together with the built in color -> component css props mapping result in final theme where each component has a set of color specific css props. Should this not suffice there is a final step of providing overrides property that allows for overriding any parts of this result. Documenting that object is beyond the scope of this changelog, it is easiest to just monitor that object in debugger and decide on what parameters to change.

  Examples:

1
// Picks the default blue dark theme
2
config.colorTheme = "BlueDarkTheme";
3
// Picks dark theme, changes all of its base colors to new ones and tells the system that we still expect it to take the theme as dark (light parameter)
4
config.colorTheme = {
5
     name: "DarkTheme",
6
     colors: {
7
         base1: "blue",
8
         base2: "orange",
9
         base3: "yellow",
10
         base4: "black",
11
         base5: "white",
12
         base6: "pink",
13
         base7: "red",
14
         base8: "blue",
15
         base9: "brown",
16
         base10: "black",
17
         base11: "white"
18
     },
19
     light: false;
20
}