Teable AI-Native Data Management Platform

repository·develop·Indexed 12 days ago

https://github.com/teableio/teable

An AI-native data management platform combining spreadsheet-like simplicity with a PostgreSQL backend. Teable allows users to build custom apps, automate workflows with AI, and manage large-scale data. It features a topological dependency model for calculations, support for complex One-to-Many and Many-to-One relationships, and flexible self-hosting options via Docker in either Standalone or Full-featured modes.

Tokens
217.2K
Snippets
609
Records
1K
Agent score
97%

What's inside Teable

  1. Overview of v2 adapter-db-postgres-pg

    develop

    The adapter-db-postgres-pg package provides the database adapter layer for Teable v2 using the Kysely query builder with a Postgres dialect, powered by the pg driver. It is responsible for:

    • Providing the Kysely Postgres dialect.
    • Re-exporting shared Postgres DB tokens, configuration schemas, and the UnitOfWork implementation from the shared adapter package.
    • Exposing Dependency Injection (DI) helpers to register the database into application containers.
  2. Package structure of adapter-db-postgres-pglite

    develop

    The package is organized into the following structure:

    • src/createDb.ts: Contains the factory for creating the Kysely instance and the KyselyPGlite dialect.
    • src/di/register.ts: Handles Dependency Injection (DI) registration for the PGlite dialect.
    • src/di/: Contains DI registration helpers.
    • src/index.ts: The public entry point for the package exports.
  3. Use @teable/v2-utils for table rendering and formatting

    develop

    The @teable/v2-utils package provides reusable utility helpers designed for formatting and convenience. Its primary purpose is to provide utilities that depend on @teable/v2-core while remaining decoupled from the core domain logic.

    Key functionality includes:

    • Table Rendering: Using printTable.ts to render domain tables and raw record payloads into human-readable ASCII tables, which is useful for CLI tools or logging.
  4. Overview of Teable Plugins

    develop

    Plugins are extensions that integrate into specific positions within the Teable application. Official plugins are managed within a single Next.js project located in the plugins directory, which facilitates code sharing and maintenance.

    Plugins can be integrated into two supported positions defined by the PluginPosition enum:

    export enum PluginPosition {
      Dashboard = 'dashboard',
      View = 'view',
    }
  5. How computed fields are handled during record creation

    develop

    Computed fields are filtered out at multiple layers to prevent invalid manual updates:

    1. Domain Layer: table.getEditableFields() excludes computed fields from the initial set.
    2. Infrastructure Layer: A secondary check is performed using field.computed().toBoolean().
    3. Visitor Layer: The visitor returns an empty result for formula fields to ensure no database columns are targeted for these fields.
    // Visitor implementation for formula fields
    visitFormulaField(): FieldInsertResult {
      return { columnValues: {}, queryExecutors: [] };
    }
  6. Architecture of the postgresjs database adapter

    develop

    The adapter-db-postgres-postgresjs package provides a Kysely dialect backed by the postgres driver. Its primary responsibilities are:

    1. Providing the Kysely Postgres.js dialect using the postgres library.
    2. Registering a Kysely instance into the shared Postgres DB tokens.
    3. Re-exporting shared Postgres tokens, configuration, and UnitOfWork from the shared adapter package.

    Key components include:

    • src/createDb.ts: A factory for creating the Kysely instance with the PostgresJSDialect.
    • src/di/register.ts: Handles Dependency Injection (DI) registration for the postgresjs dialect.
    • src/index.ts: The public entry point for the package exports.
  7. Understand the shared domain architecture in Teable

    develop

    The domain/shared directory contains the foundational building blocks used across the Teable domain and application layers. It provides standardized abstractions for implementing Domain-Driven Design (DDD) patterns, ensuring consistency in how entities, values, and events are handled.

    Core Abstractions

    • AggregateRoot: A base class used to manage a cluster of domain objects. It is responsible for collecting and releasing DomainEvents that occur during business logic execution.
    • ValueObject: A base class for objects defined by their attributes rather than a unique identity. It defines the equality contract (ensuring two objects are considered equal if their values match).
    • Entity: A base class for objects that have a unique identity, providing a standard way to access an entity's ID.
    • DomainEvent: A standardized interface for representing things that have happened within the domain.
    • DomainError: A structured error model used to provide consistent error codes, tags, and predicates across the system.

    Key Utilities

    • IdGenerator: A helper for generating prefixed random IDs.
    • Graph Utilities: Located in the graph/ subfolder, these are used for domain ordering, such as performing topological sorts.
    • RehydratedValueObject: A specialized base class that allows for an empty placeholder value that is populated once a repository rehydrates the object.
  8. Understand the @teable/v2-core architecture and layering

    develop

    The @teable/v2-core package is organized using a layered architecture that separates write operations (commands), read operations (queries), and domain logic. This structure ensures a clear separation of concerns between application orchestration and domain modeling.

    Core Layers

    • commands/: Contains application commands and their handlers. This is the write side of the application.
    • queries/: Contains application queries and their handlers. This is the read side of the application.
    • application/: Contains application services that orchestrate domain behavior and interact with ports.
    • domain/: The core domain model, including aggregates, value objects, specifications, and domain events.
    • ports/: Defines interfaces (ports) for external dependencies, along with default or in-memory implementations and mappers.

    Layering and Implementation Rules

    • Command Handlers: Handlers can orchestrate ports and application services. However, they must not call other command handlers or re-dispatch commands through the ICommandBus.
    • Shared Logic: Any write behavior that needs to be shared across multiple handlers should be implemented as a service within application/services/.
    • Repository Responsibility: Any work that must happen immediately after data is persisted (such as schema refreshes, backfill replays, or collecting repository-originated action triggers) must reside within the repository's create, update, or delete methods. Application flows should only interact with the resulting aggregate and its emitted domain events.
  9. Understand the Application Layer responsibilities

    develop

    The application layer in Teable is responsible for orchestrating domain behavior and coordinating ports. It manages cross-aggregate workflows, transactions, and event publishing boundaries.

    Crucial Rule: The application layer must not contain domain rules. All business logic and domain rules must be delegated to domain services, entities, or visitors. If you are implementing logic that determines how a specific entity behaves, it belongs in the domain layer; if you are implementing logic that coordinates multiple entities or handles a high-level workflow, it belongs in the application layer.

  10. Understand the Formula Domain Architecture

    develop

    The domain/formula package is responsible for the core logic surrounding formula parsing and type inference. It provides the necessary infrastructure for domain value objects to understand the structure and expected types of formulas without actually executing them (evaluation).

    Key responsibilities include:

    • Parsing and Type Inference: Providing helpers to determine the types of values within a formula expression.
    • Function Registry Metadata: Maintaining metadata for registered functions to enable return type inference based on input parameters (this is metadata-only and does not perform evaluation).
  11. Computed Dependency Cascade Test Categories

    develop

    The computed/dependency-cascade.spec.ts file tests how changes to one field propagate to dependent computed fields. The test categories include:

    • Formula dependencies: Recomputation when a referenced field converts.
    • Lookup/Rollup dependencies: Metadata and value updates when the target field converts.
    • Section A (Targeted Seeding): Verifies that property changes (like renaming a select option or reducing rating max) only trigger seeding for affected records.
    • Section B (Type Conversion Seeding): Verifies that type conversions (e.g., text → number) trigger seeding for all records.
    • Section C (Cross-table dependencies): Tests lookup/rollup seeding when a field in a foreign table is updated via a link.
    • Section D (Formula Compatibility): Ensures formulas correctly handle hasError states or maintain functionality during compatible type conversions.
    • Section E (Link Updates): Tests how relationship changes (e.g., oneWay to twoWay) affect dependents.