C3 AI Documentation Home

Debug and Profile

This section covers debugging and profiling your user interface.

Prerequisites:

  • A user interface that you've created with C3 AI UI Stack.

Use these debugging tools and extensions

Chrome DevTools and the React and Redux extensions are the tools used to debug the C3 AI UI Stack. These debugging tools and extensions provide helpful debugging information. Familiarize yourself with the following tools and install the extensions to follow along with the next sections.

Chrome DevTools:

React and Redux extensions:

Inspect the component instance source code

The component instance's source code is the first place to inspect to see if issues are related to incorrect component configuration or code generation.

In your package, under the ui/c3/meta folder, the component instances configured through the JSON files translate into TypeScript React code, the "source code".

To inspect the source code:

  1. Navigate to the Sources panel in Chrome DevTools.
  2. Enter the JSON file name (without the extension) for the component that you want to troubleshoot.
  3. Select the corresponding TSX file. select tsx file in sources panel
  4. Set breakpoints. The best place to set a breakpoint is the first line of the component function. This allows you to see the result of every property that is passed in.
  5. Inspect the variables, key/values pairs, and source code. debug txs in sources panel

Cannot find the TSX file

The previous example image shows the Sources panel in the Chrome DevTools when you enter the JSON file name SDLDemo.TableTypesBasic and select the TSX file. If there is no corresponding TSX file, these can be the following reasons:

  • If you do not see any file(s) with the same JSON filename, you might be debugging a production build that is not supported.
  • If you see a list of similar files, you might have multiple source maps that provide source code with changed names. JSX files appear this way. In this situation, choose the file containing the additional fingerprint after the ?.

An example image of the multiple files for a jsx file:

select jsx in sources panel

Choose the file containing the fingerprint after the ?, SDLTable.jsx?077e to see the source code.

debug the jsx file in sources panel

Find the rendered component ID

The component ID consists of the component instance JSON filename. When debugging the UI, there might be times you do not know the component ID. To find the component ID, install:

To find the component ID:

  1. Open the Components tab in the React Devtools.
  2. Select the inspection tool. To find hovered component filenanme
  3. Hover over the component to find the component ID. You can also hover over the component ID in the Components tab to highlight the component instead.
  4. See the highlighted component ID with the following syntax: ModuleName.ComponentName.

View triggered actions, payloads, and changes in the state of a component

Note: Install Redux DevTool to see triggered actions, payloads, and the changes in the state of a component.

Components interact with each other by triggering actions. The trigger field in the component's JSON configuration declares the action. To debug an action, open Redux DevTools.

To following example code block shows the JSON configuration of a component with a trigger.

JSON
[{
  "trigger": "SDLDemo.TableActionsHoverActions.ROW_ACTION_CLICK_DELETE_WITH_CONFIRMATION",
  "effectType": "UiSdlEpicShowUiSdlModal,"
  "payload": {
    "modal": "SDLDemo.RowDeletionConfirmationModal"
  }
}];

Following the previous codeblock, the ROW_ACTION_CLICK_DELETE_WITH_CONFIRMATION triggers when clicking on the delete the icon on the row. Then, the ROW_ACTION_CLICK_DELETE_WITH_CONFIRMATION successfully starts the MODAL_OPEN action.

To view triggered actions:

  1. Open the Chrome DevTools.
  2. Select the Redux Tab.
    • If you do not see the Redux tab, select the arrow and then the Redux option in the dropdown menu.
    • If it is still not shown, verify that you installed the correct Redux extension.
  3. Select the red circle button. This action will clear the previous action logs.
  4. Trigger an action by selecting the delete icon on a table row.
  5. Select the desired action to view the passed data.

Expected actions are not triggered

If the expected actions are not triggered, it might be due to a typo in the action names. Check for typos in the effectTrigger field component JSON configuration.

This debugging method applies to any type or subtype interacting with actions like UiSdlEpic, UiSdlTransform, or UiSdlApplicationState. To further debug, enter the effectType value. In the previous code block, the value of the effectType is UiSdlEpicShowUiSdlModal.

UiSdlEpicShowUiSdlModal source code

Note: To learn more about how data is passed between components, see communication between components.

View change in the component's state

One of the best ways to see what changed in the state of your component is to view the Diff tab, where only the values that changed are shown and highlighted:

view diff tab in react extensions

Send a modified action

To debug or send potential fixes, you can also send modified actions. To do so, follow these steps:

  1. Open the Redux DevTools.
  2. Select the icon at the bottom of the panel to open the dispatcher. open dispatcher
  3. Enter the modified action and select the Dispatch button. dispatch modified action
  4. If you have UiSdlEpic related to the action, view and analyze the source code of the epics by placing breakpoints or by viewing the Inspector panel.

