Frontend: UI Component Library
Relevant source files
The following files were used as context for generating this wiki page:
The Nucleus project utilizes a monorepo architecture where the frontend UI is built upon a shared library of components, elements, and static assets. This library is designed to ensure consistency and reusability across the different product applications, such as Nucleus, Memotron, and Pointron. The core technologies for the frontend are SvelteKit and TailwindCSS.
The UI library is structured into distinct packages, primarily components, elements, and static, which are consumed by the individual product applications. This modular approach simplifies development, testing, and maintenance. The entire system is orchestrated using Turbo for efficient build processes.
Sources: WARP.md:8-14, README.md:37-38
Architecture and Structure
The UI component library is part of a larger monorepo structure. The key directories related to the frontend component system are located under packages/ and client/. Product-specific applications that consume these shared libraries reside in apps/.
packages/: Contains shared libraries, including UI elements, components, types, and utilities.client/: Historically contained frontend code, but is being migrated to thepackages/andapps/structure. It still holds some product-specific implementations and data sources.apps/: Contains the deployable product applications, such asnucleus-app.
Sources: WARP.md:15-23, test-setup.js:13-24
Package Hierarchy
The following diagram illustrates how product applications consume the shared UI packages.
This diagram shows the nucleus-app depending on various shared packages from the @21n scope, including UI-specific ones like components, elements, and static.
Sources: apps/nucleus/package.json:76-83, test-setup.js:14-15
Key UI Packages
The UI library is divided into several key packages, each with a specific responsibility.
| Package | Description | Source File |
|---|---|---|
@21n/components | Contains complex, shared UI components used across multiple products. These are composed of smaller elements. | test-setup.js:14 |
@21n/elements | Contains basic, atomic UI elements like buttons, inputs, etc. These are the fundamental building blocks for more complex components. | test-setup.js:14 |
@21n/static | A shared package for all static assets, including icons, sounds, and images. It provides a centralized and type-safe way to access assets. | client/static/README.md:1-3 |
@21n/types | Holds shared TypeScript type definitions, ensuring data consistency between components and data sources. | test-setup.js:14 |
Component Data and Content
Components are often driven by structured data loaded from TypeScript files or JSON. This separation of data and presentation allows for flexible and maintainable UI.
Feature Wheel Component Data
An example of this pattern is the data structure for the "Feature Wheel" component used on the Memotron comparison page. The data is defined in memotronWheel.ts and includes categories, features, and competitor information.
The features are organized into several categories defined by the MemotronFeatureCategory enum.
| Category | Color |
|---|---|
Capture | #2A8CAB |
Clipping | #4E9973 |
Content | #1E9B92 |
Curation | #D4A534 |
Views | #AA6A6A |
RetrievalAndSynthesis | #7E49A1 |
App | #4287f5 |
Sources: client/landing/routes/compare/memotronWheel.ts:16-30
Each feature is an object conforming to the IFwFeature interface, containing properties like label, slug, description, and ratingCriteria.
// client/landing/routes/compare/memotronWheel.ts:63
export const features: IFwFeature[] = [
// App features
{
label: "Source",
slug: "source",
category: MemotronFeatureCategory.App,
icon: "source",
learnMoreLink: "https://docs.memotron.app/memotron/source",
progress: 1,
isProminent: true,
description:
"Source available codebase allowing public access and contributions with transparent development process",
ratingCriteria: [
// ...
],
// ...
},
// ...
];
Sources: client/landing/routes/compare/memotronWheel.ts:4-8, client/landing/routes/compare/memotronWheel.ts:63-89
External Data Integration
Component data can also be sourced from external JSON files. For instance, the competitive analysis data for Notion is stored in notion.json. This file includes ratings and notes for various features, which are then loaded and associated with the corresponding feature definitions.
// client/cx/contemporaries/notion.json:48
{
"feature": "privacy",
"rating": 0.3,
"notes": "Notion doesn't take offline-first approach and does not have end-to-end encryption for cloud sync. Notion does have a [bug bounty program](https://www.notion.so/notion/Responsible-Disclosure-Policy-5f18bb6b86804eaf989c006131778b9c) and [discloses](https://www.notion.so/notion/Privacy-Policy-3468d120cf614d4c9014c09f6adc9091) that it does not sell user data for external use by other companies."
}
This data is loaded by a loader function (getContemporariesForFeature) and mapped to the feature objects.
Sources: client/cx/contemporaries/notion.json:48-52, client/landing/routes/compare/memotronWheel.ts:800-804
Static Assets (@21n/static)
The @21n/static package centralizes all shared static assets. It provides a Vite plugin for easy integration into SvelteKit apps and exports asset paths for type-safe usage in components.
Available Assets
The package includes a variety of assets:
| Asset Type | Examples - icons/sprite-*.svg (Lucide, Phosphor, Solar) - sounds/*.mp3 (dingding, tick, upchime) - monaco-editor/* assets |
|---|
Sources: client/static/README.md:18-32, client/static/assets-manifest.json
Usage in Svelte
The assets can be imported and used directly within Svelte components, providing a clean and maintainable way to manage static files.
<script>
import { assets } from 'static';
</script>
<img src={assets.nucleusLogo} alt="Nucleus Logo" />
<audio src={assets.sounds.upchime} />
<img src={assets.icons.arrowBack} alt="Back Arrow" />
Sources: client/static/README.md:10-16
Dependencies and Tooling
The nucleus-app relies on a rich ecosystem of libraries and tools for development, testing, and building.
| Dependency | Version | Usage |
|---|---|---|
svelte | ^4.2.7 | Core frontend framework. |
@sveltejs/kit | ~2.5.28 | Application framework for Svelte. |
tailwindcss | ^3.2.4 | Utility-first CSS framework for styling. |
storybook | ^7.6.3 | UI component development, testing, and documentation. |
vitest | ^2.0.5 | Unit testing framework. |
vite | ^5.0.3 | Build tool and dev server. |
@21n/components | * | Shared complex UI components. |
@21n/elements | * | Shared atomic UI elements. |
@21n/static | * | Shared static assets. |
monaco-editor | ^0.52.0 | The code editor that powers VS Code, used for advanced text inputs. |
@carbon/charts-svelte | 1.13.6 | Charting library for data visualization. |
@antv/g6 | ^5.0.26 | Graph visualization engine. |
Sources: apps/nucleus/package.json:37-118
Development and build processes are managed via npm scripts defined in package.json, which leverage Vite and Turbo. Key scripts include dev for starting the development server, build for creating a production build, and storybook for launching the Storybook UI.
Sources: apps/nucleus/package.json:5-24
In summary, the Nucleus frontend is built on a robust and modular UI component library. This architecture promotes code reuse, consistency, and maintainability across its suite of productivity applications. By separating concerns into distinct packages for components, elements, and static assets, the system allows developers to build and scale the user interface efficiently.