You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/developers/applications/index.md
+7-11Lines changed: 7 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -83,15 +83,14 @@ This guide is going to walk you through building a basic Harper application usin
83
83
84
84
[The getting started guide](/learn/) covers how to build an application entirely through schema configuration. However, if your application requires more custom functionality, you will probably want to employ your own JavaScript modules to implement more specific features and interactions. This gives you tremendous flexibility and control over how data is accessed and modified in Harper. Let's take a look at how we can use JavaScript to extend and define "resources" for custom functionality. In Harper, data is accessed through our [Resource API](../../reference/resources/), a standard interface to access data sources, tables, and make them available to endpoints. Database tables are `Resource` classes, and so extending the function of a table is as simple as extending their class.
85
85
86
-
To define custom (JavaScript) resources as endpoints, we need to create a `resources.js` module (this goes in the root of your application folder). And then endpoints can be defined with Resource classes that `export`ed. This can be done in addition to, or in lieu of the `@export`ed types in the schema.graphql. If you are exporting and extending a table you defined in the schema make sure you remove the `@export` from the schema so that don't export the original table or resource to the same endpoint/path you are exporting with a class. Resource classes have methods that correspond to standard HTTP/REST methods, like `get`, `post`, `patch`, and `put` to implement specific handling for any of these methods (for tables they all have default implementations). Let's add a property to the dog records when they are returned, that includes their age in human years. To do this, we get the `Dog` class from the defined tables, extend it (with our custom logic), and export it:
86
+
To define custom (JavaScript) resources as endpoints, we need to create a `resources.js` module (this goes in the root of your application folder). And then endpoints can be defined with Resource classes that `export`ed. This can be done in addition to, or in lieu of the `@export`ed types in the schema.graphql. If you are exporting and extending a table you defined in the schema make sure you remove the `@export` from the schema so that don't export the original table or resource to the same endpoint/path you are exporting with a class. Resource classes have `static`methods that correspond to standard HTTP/REST methods, like `get`, `post`, `patch`, and `put` to implement specific handling for any of these methods (for tables they all have default implementations). Let's add a property to the dog records when they are returned, that includes their age in human years. To do this, we get the `Dog` class from the defined tables, extend it (with our custom logic), and export it:
87
87
88
88
```javascript
89
89
// resources.js:
90
90
const { Dog } = tables; // get the Dog table from the Harper provided set of tables (in the default database)
91
91
92
92
exportclassDogWithHumanAgeextendsDog {
93
-
static loadAsInstance =false;
94
-
asyncget(target) {
93
+
asyncstaticget(target) {
95
94
constrecord=awaitsuper.get(target);
96
95
return {
97
96
...record, // include all properties from the record
@@ -126,8 +125,7 @@ The resource methods are automatically wrapped with a transaction and will autom
@@ -145,7 +143,7 @@ The call to `Breed.get` will return a record from the `Breed` table as specified
145
143
We may also want to customize access to this data. By default, the `target` has a `checkPermission` property that indicates that the table's `get` method will check if there is a valid user with access to a table before returning a record (and throw an `AccessViolation` if they do not). However, we can explicitly allow permission to the table's data/records by setting `checkPermission` to `false`:
146
144
147
145
```javascript
148
-
asyncget(target) {
146
+
staticasyncget(target) {
149
147
target.checkPermission=false;
150
148
constrecord=awaitsuper.get(target);
151
149
...
@@ -155,8 +153,7 @@ Here we have focused on customizing how we retrieve data, but we may also want t
155
153
156
154
```javascript
157
155
exportclassCustomDogextendsDog {
158
-
static loadAsInstance =false;
159
-
asyncpost(target, data) {
156
+
staticasyncpost(target, data) {
160
157
if (data.action==='add-trick') {
161
158
constrecord=this.update(target);
162
159
record.tricks.push(data.trick); // will be persisted when the transaction commits
@@ -171,8 +168,7 @@ We can also define custom authorization capabilities here. For example, we might
171
168
172
169
```javascript
173
170
exportclassCustomDogextendsDog {
174
-
static loadAsInstance =false;
175
-
asyncpost(target, data) {
171
+
staticasyncpost(target, data) {
176
172
if (data.action==='add-trick') {
177
173
constcontext=this.getContext();
178
174
// if we want to skip the default permission checks, we can turn off checkPermissions:
@@ -208,7 +204,7 @@ We can also directly implement the `Resource` class and use it to create new dat
0 commit comments