View requests sent by the browser

Read inspect network activity before continuing.

It is vital to ensure your Protocol is at least h2 and that the reported time per request is lower than 100ms. Higher times indicate network latency or server slowness. Address those issues to ensure proper performance. The Network tab of Chrome DevTools gives you a detailed list of sent requests made from the browser.

network performance

The network tab lets you accomplish the following:

  • Filter the request by type or name:

    1. Use the built-in filters, the Fetch/XHR option.
    2. Enter the type or name of the request.

  • Analyze the time the request spent on the server side:

    1. Select the desired request to view specific details.
    2. Select Header tab and view the x-timing-info under Response Headers.

    view x-timing-info

  • View response data when trialing issues that are related to data:

    1. Select Preview tab. This provides an interactive view of the JSON data that was retrieved from the server. Each level is collapsible and expandable.

    view response data 2. Select the Response tab which provides the raw JSON data.

Profiling and performance

Before implementing optimized solutions or reporting performance issues, it is best practice to optimize the quality assurance (QA) and production environments. Optimizing the QA environment helps catch errors early.

Requirements for production and quality assurance environments

Note: Although you can follow these instructions in both development and production mode, you must switch to development mode to identify the code you are debugging by filename.

  • Determine which mode is currently running:

    JavaScript
    UiSdlConfig.inst().infrastructure.webpackMode;

    If this returns development or production, that is the mode that UI bundles will be served as. Otherwise if this returns undefined, then the mode is determined by the AppMode that can be found via

    JavaScript
    App.inst().mode;

    See the below table for a full explanation for which combinations of UiSdlConfig.inst().infrastructure.webpackMode and App.inst().mode serve which bundle mode.

    UiSdlConfig.inst().infrastructure.webpackModeApp.inst().modebundles served as
    development[any]development
    production[any]production
    undefineddev or testdevelopment
    undefinedprod or trialproduction

  • Enable development mode:

    Although development mode will be the default if App.inst().mode is 'dev' or 'test', it can also be set for other App modes with:

    JavaScript
    UiSdlConfig.inst().setConfigValue('infrastructure.webpackMode', 'development');

  • Enable HTTP/2.

    • Depending on your cloud provider, this might be enabled. For environments hosted by C3 AI, it is already enabled. Please reach out to your IT organization to see if your provider can enable HTTP/2.

The following sections discuss ways to find and isolate the root causes of poor code performance.

Diagnose poor performing code

Poor code performance can occur if a component is rendered too many times. This section discusses ways to profile your component code.

If your UI is running slowly, use the following steps to record a profiling session on your component code:

  1. Record a Profiling session when running the slow-running UI.

    • If you find that a specific interaction triggers page slowness, start recording before that interaction is triggered.
    • If the trigger of the page slowness is unknown, start the recording as soon as the page begins loading.

    record a profiling session

  2. Start recording. Once you start recording, you'll see a modal appear.

  3. Perform the desired user interactions to record.

  4. Stop recording by selecting the Stop button in the modal.

    recording a session

An example image of an analysis you receives after you stop recording a session:

recorded session chart

Note: The "flame chart" identifies the called functions and the time spent completing each function. The flame chart shows the function names if your application is in development mode.

View the Summary tab to see:

  • Total Time: The time it took for the function to complete running (for the onSearchQueryChange it took 190.87ms).
  • Self Time: All the time spent in functions called by it (for the onSearchQueryChange the amount of time functions spent calling on it was 0).
  • Function: Showcases the filename for the function. Select the SDLSearch.jsx to be redirected to the file and set breakpoints or analyze the source code.

Analyze whether the component is re-rendering too many times

The flame chart indicates when a component is executing multiple times in rapid succession unnecessarily.

These charts cannot show the cause because the function calls are too small to find the root issues.

Example of a session recording of an input field behaving unexpectedly and causing a slowdown when the user interacts with it:

record of a bad session

To find the root cause:

  1. View other network requests or application logic contributing to the slowness.

  2. Explore the issue further by using the Profiler in React Dev Tool.

    • Enable Record why each component rendered feature to capture how and which components are re-rendered.

    enable recording feature of components

    • Start, stop, and capture the bad behavior in the recording.
    • Analyze the flamegraphs.
      • The example image shows the SDLDemo.SimpleForm re-rendering 12 times and around 90ms per render. view response flamegraph
    • Compare each of the renders.
      • It might be that a part of a component is re-rendered again and again. In severe cases, the component might unmount and remount again.

In our example, two React hooks change each time the component renders. If this is a component you authored, find which hooks were changed by searching for the component in the Components React DevTool tab and locate the hooks by number.

Was this page helpful?