From Zero to ComposeSDK: Building a Sisense React Application with an AI Coding Assistant

A computer with no development related setup, no code editor application, no programming languages or runtimes such as Node installed, no development tooling of any kind, can create a running ComposeSDK React application in a single development session, connected to a live Sisense instance and ready for continued iteration. The computer can be a laptop, desktop, or server, and the finished app can be served from localhost, a local IP address, or a domain. Almost none of this development and setup has to be done by hand. An AI coding assistant installs the tooling, runs the commands, and writes the code, while the developer describes what should happen and confirms the results along the way. This style of development is sometimes called vibe coding, which refers to working conversationally and letting the AI handle the mechanics.

Any modern LLM based coding assistant can drive this workflow. It needs two capabilities, editing code files in the project folder and running terminal commands. This article uses Claude Code in VS Code as the concrete example, but the same steps work in other editors with agentic assistants, in a standalone CLI tool like Claude CLI, or in a desktop app with terminal access like Claude Desktop. The prompts translate directly and are not specific to Claude.

Only two steps require manual installation. The first is installing the text editor with its AI assistant, and the second is generating an API token inside the Sisense web interface. Everything else happens through conversation, from installing Node.js to creating the project, configuring credentials, generating the .ts representation of a Sisense data model, and building the widgets, dashboards, and other visualizations themselves.

The starting point on the Sisense side is a modern Linux instance with at least one data model, either an ElastiCube or a live model, and permission to generate an API bearer token on it.

Prerequisites

A modern Linux Sisense instance with at least one data model
Permission to generate an API bearer token on that instance
A computer with the ability to install programs and CLI access
Access to an LLM like Claude, or similar

Getting Started

An editor and an AI assistant have to be installed before anything can be done conversationally, so the first two steps are done manually.

Download and install Visual Studio Code.
Open the Extensions view in VS Code, search for the assistant of choice, install it, and sign in. For Claude Code, see the Claude Code documentation. Other agentic assistants with file editing and terminal access work the same way.

One behavior is worth knowing about before the first prompt. Agentic assistants ask for approval before running each terminal command, so expect to click Yes regularly during setup, and read each command before approving it. The approval step exists so the developer always knows what is about to run on the machine, and it only provides that protection if the commands are actually read. Most assistants also offer an option to allow certain commands without asking again, which becomes convenient once a pattern has been reviewed a few times. Editing files inside the project folder is a sensible thing to approve universally. Commands that reach outside the project folder, or that install programs system wide, should be reviewed every time and not auto approved.

How Granular to Be

The sections below proceed step by step, with each prompt doing one focused thing. That structure is deliberate. It makes each step verifiable before the next is added, and it gives the reader a chance to learn what is happening at every stage. It is not a limitation of the LLM.

In practice, an agentic assistant handles much larger requests comfortably. Given an empty folder and little else, a single prompt can carry the project most of the way.

Set up a new ComposeSDK React application in this folder. Install Node if it is missing, create a React TypeScript Vite project, add the Sisense ComposeSDK packages, and start the dev server. My Sisense instance is at https://example.sisense.com and I will provide an API token in the file where it is needed, tell me where it is.

The assistant works through the chain on its own, installing what is missing, flagging where the token goes, and reporting back when the dev server is running. Granular prompts tend to be the better choice while learning. Broad prompts work better once the process is familiar. Most real sessions mix both freely.

If any errors are visible, pasting the error message into the LLM chat will often allow the LLM to resolve the issue. Checking the browser developer tools console for error messages to copy can also be helpful.

Handing the Environment to the Assistant

From this point forward, work happens in the assistant's chat panel. The first task is the development environment itself.

To open the Claude VS Code UI, click the orange flower icon in the top right corner when a text file is open in VS Code.

Open VS Code in a new empty folder that will hold the project (File, Open Folder, then create or select a directory. Name the folder appropriately, to match the name of the ComposeSDK (CSDK) application). Create an empty text file if the Claude VS Code icon (or the equivalent for the LLM in use) is hidden. Then open the LLM chat panel and ask the assistant to set up the toolchain.

