Forem: Ghofrane Baaziz

How do you add block-level AI actions to a Retool custom component?

Ghofrane Baaziz — Wed, 22 Apr 2026 14:38:51 +0000

We built a custom AI-powered rich text editor as a Retool custom component for a client's internal support tool and walked through it live at Retool's Build Together session this week. The component gives support operators block-level AI actions: rewrite a paragraph, summarize a section, draft a reply from ticket context without leaving the tool.

This post covers why we built it as a custom component, how the architecture works, and how to wire it up in your own Retool app.

Repo: github.com/StackdropCO/retool-ai-editor

Why can't you use a Retool text area with AI actions?

Two reasons: granularity and structured output.

Retool's stock text area gives you a string. AI acting on a string means acting on the whole thing: if an operator wants to rewrite one paragraph out of five, the text area has no concept of that block. You'd need to write your own selection logic, parse the string, find the boundaries, and reconstruct the document after the transformation. That logic lives outside Retool's low-code surface entirely.

The second problem is downstream. Once the operator is done editing, you need to send structured data to queries, tables, and workflow nodes. Parsing a markdown or HTML blob at that stage is unnecessary work.

The combination of block-level targeting and structured JSON output pointed to editor.js.

What does editor.js give you that a text area doesn't?

Editor.js is a block-style rich text editor, think Notion's content model. Every paragraph, heading, and list item is its own independent JSON object. The output isn't a string, it's a structured document:

{
  "blocks": [],
  "time": 0,
  "version": ""
}

You can see this directly in Retool's inspector panel when the component is selected, the editorData output updates in real time as the operator types, and you can bind it to any downstream component:

{{ AIEditor1.editorData.blocks }}

Each block has its own type, content, and identity. That means you can target a specific block with an AI transformation without touching anything else in the document.

Editor.js also runs as real React inside Retool's custom component environment so no sandboxing, no allow list. It installs from npm without modification and supports hooks, refs, effects, CSS modules, and TypeScript.

How does the AI wiring work inside a Retool custom component?

The component exposes two events to Retool: aiTransformRequest and editorChange.

When an operator triggers an AI action, the component sets a group of state properties first, then fires aiTransformRequest. This is a standard Retool custom component pattern: events carry no payload, so state is set before the event fires, and the connected query reads from state:

// Component sets state, then fires the event
setTransformBlockContent(content)
setTransformType(type)
setTransformBlockId(blockId)
setTransformScope(scope)
aiTransformRequest()

// In Retool, the query reads:
{{ AIEditor1.transformBlockContent }}
{{ AIEditor1.transformType }}

Retool runs the connected ai_transform JavaScript query, which calls your LLM endpoint, handles the response, and pushes the result back into the component:

aiEditor1.setValue('transformResponse', raw.trim() + salt)

The salt is String.fromCharCode(8203), a zero-width space that forces Retool to detect a value change even when the AI returns identical text twice in a row.

The prompt, the model, and the context all live in the Retool query, not inside the component. That means anyone configuring the app can change how the AI behaves without touching component code.

The full data flow in the query graph: aiEditor1 → ai_transform → anthropic_api.

What AI actions does the component support?

Three actions, and they work differently depending on how they're triggered.

Rewrite and Summarize: block tune actions

Every block gets an AI action menu in its settings panel (the three-dot toolbar on hover). Rewrite and Summarize live here. When triggered, the component fires aiTransformRequest with transformScope: 'block' and the block's text content in transformBlockContent. The LLM response replaces that specific block in place via editor.blocks.update(id, data) no index math, no re-inserts.

Draft reply: slash-menu action

Typing / opens the slash menu with a Draft reply entry. Selecting it inserts a dimmed, pulsing placeholder block and fires aiTransformRequest with transformScope: 'insert' and transformType: 'draft'. For this action, transformBlockContent is empty, the draft is grounded entirely from app state you pass to the query: ticket context, previous messages, CRM data, whatever's available. The component splits the response on blank lines and replaces the placeholder with one paragraph block per chunk.

