@antelopejs/interface-data-api 0.1.6 → 0.1.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/docs/1.introduction.md +128 -0
- package/docs/10.joined.md +146 -0
- package/docs/11.computed.md +152 -0
- package/docs/2.data-controllers.md +120 -0
- package/docs/3.routes.md +320 -0
- package/docs/4.access-rights.md +148 -0
- package/docs/5.validators.md +204 -0
- package/docs/6.listable.md +257 -0
- package/docs/7.foreign-keys.md +285 -0
- package/docs/8.filters.md +175 -0
- package/docs/9.modifiers.md +137 -0
- package/package.json +8 -3
- package/skills/data-api-interface/SKILL.md +91 -0
|
@@ -0,0 +1,137 @@
|
|
|
1
|
+
# Modifiers
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
Modifiers from `@antelopejs/interface-database-decorators` work automatically with the Data API. Modifiers such as `@Hashed` or `@Encrypted` transform data transparently during read and write operations without any additional configuration in the data controller.
|
|
6
|
+
|
|
7
|
+
Some modifiers require a runtime parameter (for example, a locale key for localization). The `@ModifierKey` decorator bridges this gap by mapping a controller field to a modifier's runtime key.
|
|
8
|
+
|
|
9
|
+
## The `@ModifierKey` Decorator
|
|
10
|
+
|
|
11
|
+
Use `@ModifierKey` when a modifier needs a runtime value that varies per request. The decorator associates a controller field with a specific modifier class. The field's value at request time is passed to the modifier during lock and unlock operations.
|
|
12
|
+
|
|
13
|
+
```typescript
|
|
14
|
+
import { ModifierKey } from "@antelopejs/interface-data-api/metadata";
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
### Signature
|
|
18
|
+
|
|
19
|
+
```typescript
|
|
20
|
+
@ModifierKey(modifierClass: typeof ContainerModifier<any>)
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
| Parameter | Description |
|
|
24
|
+
| --------- | ----------- |
|
|
25
|
+
| `modifierClass` | The modifier class that requires a runtime key (e.g., `LocalizationModifier`) |
|
|
26
|
+
|
|
27
|
+
### Example: Localized Content
|
|
28
|
+
|
|
29
|
+
The `LocalizationModifier` requires a locale identifier to determine which translation to store or retrieve. Use `@ModifierKey` to supply this value from an HTTP header.
|
|
30
|
+
|
|
31
|
+
```typescript
|
|
32
|
+
import { Controller, Parameter } from "@antelopejs/interface-api";
|
|
33
|
+
import {
|
|
34
|
+
DataController,
|
|
35
|
+
DefaultRoutes,
|
|
36
|
+
RegisterDataController,
|
|
37
|
+
} from "@antelopejs/interface-data-api";
|
|
38
|
+
import {
|
|
39
|
+
Access,
|
|
40
|
+
AccessMode,
|
|
41
|
+
Listable,
|
|
42
|
+
ModelReference,
|
|
43
|
+
ModifierKey,
|
|
44
|
+
} from "@antelopejs/interface-data-api/metadata";
|
|
45
|
+
import {
|
|
46
|
+
BasicDataModel,
|
|
47
|
+
Field,
|
|
48
|
+
Index,
|
|
49
|
+
Localized,
|
|
50
|
+
LocalizationModifier,
|
|
51
|
+
Model,
|
|
52
|
+
RegisterTable,
|
|
53
|
+
Table,
|
|
54
|
+
} from "@antelopejs/interface-database-decorators";
|
|
55
|
+
|
|
56
|
+
@RegisterTable("content")
|
|
57
|
+
class Content extends Table.with(LocalizationModifier) {
|
|
58
|
+
@Index({ primary: true })
|
|
59
|
+
@Field("string")
|
|
60
|
+
declare _id: string;
|
|
61
|
+
|
|
62
|
+
@Localized()
|
|
63
|
+
@Field("string")
|
|
64
|
+
declare title: string;
|
|
65
|
+
|
|
66
|
+
@Localized()
|
|
67
|
+
@Field("string")
|
|
68
|
+
declare description: string;
|
|
69
|
+
}
|
|
70
|
+
|
|
71
|
+
class ContentModel extends BasicDataModel(Content, "content") {}
|
|
72
|
+
|
|
73
|
+
@RegisterDataController()
|
|
74
|
+
class ContentAPI extends DataController(
|
|
75
|
+
Content,
|
|
76
|
+
DefaultRoutes.All,
|
|
77
|
+
Controller("/content"),
|
|
78
|
+
) {
|
|
79
|
+
@ModelReference()
|
|
80
|
+
@Model(ContentModel, "my-database")
|
|
81
|
+
declare contentModel: ContentModel;
|
|
82
|
+
|
|
83
|
+
@Parameter("x-content-language", "header")
|
|
84
|
+
@ModifierKey(LocalizationModifier)
|
|
85
|
+
declare language: string;
|
|
86
|
+
|
|
87
|
+
@Listable()
|
|
88
|
+
@Access(AccessMode.ReadWrite)
|
|
89
|
+
declare title: string;
|
|
90
|
+
|
|
91
|
+
@Listable()
|
|
92
|
+
@Access(AccessMode.ReadWrite)
|
|
93
|
+
declare description: string;
|
|
94
|
+
}
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
### How It Works
|
|
98
|
+
|
|
99
|
+
1. The HTTP request includes the header `x-content-language: fr`.
|
|
100
|
+
2. The `language` property receives the value `"fr"`.
|
|
101
|
+
3. During write operations, the modifier uses `"fr"` as the key to store the localized value.
|
|
102
|
+
4. During read operations, the modifier uses `"fr"` to retrieve the correct localized value.
|
|
103
|
+
|
|
104
|
+
**Example request:**
|
|
105
|
+
|
|
106
|
+
```http
|
|
107
|
+
POST /content/new
|
|
108
|
+
x-content-language: fr
|
|
109
|
+
Content-Type: application/json
|
|
110
|
+
|
|
111
|
+
{
|
|
112
|
+
"title": "Titre en francais",
|
|
113
|
+
"description": "Description en francais"
|
|
114
|
+
}
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
The data is stored under the `"fr"` locale key. A subsequent request with `x-content-language: en` accesses different localized values for the same record.
|
|
118
|
+
|
|
119
|
+
> **Note:** Most modifiers (such as `@Hashed` and `@Encrypted`) do not require `@ModifierKey`. Only modifiers that need a runtime parameter per request require this decorator.
|
|
120
|
+
|
|
121
|
+
## Integration with Other Features
|
|
122
|
+
|
|
123
|
+
### Foreign Keys
|
|
124
|
+
|
|
125
|
+
Modifiers work automatically with foreign key relationships. When the Data API resolves foreign records, modifier-protected fields on those records are properly unlocked during retrieval. See the [foreign keys documentation](./7.foreign-keys.md) for details.
|
|
126
|
+
|
|
127
|
+
### Filters
|
|
128
|
+
|
|
129
|
+
When filtering modifier-protected fields, custom filter functions receive the unlocked (transformed) value through the `proxy` parameter. This ensures filters operate on the correct data. See the [filters documentation](./8.filters.md) for details.
|
|
130
|
+
|
|
131
|
+
## Learn More
|
|
132
|
+
|
|
133
|
+
For the full list of available modifiers and instructions on creating custom ones, see the [@antelopejs/interface-database-decorators documentation](https://github.com/AntelopeJS/interface-database-decorators).
|
|
134
|
+
|
|
135
|
+
## Next Steps
|
|
136
|
+
|
|
137
|
+
See the [joined fields documentation](./10.joined.md) to learn how to flatten a remote field onto rows for native sorting and filtering.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@antelopejs/interface-data-api",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.7",
|
|
4
4
|
"description": "AntelopeJS interface for data API with CRUD controllers and route generation",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"antelopejs",
|
|
@@ -17,7 +17,9 @@
|
|
|
17
17
|
"main": "dist/index.js",
|
|
18
18
|
"types": "dist/index.d.ts",
|
|
19
19
|
"files": [
|
|
20
|
-
"dist"
|
|
20
|
+
"dist",
|
|
21
|
+
"docs",
|
|
22
|
+
"skills"
|
|
21
23
|
],
|
|
22
24
|
"exports": {
|
|
23
25
|
".": {
|
|
@@ -79,6 +81,9 @@
|
|
|
79
81
|
},
|
|
80
82
|
"antelopeJs": {
|
|
81
83
|
"standalone": true,
|
|
82
|
-
"test": "src/antelope.test.ts"
|
|
84
|
+
"test": "src/antelope.test.ts",
|
|
85
|
+
"skills": [
|
|
86
|
+
"./skills"
|
|
87
|
+
]
|
|
83
88
|
}
|
|
84
89
|
}
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: data-api-interface
|
|
3
|
+
description: AntelopeJS interface that generates CRUD REST endpoints from a database table via a DataController class and field decorators (Access, Listable, Mandatory, Sortable, Filter, Foreign, Joined, Computed, Validator). Use when importing @antelopejs/interface-data-api or @antelopejs/interface-data-api/metadata, when building a data controller / data API over an interface-database table, or when working with DataController, DefaultRoutes, RegisterDataController, ModelReference, or filter_/sortKey/sortDirection list query parameters.
|
|
4
|
+
category: antelopejs-interface
|
|
5
|
+
tags: [antelopejs, data-api, crud, rest, decorators]
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Data API Interface
|
|
9
|
+
|
|
10
|
+
Declarative CRUD layer on top of `@antelopejs/interface-api` (HTTP) and
|
|
11
|
+
`@antelopejs/interface-database(-decorators)` (storage). You build a controller class with
|
|
12
|
+
`DataController(tableClass, routes, Controller("/path"))`, decorate fields to expose them, and get
|
|
13
|
+
`get/list/new/edit/delete` routes generated. Everything here is consumer-side: there is no proxy
|
|
14
|
+
point of its own to implement — the underlying api/database interfaces do the actual crossings, so
|
|
15
|
+
your module must also import those peer interfaces.
|
|
16
|
+
|
|
17
|
+
## Imports
|
|
18
|
+
|
|
19
|
+
```typescript
|
|
20
|
+
import { DataController, DefaultRoutes, RegisterDataController, GetDataControllerMeta } from "@antelopejs/interface-data-api";
|
|
21
|
+
import { Access, AccessMode, Listable, Mandatory, Optional, Sortable, Filter, Foreign, Joined, Computed, Validator, ModelReference, ModifierKey } from "@antelopejs/interface-data-api/metadata";
|
|
22
|
+
import { Parameters, Query, Validation } from "@antelopejs/interface-data-api/components";
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
`/components` is only needed for custom route callbacks (query building, validation helpers).
|
|
26
|
+
|
|
27
|
+
## Minimal consumption example
|
|
28
|
+
|
|
29
|
+
```typescript
|
|
30
|
+
import { Controller } from "@antelopejs/interface-api";
|
|
31
|
+
import { DataController, DefaultRoutes, RegisterDataController } from "@antelopejs/interface-data-api";
|
|
32
|
+
import { Access, AccessMode, Listable, Mandatory, ModelReference, Sortable } from "@antelopejs/interface-data-api/metadata";
|
|
33
|
+
import { BasicDataModel, Field, Model, RegisterTable, Table } from "@antelopejs/interface-database-decorators";
|
|
34
|
+
|
|
35
|
+
@RegisterTable("tasks", "default")
|
|
36
|
+
class Task extends Table {
|
|
37
|
+
declare _id: string;
|
|
38
|
+
|
|
39
|
+
@Field("string")
|
|
40
|
+
declare summary: string;
|
|
41
|
+
}
|
|
42
|
+
|
|
43
|
+
class TaskModel extends BasicDataModel(Task, "tasks") {}
|
|
44
|
+
|
|
45
|
+
@RegisterDataController()
|
|
46
|
+
class TaskAPI extends DataController(Task, DefaultRoutes.All, Controller("/tasks")) {
|
|
47
|
+
@ModelReference()
|
|
48
|
+
@Model(TaskModel, "my-database")
|
|
49
|
+
declare taskModel: TaskModel;
|
|
50
|
+
|
|
51
|
+
@Listable()
|
|
52
|
+
@Access(AccessMode.ReadOnly)
|
|
53
|
+
declare _id: string;
|
|
54
|
+
|
|
55
|
+
@Listable()
|
|
56
|
+
@Sortable()
|
|
57
|
+
@Mandatory("new")
|
|
58
|
+
@Access(AccessMode.ReadWrite)
|
|
59
|
+
declare summary: string;
|
|
60
|
+
}
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
This exposes `GET /tasks/get?id=`, `GET /tasks/list`, `POST /tasks/new`, `PUT /tasks/edit?id=`,
|
|
64
|
+
`DELETE /tasks/delete?id=` (repeat `id` to delete several).
|
|
65
|
+
|
|
66
|
+
## Gotchas
|
|
67
|
+
|
|
68
|
+
- `@RegisterDataController()` is mandatory: it wires field decorators, parameter providers, and
|
|
69
|
+
routes. A `@ModelReference()` property holding a `@Model` instance is required too (`Query.GetModel`
|
|
70
|
+
throws 500 without it).
|
|
71
|
+
- Fields with no decorator are invisible to the API — neither returned nor writable; visibility
|
|
72
|
+
requires `@Access`. `@Optional()` only registers a field as not-mandatory (it does not expose it).
|
|
73
|
+
- `list` responds `{ results, total, offset, limit }`. `limit` defaults to 10 and is capped at 100
|
|
74
|
+
(`maxPage`). Sorting uses `sortKey`/`sortDirection` query params and requires `@Sortable` on the
|
|
75
|
+
field (400 otherwise). List responses only include `@Listable` fields unless `noPluck` is set.
|
|
76
|
+
- Filters come from `filter_<name>=<mode>:<value>` query params (plain value means `eq`); modes are
|
|
77
|
+
`eq|ne|gt|ge|lt|le` (the default filter compares the raw query-string value — pass a custom filter
|
|
78
|
+
function to cast for numeric ranges). Only fields declared with `@Filter()` are filterable.
|
|
79
|
+
- `@Joined` and `@Computed` fields are materialized in-database, so `@Sortable` and `@Filter()` work
|
|
80
|
+
efficiently on them — but those decorators must still be applied explicitly. Such fields are
|
|
81
|
+
forced read-only and to non-indexed sorting.
|
|
82
|
+
- Route selection: pass a subset like `{ get: DefaultRoutes.Get, list: DefaultRoutes.List }` instead
|
|
83
|
+
of `DefaultRoutes.All`; use `DefaultRoutes.WithOptions(route, options, endpoint)` to rename an
|
|
84
|
+
endpoint or preset parameter options.
|
|
85
|
+
- `@Access` accepts per-action overrides, e.g. `@Access(AccessMode.ReadOnly, { edit: AccessMode.ReadWrite })`.
|
|
86
|
+
|
|
87
|
+
## Deeper reference
|
|
88
|
+
|
|
89
|
+
See this package's `docs/` chapters — Introduction, Data Controllers, Routes, Access Rights,
|
|
90
|
+
Validators, Listable Fields, Foreign Keys, Filters, Modifiers, Joined Fields, Computed Fields — and
|
|
91
|
+
the shipped `.d.ts` files for exact signatures. Do not duplicate them here.
|