Install the latest LTS version of Node on this machine, make sure it is on the path, then verify that node and npm both work from the terminal.

The assistant detects the operating system, picks an appropriate install method for that platform, runs it, and confirms the versions. If the path changed during installation, the assistant will usually mention that the terminal or VS Code may need a restart before the change takes effect. Node.js can also be installed manually for the relevant OS from the Node.js website download section, if the LLM struggles to install it via CLI.

This first exchange establishes the pattern for everything that follows. State the goal, let the LLM assistant run the commands, confirm the result, move to the next step.

Creating the Project

With the toolchain verified, the next request creates the application.

Create a new React TypeScript app in this folder using Vite, install the dependencies, and start the dev server so I can confirm the default page loads.

The assistant plans and sets up the project, installs packages, and starts the Vite dev server, usually at http://localhost:5173. Open that URL in a browser and confirm the default Vite page renders.

Confirming each layer before adding the next is a habit worth keeping. If a later step fails, a verified baseline makes it obvious where the problem was introduced.

Installing ComposeSDK

ComposeSDK ships as npm packages, so adding it is one request.

Add the Sisense ComposeSDK packages to this project: sdk-ui and sdk-data as dependencies, and the SDK CLI as a dev dependency.

The three packages serve distinct purposes. @sisense/sdk-ui provides the React components, the charts, dashboards, and filter UI. @sisense/sdk-data provides the query construction layer, including dimensions, measures, and filter factories. @sisense/sdk-cli is a development tool used to generate the TypeScript data model files covered later in this article, and never ships with the application.

Full ComposeSDK documentation is available on developer.sisense.com.

Connecting to the Sisense Instance

Two values connect and authenticate the CSDK application to Sisense, the instance URL and an API bearer token.

Generate the token in the Sisense web interface, from the user profile menu under API Token (Sisense documentation on generating API tokens). Copy it once generated.

The recommended approach keeps the token out of the LLM chat entirely, so the LLM never has access to it. The assistant builds the configuration with the token left blank.

Create a .env file with VITE_SISENSE_URL set to https://example.sisense.com and VITE_SISENSE_TOKEN left blank. Add .env to .gitignore, deny your own read access to .env in your permission settings, wrap the app in SisenseContextProvider using those environment variables, and tell me where to paste my token.

The assistant creates the .env file with the relevant keys, excludes it from both version control and its own file access, and points to where the token goes. Editing the URL and pasting the token into .env directly in the editor completes the setup. From that point the application can read the bearer token value but the assistant cannot.

In Claude Code specifically, the mechanism for blocking its own access is a permission deny rule rather than an ignore file. The rule lives in .claude/settings.json at the project level, or in ~/.claude/settings.json to apply across all projects.

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

The /permissions command in Claude Code can also add this rule interactively, saving it to .claude/settings.local.json. Other assistants have their own equivalents, whether ignore files or access controls. Whichever tool is in use, it is worth verifying the block before pasting the real token. Put a dummy value in .env, ask the assistant to read the file, and confirm it refuses.

Pasting the token straight into the chat and letting the assistant write the whole file also works, but is not recommended, since it means trusting the chat tool with a credential. Either way, keep .env out of version control and rotate the token if exposure is suspected. Clicking the refresh icon in the Profile bearer token page rotates the token.

A token from a viewer role user is all that is required for CSDK, as long as that user has access to every dashboard and data source the application uses. Bearer tokens are also not the only option. ComposeSDK can authenticate with Web Access Tokens (WAT) and SSO as well, which are worth considering beyond initial development (ComposeSDK authentication documentation).

The resulting setup looks approximately like this in main.tsx, the entry file Vite generates. Wrapping inside App.tsx works just as well, as long as the provider sits above every ComposeSDK component.