What does the file structure look like?

src/
  components/
    AIEditor/
      index.tsx             # React component — all Retool state/event wiring
      AITransformTune.ts    # Block Tune: per-block Rewrite and Summarize actions
      AIAction.ts           # Block Tool: slash-menu Draft reply action
      AIEditor.module.css   # Container styles
  index.tsx                 # Barrel export

The Retool-specific surface is contained in index.tsx. To use this outside Retool, swap the Retool state hooks for useState and component props, everything else is pure editor.js and React.

How do you add this component to a Retool app?

1. Clone and install

git clone https://github.com/StackdropCO/retool-ai-editor ai-editor-retool
cd ai-editor-retool
npm install
npx retool-ccl login
npx retool-ccl dev

Dev mode syncs your local changes to Retool on every save. Drag the AIEditor component onto any canvas.

2. Create your transform query

Create a JavaScript query that calls your LLM endpoint (Retool AI, OpenAI, Anthropic, or any other). Switch on {{ AIEditor1.transformScope }} to handle block transforms vs. draft inserts, then on {{ AIEditor1.transformType }} for the specific action. Use {{ AIEditor1.transformBlockContent }} as user content for block-scope transforms.

The query runs in the full Retool app scope, so you can reference any query or component directly in the prompt:

{{ someTable.selectedRow }}
{{ ticketQuery.data }}

3. Add the event handler

On the AIEditor1 component:

Event: aiTransformRequest
Action: Trigger your transform query
Then: Set AIEditor1.transformResponse to {{ yourTransformQuery.data }}

The component handles the rest, routing the response to the right block, replacing the placeholder, or updating in place.

4. Deploy

npx retool-ccl deploy

This pushes an immutable version to your Retool instance. Anyone in the org can drag it onto a canvas like any stock component.

Component properties reference

Output: component writes, your app reads

Property	Type	Description
`editorData`	object	Full editor.js JSON, updated on every change (debounced 400ms)
`transformBlockContent`	string	Text of the block being transformed (empty for `insert` scope)
`transformType`	string	`summarize`, `rewrite`, or `draft`
`transformBlockId`	string	editor.js id of the block being transformed or replaced
`transformScope`	string	`block` (tune-menu) or `insert` (slash-menu Draft reply)

Input: your app writes, component reads

Property	Type	Description
`transformResponse`	string	LLM response. Bind to your query result.
`readOnly`	boolean	Toggle read-only mode from your app.

What are the limits of this component?

It starts to feel heavy past around 50 blocks, fine for replies, drafts, and short-form content, but not the right fit for long documents or articles.

No collaborative editing. This is an editor.js limitation. The library doesn't support it natively, and neither does this component.

No streaming on AI responses. The editor waits for the full response before rendering. It shows a "Drafting reply..." loading state while the query runs.

What's next?

We're working on a Bynder asset management integration as the next component. Same approach: encapsulate a third-party library's API into a custom component, expose enough surface for end users to configure without touching code.

If you have questions on the build or want to adapt it for a different use case, drop them in the comments.

Repo: github.com/StackdropCO/retool-ai-editor

Built by John Miniadis at Stackdrop, a Retool-certified agency building governed internal tools for mid-market and enterprise clients across EMEA.

FAQ

Can I use this editor.js component outside of Retool?
Yes. The Retool-specific wiring is isolated to one file (index.tsx). Replace the Retool state hooks with useState and component props, and you have a standalone React component with no Retool dependency.

Does this work with any LLM, or only Anthropic?
Any LLM endpoint works. The component fires a Retool event, and your query handles the API call. You can use Retool AI, OpenAI, Anthropic, or any custom endpoint. The response shape handling in the query supports multiple formats (data?.content?.[0]?.text, data?.completion, data?.answer, data?.text).

