Skip to content

Latest commit

 

History

1,023 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Banner

Decaf's Angular Module

Release docs refreshed on 2025-11-26. See workdocs/reports/RELEASE_NOTES.md for ticket summaries.

Licence GitHub language count GitHub top language

Build & Test CodeQLSnyk Analysis Pages builder .github/workflows/release-on-tag.yaml

Open Issues Closed Issues Pull Requests Maintained

Line Coverage Function Coverage Statement Coverage Branch Coverage

Forks Stars Watchers

Node Version NPM Version

Documentation available here

Minimal size: unknown kb gzipped

Description

A very versatile persistence layer. from smart contracts, Digital wallets or just regular database access

How to Use

Graph frontend (DECAF-50)

The canonical graph frontend (DECAF-50 §4.12, §4.17–§4.20) is manifest-driven and document-native — no node constructors, no legacy config store, no flag mechanics reach the browser:

  • Catalogue (src/graph/catalog/): GraphNodeCatalogService loads/refreshes GraphNodeManifest[] (palette consumes manifests; adding a node creates a GraphNodeInstance via GraphNodePaletteFactory and dispatches node.add). Sources: GraphNodeCatalogApi (backend), offline GraphNodeManifestFixtures (compiled from the demo's decorated classes with the ui-decorators compiler — demo-decorated kinds stay locally authoritative), and GraphNodeCatalogCompositeSource merging both. The catalogue service pairs a decaf @service() registry singleton with an Angular Injectable({providedIn:'root'}) root provider (normative pairing, spec §4.12); @graphAngularServiceShare (from src/graph/utils/graphAngularServiceShare.ts) re-attaches the Angular provider to the decaf @service() wrapper class so DI resolves either shape.
  • Document layer (src/graph/document/): GraphWorkflowDocumentStore (canonical document state; every semantic mutation is a command), GraphDiagramMutationTranslator + GraphDiagramAdapter (projection is a pure function of document + manifest reader; canvas mutations become document commands, never the reverse), GraphDocumentSelectors/GraphDocumentCommands.
  • Editing (src/graph/components/): node edit modal, switch case editor, and node templates all seed from the document's GraphNodeInstance/canvas data and save through the store. Edit results update the store directly — GraphNodeConfigStore is gone.
  • Parameter renderers (src/graph/parameters/): 12 built-in typed renderers (text, multiline, number, boolean, static/dynamic options, collection, object, code, expression, resource locator, credential, notice, hidden) registered in GraphParameterRendererRegistry, with generic fallback rendering, visibility DSL evaluation, manifest validation, and dependency-triggered dynamic options reload.
  • Runs (src/graph/runs/): GraphRunClient/GraphRunEventClient/GraphRunStateStore wire the editor document to the backend run API, including live node/edge event mapping and terminal-state semantics (DECAF-48).

Boundary guarantee: no graph engine, executor, catalogue runtime, validator, or run-store code reaches the production browser bundle (§4.20 bar 1 — enforced by the TASK-233 bundle scan).

Graph demo

src/app/pages/graph/graph.page.ts hosts the demo (workflow editor + run console) wired to the canonical document store, the manifest-driven palette, and the composite catalogue source.

Coding Principles

  • group similar functionality in folders (analog to namespaces but without any namespace declaration)
  • one class per file;
  • one interface per file (unless interface is just used as a type);
  • group types as other interfaces in a types.ts file per folder;
  • group constants or enums in a constants.ts file per folder;
  • group decorators in a decorators.ts file per folder;
  • always import from the specific file, never from a folder or index file (exceptions for dependencies on other packages);
  • prefer the usage of established design patters where applicable:
    • Singleton (can be an anti-pattern. use with care);
    • factory;
    • observer;
    • strategy;
    • builder;
    • etc;

Release Documentation Hooks

Stay aligned with the automated release pipeline by reviewing Release Notes and Dependencies after trying these recipes (updated on 2025-11-26).

Related

decaf-ts ui-decorators styles decorator-validation db-decorators

Social

LinkedIn

Languages

TypeScript JavaScript NodeJS ShellScript

Getting help

If you have bug reports, questions or suggestions please create a new issue.

Contributing

I am grateful for any contributions made to this project. Please read this to get started.

Supporting

The first and easiest way you can support it is by Contributing. Even just finding a typo in the documentation is important.

Financial support is always welcome and helps keep both me and the project alive and healthy.

So if you can, if this project in any way. either by learning something or simply by helping you save precious time, please consider donating.

License

This project is licensed under the Mozilla Public License 2.0 (MPL-2.0). See ./LICENSE.md for a Fair Usage Addendum that explains when AGPL-3.0 applies (automated AI/Decaf MCP code generation and non-deterministic UI generation).

By developers, for developers...

About

No description, website, or topics provided.

Resources

Stars

1 star

Watchers

0 watching

Forks

Releases

Sponsor this project

Packages

Used by

Contributors

Languages

Generated from decaf-ts/ts-workspace