import { createRoot } from 'react-dom/client';
import { SisenseContextProvider } from '@sisense/sdk-ui';
import App from './App.tsx';

// The provider supplies the connection to every ComposeSDK component below it.
// Values come from .env so credentials stay out of source control.
createRoot(document.getElementById('root')!).render(
  <SisenseContextProvider
    url={import.meta.env.VITE_SISENSE_URL}
    token={import.meta.env.VITE_SISENSE_TOKEN}
  >
    <App />
  </SisenseContextProvider>
);

Smoke Testing the Connection

Before building further, it is worth confirming the application can reach and authenticate with the Sisense instance. There are two reasonable ways to do it.

The fastest is DashboardById, which renders an existing Sisense dashboard and requires no data model work in the project. Open any dashboard in Sisense and copy its OID from the browser URL.

Render the dashboard with OID 65a1b2c3d4e5f6a7b8c9d0e1 from my Sisense instance on the main page using DashboardById, replacing the default Vite content.

The alternative is a minimal chart against a known data model, which previews the widget workflow used in the rest of this article. Either one confirms the same thing, that the URL and token work and the instance is reachable from the browser.

A rendered dashboard means the connection is established. A blank or broken one usually traces back to one of these common causes.

The token is invalid or belongs to a user without access to the dashboard or data source. Regenerate the token and confirm the user can open the dashboard in Sisense directly.
The URL is incorrect, commonly a missing https:// or a trailing path. The value should be the bare instance origin.
The browser blocks the request with a CORS error. ComposeSDK typically works without any CORS configuration, but if the console shows a CORS error, an administrator can add http://localhost:5173 to the allowed origins in the Sisense Admin section under Security Settings (Sisense documentation on CORS configuration).

Browser console errors generally identify which of these applies, and the error output can be pasted straight into the chat for diagnosis.

Generating the TypeScript Data Model

ComposeSDK includes a built in tool for this step. The SDK CLI installed earlier generates a .ts file that describes the data model, listing its tables, dimensions, and measures as typed TypeScript objects, so widget code references real fields with autocomplete rather than hand typed strings. It works the same way whether the model is an ElastiCube or a live model.

Being specific in the prompt matters here. Naming the goal, a .ts file generated by the SDK's own CLI, steers the assistant toward the right tool, there otherwise being the possibility it would try to create or hallucinate its own representation.

Use the ComposeSDK CLI (the get-data-model command from @sisense/sdk-cli) to generate a .ts file describing my data model named Sample ECommerce, and save it to src/models. Use the token in .env.

Under the hood this runs a command of the following form.

# Generates a .ts file describing the data model's tables, dimensions, and measures.
# The token and URL are the same values used by the app itself.
npx @sisense/sdk-cli get-data-model \
  --url https://example.sisense.com \
  --token <token> \
  --dataSource "Sample ECommerce" \
  --output src/models/sample-ecommerce.ts

The generated .ts file exports a typed object, conventionally imported as DM, containing every table, dimension, and measure in the model. Everything built from this point on references fields through that object, which means typos become compile errors instead of silently empty charts.

Building the First Widget

With the .ts model file in place, building the first real chart is a single request.

Using the generated Sample ECommerce data model in src/models, add a column chart below the dashboard showing total Revenue by Condition.

The assistant writes a component along these lines.

import { Chart } from '@sisense/sdk-ui';
import { measureFactory } from '@sisense/sdk-data';
import * as DM from './models/sample-ecommerce';

// A minimal ComposeSDK chart: one category dimension, one aggregated measure.
<Chart
  dataSet={DM.DataSource}
  chartType="column"
  dataOptions={{
    category: [DM.Commerce.Condition],
    value: [measureFactory.sum(DM.Commerce.Revenue, 'Total Revenue')],
  }}
/>

Once it renders, iteration can be done through continued conversation or manual code editing. The Vite application will auto update with any changes, without requiring manual refreshes.

Change it to a bar chart, break it down by Gender, and only include 2024 data.