How does the component pass block content to the Retool query?
Retool custom component events carry no payload, so the component sets state properties before firing the event. Your query reads {{ AIEditor1.transformBlockContent }} for the block text, {{ AIEditor1.transformType }} for the action, and {{ AIEditor1.transformScope }} to distinguish between block transforms and slash-menu inserts.

What happens if the AI returns the same text twice in a row?
The component appends a zero-width space (String.fromCharCode(8203)) to every response before writing it back. This forces Retool to detect a value change and trigger the update even when the text is identical.

When should I use a custom component instead of a stock Retool text area?
When you need structured output (JSON per block rather than a string), block-level event handling, or UI elements that stock inputs don't support, custom menus, inline toolbars, placeholder animations, and slash commands. If a string output and simple AI actions on the whole field are sufficient, the stock text area is the simpler choice.

PostgreSQL INT4RANGE: Enforce non-overlapping zones in SQL

Ghofrane Baaziz — Mon, 20 Apr 2026 22:11:32 +0000

Originally written by Omar Tarek, Software Developer at Stackdrop. Posted here with his permission.

When you need to assign geographic zones to records in PostgreSQL without overlap, the INT4RANGE type handles range storage, containment queries, and conflict enforcement natively without you writing a single manual comparison.

The problem: why range assignments fail silently with start/end fields

Here's a schema most people reach for first:

CREATE TABLE postal_code_assignments (
    assignment_id SERIAL PRIMARY KEY,
    agent_id INTEGER,
    start_code INTEGER,
    end_code INTEGER DEFAULT NULL
);

Single code lookups are fine:

SELECT agent_id
FROM postal_code_assignments
WHERE 19406 BETWEEN start_code AND COALESCE(end_code, start_code);

Overlap detection is not. To check whether an incoming range (A, B) conflicts with an existing (C, D), you have to manually cover: partial left overlap, partial right overlap, full containment in either direction, and single-value edge cases. That logic has to live somewhere in the application, it has to be replicated everywhere ranges are written, and the database will not catch it if you miss a path.

We built an admin tool for a sales operations team where agents are assigned postal code zones across a country. A silent overlap means one postal code shows up in two agents' zones, duplicated contacts, broken sales attribution, and no visibility into which assignment is wrong. We needed the database to enforce this, not the application.

INT4RANGE: what it is and how it works

INT4RANGE is a native PostgreSQL type that stores an integer range as a single value. The notation follows standard interval math:

[19400,19500]: 19400 through 19500 inclusive
[19306,19307): exactly 19306 (single value in canonical half-open form)
(19300,19400): all integers strictly between the bounds

The type ships with operators you actually need: && (overlap), <@ (containment), -|- (adjacency). These work with GiST indexes, so the database can run them efficiently at query and write time.

The schema:

CREATE TABLE postal_code_assignments (
    assignment_id SERIAL PRIMARY KEY,
    agent_id INTEGER,
    postal_code_range INT4RANGE,
    deleted BOOLEAN NOT NULL DEFAULT false,
    FOREIGN KEY (agent_id) REFERENCES sales_agents(agent_id),
    EXCLUDE USING GIST (postal_code_range WITH &&) WHERE (deleted IS NOT TRUE)
);

That EXCLUDE USING GIST line is the key part. It tells PostgreSQL to index the range column with GiST and reject any insert or update where the new range overlaps an existing one. The partial predicate WHERE (deleted IS NOT TRUE) excludes soft-deleted rows, so you can keep historical assignments without triggering false conflicts.

Inserts, lookups, and display

Single code:

INSERT INTO postal_code_assignments (agent_id, postal_code_range)
VALUES (4, '[19306,19307)');

Range:

INSERT INTO postal_code_assignments (agent_id, postal_code_range)
VALUES (5, '[19400,19500]');

Any overlapping insert is rejected immediately by the constraint. No pre-check query needed.

Ownership lookup:

