Click UI is the ClickHouse design system and component library. Our aim with Click UI is to provide an accessible, theme-able, modern, and attractive interface with which to experience the speed and power of ClickHouse.
You can find the official docs for the Click UI design system and component library at clickhouse.design/click-ui.
- Requirements
- Quick Start
- Development
- Tests
- Storybook
- Distribution
- Assets Management
- Releases and Versions
- Nodejs (>= 22.12.x) as runtime
- Yarn (>= 4.5.3) for development, any other package manager in a host project
Install the package via npm or your favourite package manager:
npm i @clickhouse/click-ui@latestTo use Click UI, you must wrap your application in the provider. This ensures styles and themes are applied correctly across all components.
import { ClickUIProvider, Title, Text } from '@clickhouse/click-ui'
function App() {
return (
<ClickUIProvider theme="dark">
<Title type="h1">Hello ClickHouse</Title>
<Text>Start building today!</Text>
</ClickUIProvider>
)
}For more examples, including theme switching and configuration, see the How to use section, or explore our design system at clickhouse.design/click-ui.
The project uses yarn package manager for development.
After cloning the repository change to the work directory and install the dependencies:
yarnTokens are provided by a style directionary sourced from tokens-studio.
It's expected to have theme tokens provided externally, e.g. Figma tokens-studio output is stored in the repository and a PR's opened. The assets are stored in the directory [./tokens/themes].
Once [./tokens/themes] files are updated, we must regenerate the tokens:
yarn generate:tokensLearn more about tokens-studio here.
We leverage Storybook as our primary development environment and documentation, see Storybook.
You can start the Storybook development server by:
yarn devWe do NOT maintain a separate development environment; our Storybook stories serve as the source of truth for component implementation.
Important
We operate collaboratively with the Product Design team. While stories reflect the current implementation (live), Figma files remain the source of truth for design research and decision-making. Changes are typically finalized in Figma before being implemented in code to ensure design-sync.
By avoiding local preview files, we ensure that component experimentation happens in isolation; free from application side effects and providing a live look at component interfaces and usage examples at time of writing.
Note
To ensure stability, we utilize Visual Regression and Unit Testing, see tests. When contributing features or tweaks, you're expected to include or update the relevant tests to maintain stability, e.g. remember the components are consumed by a number of applications.
To get started with the development playground, refer to the Storybook section here.
The package uses vitest and react testing library for tests, e.g. functional tests.
yarn testThe project uses Chromatic for visual regression testing of UI components.
It captures screenshots of Storybook and compares them across builds to detect unintended visual changes by:
- Automated visual testing in GitHub CI/CD pipeline, e.g. storybook publish, UI tests
- Leveraging storybook stories
- Provides visual diff reviews and approval workflows
- Helps catch UI bugs
To setup, you must get a team member project token.
Add the token as an environment variable to your environment preference or profile, e.g. ~/.zshrc:
export CHROMATIC_PROJECT_TOKEN=<YOUR-TOKEN-HERE>Once ready, you can run tests by:
yarn test:chromaticNote
Chromatic does NOT generate a report in the terminal due to its cloud nature, which only outputs:
- Build status, e.g. uploading or testing
- Link to the cloud runner or dashboard
- Exit code
If you need quicker iteration feedback, or more testing control during local development, read here
The component library provides a collection of ready-to-use components. We use Storybook to showcase and document our components.
Start the storybook development server:
yarn storybookIt'll default to the location http://localhost:6006, if port available.
To build a static version:
yarn storybook:buildOnce built, you can serve the static files by:
yarn storybook:serveThe latest static version's built and deployed automatically when contributing to main of Click UI.
Once deployed it's available publicly at clickhouse.design/click-ui.
Learn to manage the versioning of changelog entries.
The following is a brief description of available commands to allow a person making a contribution make key decisions about their changes.
It'll generate a changeset, which is effectively two key bits of information:
- A version type which follows semver
- Change information placed in a changelog
Make good use of this simple workflow to help us release new package versions more confidently.
When contributing, declare an intent or describe the changes you're making or adding to a release by executing the changeset:add command.
The wizard will ask a few questions and generate a changelog entry for you:
yarn changeset:addThe changesets tool keeps track of all declared changes in the .changeset directory.
Once completed, you must commit the changeset!
To check if your branch contains a changeset:
yarn changeset:statusTo consume all changesets, and update to the most appropriate semver version and write a friendly changelog based on those changesets, the following command is available:
Important
Consuming changesets is done automatically in the CI/CD environment. For this reason, you don't have to execute the command, as a contributor your single concern should be adding changesets to any relevant changes.
yarn changeset:versionThe package is distributed as ESM.
To build the distribution version of the package run:
yarn buildNote
Optimizations are responsability of consumer or host apps, e.g. they can't remove unused code if already minified it! We ship unminified code so their build tools can: analyse and remove what they don't need or dead code, debug more easily, compress everything together in one go instead of handling conflicting compression algorithms, etc.
Navigate to your app's work directory and add the package.
Here, we use yarn but you can use your favorite package manager, e.g. pnpm.
yarn add @clickhouse/click-uiNote
Click UI should be supported by react frameworks. If you run into any issues consuming it in your react app, report it here. Provide all important details, including information on how to replicate the issue!
Once installed, wrap the application with Click UI provider:
import { ClickUIProvider } from '@clickhouse/click-ui'
export default () => {
return (
<ClickUIProvider theme='light'>
<p>Hello world!</p>
</ClickUIProvider>
);
}After, you are able to import your favorite Click UI components.
import { ClickUIProvider, Title } from '@clickhouse/click-ui'
export default () => {
return (
<ClickUIProvider theme='light'>
<Title type='h1'>Click UI Example</Title>
</ClickUIProvider>
);
}To learn more about individual components, visit Click UI components.
Deep imports are supported, you can import directly from path.
Warning
At time of writing, there are components that consume from theme provider, which means that these will fail when unwrapped. This will change in future versions.
import { Button } from '@clickhouse/click-ui/Button';Here's a quick copy and paste NextJS example with interactive components you can play:
import { ClickUIProvider, Text, ThemeName, Title, Switch } from '@clickhouse/click-ui'
import { useState } from 'react'
function App() {
const [theme, setTheme] = useState<ThemeName>('dark')
const toggleTheme = () => {
theme === 'dark' ? setTheme('light') : setTheme('dark')
}
return (
<ClickUIProvider theme={theme} config={{tooltip:{ delayDuration: 0 }}}>
<Switch
checked={theme === 'dark'}
onCheckedChange={() => toggleTheme()}
label="Dark mode"
/>
<Title type='h1'>Click UI Example</Title>
<Text>Welcome to Click UI. Get started here.</Text>
</ClickUIProvider>
)
}
export default AppThe Click UI has image asset files, such as icons or logos.
Files are originally curated in the context of the design system Figma project. Once exported/sourced from the Figma project file these have to be transformed into the Click UI desired format, e.g. an SVG as a React Component.
Here are some steps, to help you transform the Figma asset into a React Component:
- In Figma project, select and export the target image/icon, e.g. these are generally contained in a square container (64x64)
- Store the file in your local file system in a memorable location
- Use a tool to transform SVG to React JSX, e.g. react-svgr
- Create a new file in
src/components/Logos, e.g. name it by the company name - Modify the
<svg>node, it should set the size to 64x64 as the original Figma container:
Note
Notice the viewBox values, it should contain the same values from the sourced file 64x64, e.g. "0 0 64 64", if it hasn't make sure you are exporting it correctly, or the original file has the correct container width and height
<svg
width="64"
height="64"
viewBox="0 0 64 64"
fill="none"
xmlns="http://www.w3.org/2000/svg"
{...props}
>- Declare the new logo/icon in the Logos dark and light exporte files, e.g.
src/components/Logos/LogosDark.tsandsrc/components/Logos/LogosLight.ts - Finally, introduce the new icon/logo name in the types file located at
src/components/Logos/types.ts
New versions and release notes are available at GitHub Releases.
To create a new release and publish a new version, follow the instructions in publish.md.
We prefer to commit our work following Conventional Commits conventions. Conventional Commits are a simple way to write commit messages that both people and computers can understand. It help us keep track fo changes in a consistent manner, making it easier to see what was added, changed, or fixed in each commit or update.
The commit messages are formatted as [type]/[scope] The type is a short descriptor indicating the nature of the work (e.g., feat, fix, docs, style, refactor, test, chore). This follows the conventional commit types.
The scope is a more detailed description of the feature or fix. This could be the component or part of the codebase affected by the change.
Here's an example of different conventional commits messages that you must follow:
test: π Adding missing tests
feat: πΈ A new feature
fix: π A bug fix
chore: π€ Build process or auxiliary tool changes
docs: π Documentation only changes
refactor: π‘ A code change that neither fixes a bug or adds a feature
style: π Markup, white-space, formatting, missing semi-colons...