The assistant adds the breakBy entry to the data options and a date filter to the chart, and the result appears on the next hot reload. Describe a change, see it render, refine. That loop is the core of the workflow, and it is the same whether the change is a chart type, a filter, or a layout adjustment.

Styling and Structuring the Application

The same conversational approach turns the result from a test page into something that looks like an application.

Add a professional looking header and footer to the application, including the title [app title], and lay out the dashboard and the chart in cards.

What this prompt actually says will vary by user and project. The card layout here is just one option, and the assistant follows whatever visual direction it is given, from minimal to fully branded.

One distinction is worth knowing. Application CSS and widget theming are separate layers. Page layout, headers, and footers are ordinary React and CSS. The appearance of the ComposeSDK widgets themselves, including chart colors, fonts, and backgrounds, is controlled through the SDK's ThemeProvider component (ComposeSDK theming documentation). Asking for "a dark theme on the charts" versus "a dark background on the page" will, correctly, touch different code.

Working with Live Data

The ComposeSDK application itself does not typically contain or store data, though exceptions exist, a point that is often misunderstood. Every widget sends a JAQL query to the Sisense instance at render time, so the CSDK application always reflects the current state of the data model. For an ElastiCube that means fresh data appears after each build, and for a live model queries hit the source directly. In neither case does updated data require rebuilding or redeploying the application.

The generated .ts model file only needs regeneration when the schema changes, such as new fields, renamed columns, or restructured tables. Data refreshes do not affect it. When the schema does change, regeneration is one request.

My data model schema changed. Use the ComposeSDK CLI to regenerate the .ts model file and tell me if any existing widget code references fields that no longer exist.

Because the model file is typed, removed fields surface as compile errors, and the assistant can identify and fix the affected components in the same exchange.

Prompt Library

The prompts below are starting points, not strings that need to be copied exactly. Everything in this article was done conversationally, and describing the goal in natural language as it comes to mind is usually faster than locating a prompt to paste. What makes these prompts work is their specificity, with actual field names, file locations, and a clear definition of when the task is finished. Those qualities carry over to any phrasing, including a single broad prompt that covers several steps at once.

Setup and environment:

Install the latest LTS version of Node, make sure it is on the path, and verify node and npm from the terminal.

Create a React TypeScript Vite app here, install dependencies, and start the dev server.

Set up a complete ComposeSDK React app in this folder: install anything missing, create the project, add the SDK packages, and get the dev server running.

ComposeSDK installation and connection:

Add the ComposeSDK packages: sdk-ui and sdk-data as dependencies and the SDK CLI as a dev dependency.

Create a .env with my Sisense URL and a blank token, add it to .gitignore, deny your own read access to it, wire up SisenseContextProvider from those variables, and tell me where to paste my token.

The dashboard component shows a network error. Here is the browser console output: [paste]. Diagnose whether this is CORS, the token, the URL, or something else.

Data and widgets:

Use the ComposeSDK CLI to generate a .ts file for the data model named [name] into src/models.

Render the dashboard with OID [oid] using DashboardById.

Add a line chart of [measure] by [date dimension] at month granularity, with a member filter on [dimension] limited to [values].

Add breakBy on [dimension] to the existing column chart and move the legend to the bottom.

Advanced:

Use useExecuteQuery to fetch [measure] grouped by [dimension] and render the result in a plain HTML table instead of an SDK chart component.

Use onBeforeRender on the line chart to set the line width to 3 and enable data labels through the underlying Highcharts options.

The advanced prompts reference real ComposeSDK extension points. useExecuteQuery runs a query directly and returns rows for custom rendering, and onBeforeRender exposes the underlying Highcharts options object before a chart draws, allowing customization beyond the SDK's own props (useExecuteQuery reference, chart customization reference).

Useful Links

The techniques in this article generalize. Any capability in the ComposeSDK documentation, from dashboard filters to custom widget types, is reachable the same way. Describe it to the assistant with enough specificity, confirm the result in the browser, and refine conversationally.