SELECT agent_id
FROM postal_code_assignments
WHERE int4range(19406, 19407) <@ postal_code_range;

Readable display (PostgreSQL normalizes to half-open form, so subtract 1 from upper for inclusive end):

SELECT
  assignment_id,
  agent_id,
  lower(postal_code_range) AS start_postal_code,
  upper(postal_code_range) - 1 AS end_postal_code
FROM postal_code_assignments;

How does EXCLUDE USING GIST enforce non-overlapping zones?

EXCLUDE USING GIST is a table constraint that uses a GiST index to enforce that no two rows satisfy a given operator condition. In this case, the overlap operator && applied between any two rows.

GiST (Generalized Search Tree) is PostgreSQL's extensible indexing framework. Range types are designed to work with it, so the index can efficiently check whether an incoming value overlaps anything already in the table before the write is committed.

The WHERE (deleted IS NOT TRUE) partial predicate means soft-deleted rows are outside the constraint scope. Assignments that have been superseded stay in the table for audit purposes without blocking new assignments that cover the same zones.

Overlap validation moves from application code into the database itself. No pre-insert check query in your API, no validation function in your ORM, no race-condition-prone read-then-write pattern. The constraint fires on every write path.

Surfacing conflicts before writing updates

The GIST constraint blocks invalid writes but raises an error without context. In an admin UI, the admin needs to see both the incoming assignment and the existing conflicting record. A CTE handles this cleanly:

WITH updates AS (
    SELECT * FROM (VALUES
        (1::INT, 3::INT, '[19400,19450]'::int4range),
        (2::INT, 4::INT, '[19500,19600]'::int4range)
    ) AS t(id, sales_person_id, new_range)
),
conflicts AS (
    SELECT u.id AS update_id, p.id AS existing_id, p.postal_code_range
    FROM postal_code_assignments p
    JOIN updates u ON p.postal_code_range && u.new_range AND p.id != u.id
),
update_action AS (
    UPDATE postal_code_assignments p
    SET
      postal_code_range = u.new_range,
      agent_id = u.sales_person_id
    FROM updates u
    WHERE p.id = u.id
    AND NOT EXISTS (SELECT 1 FROM conflicts WHERE update_id = u.id)
    RETURNING p.id
)
SELECT 'conflict' AS result, c.update_id, c.existing_id, c.postal_code_range
FROM conflicts c
UNION ALL
SELECT 'update' AS result, a.id, NULL::INT, NULL::INT4RANGE
FROM update_action a;

Three stages: updates holds the incoming batch, conflicts checks each against existing rows using &&, update_action writes only the clean ones. The result set comes back tagged 'conflict' rows carry the overlapping record details, 'update' rows confirm what was saved. The application routes on the result column.

In our case, the updates CTE is populated via a Retool template literal, injecting a dynamic array at runtime. In a standard backend, replace that with a parameterized VALUES list from your application layer.

Tradeoffs worth knowing

INT4RANGE is PostgreSQL-specific. If you ever need to run this on MySQL or SQLite, you are back to the start/end approach. For Postgres-native stacks, the tradeoffs are almost entirely in its favour:

Overlap detection is a single operator, not a multi-condition WHERE
The constraint lives in the schema, not scattered across application code
GiST indexing performs well on containment and overlap queries at scale
The only real cost is a small write overhead from the GiST index; negligible for admin tool volumes, worth benchmarking at high insert rates

TL;DR

If you are on PostgreSQL and need non-overlapping integer ranges, INT4RANGE with EXCLUDE USING GIST is the right tool. It enforces the invariant at the database level, keeps overlap logic out of your application, and handles containment and conflict queries with native operators.

Happy to answer questions on the CTE pattern or the GiST constraint setup.

Why Retool's PDF Component Doesn't Render Your Signed S3 URL (And How to Fix It)

Ghofrane Baaziz — Mon, 20 Apr 2026 12:39:58 +0000

Originally written by Arsany Milad - Software Developer @ Stackdrop, posted here with his permission

Retool's PDF component uses fetch() to load files. Browsers enforce CORS on fetch requests. If your S3 bucket isn't configured to allow requests from Retool's origin, the request gets blocked silently and the component renders nothing. Adding Retool's domain to the bucket's CORS configuration fixes it.

Why does a signed S3 URL load correctly in a browser tab but fail silently inside Retool's PDF component?

On a random Friday I found myself working on an invoicing feature: add expense info, upload files, save, done. But when I tried to open the uploaded PDF inside the app it just showed "PDF couldn't be loaded."

![PDF could not be loaded error in Retool]

The Retool console wasn't helpful, so I checked the browser console and found this:

Access to fetch at 'https://<s3-endpoint>/<path>/document.pdf?<signed-url-params>'
from origin 'https://app.retool.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

The signed URL was valid — pasting it directly into the browser tab opened the PDF without issue. The problem was specific to the PDF component.

Here's why. When you paste a URL into the address bar, the browser performs a top-level navigation request. CORS rules don't apply to navigation. When Retool's PDF component loads a file, it calls fetch() internally. Fetch requests are cross-origin requests, and the browser enforces CORS on them. If the S3 bucket's CORS configuration doesn't include Retool's domain in AllowedOrigins, the browser blocks the response before the component receives anything.

Both the URL and the signature are valid. The bucket just hasn't been told that Retool's domain is allowed to make cross-origin requests to it.

How do you configure S3 CORS to allow Retool's PDF component to load signed URLs?

This is a CORS configuration change on the S3 bucket. No IAM changes, no bucket policy edits, no changes to how you generate signed URLs.

Step 1: Open the bucket in AWS

Log into the AWS Console
Navigate to S3
Select the bucket your Retool app is reading from
Go to Permissions
Scroll to CORS configuration
Click Edit

Step 2: Add the CORS configuration

[
  {
    "AllowedHeaders": ["*"],
    "AllowedMethods": ["GET", "HEAD"],
    "AllowedOrigins": [
      "https://app.retool.com"
    ],
    "ExposeHeaders": [
      "ETag",
      "Content-Type",
      "Content-Disposition"
    ],
    "MaxAgeSeconds": 3000
  }
]

If your Retool instance runs on a custom subdomain (e.g. https://yourcompany.retool.com), replace https://app.retool.com with your actual domain. Use only the specific domains you control — wildcards like *.retool.com cover every Retool-hosted app across all customers, not just yours.

What each field does:

Field	Purpose
`AllowedOrigins`	Tells S3 which domains are permitted to make cross-origin requests
`AllowedMethods`	Restricts which HTTP methods those origins can use
`AllowedHeaders`	Permits the headers Retool includes in its fetch requests
`ExposeHeaders`	Makes file metadata — content type, disposition, ETag — readable by the browser
`MaxAgeSeconds`	Controls how long the browser caches the preflight response

Note on PUT: The template above uses GET and HEAD only, which is enough for rendering PDFs. If your app also uploads files directly to S3 from the browser via presigned upload URLs — as in my case with invoice uploads — add "PUT" to AllowedMethods. If uploads go through your backend, you don't need it.

Step 3: Save and verify

Save the configuration. Hard-refresh Retool with Ctrl+Shift+R. Open DevTools → Network tab, reload the PDF component. The S3 response should now include:

Access-Control-Allow-Origin: https://app.retool.com

![PDF rendering correctly after CORS fix]

How should S3 CORS be configured when Retool has separate production and staging environments?

List each domain explicitly in AllowedOrigins:

"AllowedOrigins": [
  "https://yourapp.retool.com",
  "https://yourapp-staging.retool.com"
]

Keep this list as narrow as possible. A wildcard ("*") on a private bucket allows cross-origin requests from any domain. Explicit origins are always the right call on a bucket serving private documents.

When does an S3 CORS configuration for Retool need PUT or POST in AllowedMethods?

For rendering PDFs and images, GET and HEAD are sufficient. You only need PUT if the browser is uploading files directly to S3 via presigned upload URLs initiated from the frontend. If uploads go through your backend or a Retool resource connection, the browser never makes the upload request, so PUT isn't needed.

Only add methods you actively use. Each one you include extends the surface area of what cross-origin requests can do on that bucket.

What are the most common mistakes that cause S3 CORS issues to persist in Retool after applying a fix?

Treating the symptom as a signing issue. The signed URL works in the browser, so the signature is fine. CORS is a separate layer. The URL can be perfectly valid and still get blocked at the fetch level.

Using "*" as the allowed origin. This removes the origin restriction entirely. On a private bucket serving sensitive documents, explicit domains are the right call.

Using *.retool.com as the allowed origin. This wildcard covers every Retool-hosted app across all customers, not just yours. Always use your specific Retool domain.

Skipping the hard refresh. Browsers cache preflight responses for the duration set in MaxAgeSeconds. If you test immediately after saving without a hard refresh, the browser may still be acting on the cached response from before the fix. Ctrl+Shift+R clears this.

Editing the wrong bucket. If production and staging use different buckets, confirm which one your Retool app is reading from before making the change.

What is the workaround for loading private S3 files in Retool when the bucket CORS configuration cannot be modified?

Two options.

The first is to use Retool's built-in S3 resource to read the file server-side. Because the request originates from Retool's backend rather than the browser, CORS doesn't apply. The tradeoff is memory management — PDFs are large and you'll need to handle query cleanup after use to avoid memory issues.

The second is to proxy the file through your own backend: fetch the object server-side, encode it as base64, and return it to Retool as a data URI:

data:application/pdf;base64,...

Same principle — server-to-server requests aren't subject to browser CORS enforcement. The memory and latency cost scales with document size, which becomes significant with large files or high request volume. Modifying the bucket CORS configuration is the better long-term solution where access permits it.

FAQ

Why does a signed S3 URL open correctly in a browser tab but fail to load inside Retool's PDF component?

When you open a signed URL directly in a browser tab, the browser performs a top-level navigation request. CORS rules don't apply to navigation. When Retool's PDF component loads the same URL, it uses fetch() internally. Fetch requests are cross-origin requests and the browser enforces CORS on them. If the S3 bucket's CORS configuration doesn't include Retool's domain in AllowedOrigins, the browser blocks the response before the component receives anything. The PDF component renders nothing and gives no visible error in the UI.

How do I fix a CORS error blocking a signed S3 URL from loading in the Retool PDF component?

Add your specific Retool domain to the CORS configuration on the S3 bucket serving the files. In the AWS Console, go to S3 → your bucket → Permissions → CORS configuration → Edit, and add https://app.retool.com (or your custom subdomain) to AllowedOrigins. Save the config and hard-refresh Retool with Ctrl+Shift+R. This is a bucket-level change — no IAM or bucket policy edits are required.

I updated the S3 CORS configuration but Retool's PDF component is still blocked. What should I check?

The most common cause is a cached preflight response. Browsers cache CORS preflight results for the duration set in MaxAgeSeconds. If you test without a hard refresh (Ctrl+Shift+R), the browser may still be acting on the cached response from before the fix. If a hard refresh doesn't resolve it, open DevTools → Network and confirm Access-Control-Allow-Origin is now present in the S3 response. If it's still missing, verify you edited the correct bucket — production and staging buckets are separate.

Does the S3 CORS fix for Retool's PDF component also apply to image components and other file types?

Any Retool component that loads files using fetch() can be blocked by missing CORS headers. The PDF component is the most common case because PDFs are typically served from private buckets via signed URLs. If you encounter the same symptom with another component type — the URL works in a browser but the component renders nothing — the fix is the same: add Retool's domain to AllowedOrigins on the S3 bucket serving those files.

Is there a workaround for loading private S3 files in Retool when the bucket CORS configuration cannot be modified?

Yes. You can use Retool's built-in S3 resource to fetch the file server-side, or proxy it through your own backend and return it as a base64 data URI (data:application/pdf;base64,...). Both approaches bypass browser CORS enforcement because the request originates from a server rather than the browser. The memory and latency cost scales with document size — modifying the bucket CORS configuration is the better long-term solution where access permits it.

Arsany Milad is a developer at Stackdrop, a Retool-certified agency building governed internal tools for mid-market and enterprise clients across EMEA.

I built a custom range slider for Retool with a histogram built in

Ghofrane Baaziz — Mon, 24 Nov 2025 13:24:21 +0000

I built a custom range slider for Retool with a histogram built in

Range sliders in Retool are great until you need to understand your data. They let you pick min and max values, but they don’t tell you anything about the distribution itself.

I kept running into this when building internal tools, so I built a custom range slider that includes a histogram, handles uneven distributions and exposes clean values. It’s written in TypeScript and works as a native Retool component.

🔗 GitHub repo: https://github.com/StackdropCO/custom-range-slider-retool-component

🔗 More Awesome Retool components here: https://github.com/StackdropCO/awesome-retool-components

Here’s why I built it and how to use it.

Why I built this

A real example that pushed me to do this:

I needed a filter for “years of experience” inside a Retool app. Most candidates had between 0 and 20 years, but a few outliers had 45 years. With the standard slider, you get min and max, but no clue whether the middle ranges are empty or dense.

It forces you to guess, or worse, manually inspect the dataset.

To show what I mean:

Retool’s default slider (no visibility):

Custom Range Slider with distribution visible:

The histogram makes it obvious where your data actually sits. In my case, the “20 to 45 years” range was basically empty. With a logarithmic scale, even large skewed values become readable.

This small change makes filtering more honest and more useful.

What I focused on while building it

Here are the engineering decisions that mattered:

Histogram built in

Shows distribution directly on the slider.
Multiple scales

Linear, logarithmic and square root for different distribution shapes.
Clean values

Access the selected range through selectedRange.start and selectedRange.end.
Flexible inputs

Arrays, number lists, query outputs — anything numeric.
Click-to-select

Click any histogram bar to jump to that range.
Custom colors

Fully themeable inside Retool.
Negative values supported

Useful for datasets that include offsets or deltas.

Installation

Clone the repo:

git clone https://github.com/StackdropCO/custom-range-slider-retool-component.git

Install dependencies

cd custom-range-slider
npm install

Log in to Retool and initialize

npx retool-ccl login
npx retool-ccl init

Start development mode

npx retool-ccl dev

Deploy the component

npx retool-ccl deploy

Using it in Retool

Drag the Range Slider component onto the canvas.
Define start and end values:

start: 0

end: 50
Custom formatting:

(v) => {
  if (v === 0) return `${v}`
  if (v === 1) return "1 year"
  return `${v} years`
}

Bind distribution data:

{{ query2.dataArray }}
Access the selected range:

const { start, end } = customRangeSlider1.selectedRange

Switch scales if your data is skewed:
- Linear (default)
- Logarithmic
- Square root

Quick checklist

Use a published version for production
Test locally with npx retool-ccl dev
Deploy and pin the version in your Retool app
For multi-instance setups, use npx retool-ccl sync

What's next

A few improvements I'm exploring:

Auto-generated histograms from simple arrays
More control over spacing and styling
Optional statistics like mean and median
Additional scale types
General cleanup and refinements

Get involved

I built this to make filtering inside Retool more accurate, especially with uneven distributions. It's fully open source, and I'd love feedback, ideas or pull requests.

If you try it, let me know how it works for you.

Happy building!

Resources

Interested in learning more about this component? Check out the full component library and documentation.