@powerhousedao/academy 2.5.0-dev.24 → 2.5.0-dev.26
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/CHANGELOG.md +18 -0
- package/docs/academy/01-GetStarted/00-ExploreDemoPackage.md +4 -8
- package/docs/academy/01-GetStarted/01-CreateNewPowerhouseProject.md +3 -1
- package/docs/academy/01-GetStarted/02-DefineToDoListDocumentModel.md +1 -1
- package/docs/academy/01-GetStarted/03-ImplementOperationReducers.md +4 -4
- package/docs/academy/01-GetStarted/04-BuildToDoListEditor.md +5 -9
- package/docs/academy/01-GetStarted/home.mdx +1 -9
- package/docs/academy/01-GetStarted/styles.module.css +31 -0
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/02-StandardDocumentModelWorkflow.md +7 -3
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/03-BuilderTools.md +1 -1
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/01-WhatIsADocumentModel.md +26 -18
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/02-SpecifyTheStateSchema.md +70 -2
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/03-SpecifyDocumentOperations.md +59 -4
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/04-UseTheDocumentModelGenerator.md +32 -12
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/05-ImplementDocumentReducers.md +103 -38
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/06-ImplementDocumentModelTests.md +85 -228
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/07-ExampleToDoListRepository.md +41 -1
- package/docs/academy/02-MasteryTrack/05-Launch/03-SetupEnvironment.md +5 -2
- package/docs/academy/05-Architecture/00-PowerhouseArchitecture.md +3 -0
- package/docs/academy/05-Architecture/images/PowerhouseArchitecture.png +0 -0
- package/docs/academy/06-ComponentLibrary/00-DocumentEngineering.md +27 -16
- package/docs/academy/06-ComponentLibrary/02-CreateCustomScalars.md +8 -7
- package/docs/academy/07-Cookbook.md +209 -0
- package/docs/academy/08-Glossary.md +19 -20
- package/docs/academy/09-AIResources +131 -0
- package/package.json +1 -1
- package/sidebars.ts +0 -2
- package/docs/academy/06-ComponentLibrary/04-ScalarVsUIComponents.md +0 -52
- package/docs/academy/09-AIResources.md +0 -9
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,21 @@
|
|
|
1
|
+
## 2.5.0-dev.26 (2025-06-16)
|
|
2
|
+
|
|
3
|
+
This was a version bump only for @powerhousedao/academy to align it with other projects, there were no code changes.
|
|
4
|
+
|
|
5
|
+
## 2.5.0-dev.25 (2025-06-13)
|
|
6
|
+
|
|
7
|
+
### 🚀 Features
|
|
8
|
+
|
|
9
|
+
- start dependent services with switchboard ([188c82c6a](https://github.com/powerhouse-inc/powerhouse/commit/188c82c6a))
|
|
10
|
+
|
|
11
|
+
### 🩹 Fixes
|
|
12
|
+
|
|
13
|
+
- **docker:** request write permissions ([29d4d3fd7](https://github.com/powerhouse-inc/powerhouse/commit/29d4d3fd7))
|
|
14
|
+
|
|
15
|
+
### ❤️ Thank You
|
|
16
|
+
|
|
17
|
+
- Frank
|
|
18
|
+
|
|
1
19
|
## 2.5.0-dev.24 (2025-06-13)
|
|
2
20
|
|
|
3
21
|
### 🚀 Features
|
|
@@ -18,7 +18,8 @@ Install the Powerhouse command-line tool `ph-cmd` and then use it to install a p
|
|
|
18
18
|
|
|
19
19
|
## Step 1: Install the Powerhouse CLI
|
|
20
20
|
|
|
21
|
-
You will use the Powerhouse CLI to launch a local environment with a "**
|
|
21
|
+
You will use the Powerhouse CLI to launch a local environment with a "**ToDoList Demo Package**".
|
|
22
|
+
This is also the package that you'll recreate during the tutorials and get's you familiar with Powerhouse.
|
|
22
23
|
|
|
23
24
|
```bash
|
|
24
25
|
pnpm install -g ph-cmd
|
|
@@ -36,18 +37,13 @@ Now, use the `ph` command to install the demo package into a global project.
|
|
|
36
37
|
|
|
37
38
|
```bash
|
|
38
39
|
# Install the package
|
|
39
|
-
ph install @powerhousedao/
|
|
40
|
+
ph install @powerhousedao/todo-demo-package.
|
|
40
41
|
```
|
|
41
42
|
|
|
42
|
-
This command downloads and sets up the
|
|
43
|
+
This command downloads and sets up the todo-demo-package, making its features available in your Powerhouse environment.
|
|
43
44
|
|
|
44
45
|
You have now successfully installed `ph-cmd` and added your first package!
|
|
45
46
|
|
|
46
|
-
:::info
|
|
47
|
-
Let's explore what exactly you can do with this package.
|
|
48
|
-
At the bottom of the Connect Application you'll find a button with 'invoice'. This allows you to open an invoice document. The invoice document helps contributors to get paid for their work through crypto, stablecoins or a number of other currencies. Contributors can change the state of their invoice from draft to issued, while processors or clients can follow up on the payment of these invoices. In the next steps you can explore this for yourself.
|
|
49
|
-
:::
|
|
50
|
-
|
|
51
47
|
## Step 3: Run the Connect App in Studio mode
|
|
52
48
|
To run the package locally in Connect Studio (our collaboration and contributor app), run the `ph connect` command.
|
|
53
49
|
|
|
@@ -82,7 +82,9 @@ In the terminal, you will be asked to enter the project name. Fill in the projec
|
|
|
82
82
|
|
|
83
83
|
A new browser window will open and you will see the Connect application. If it doesn't open automatically, you can open it manually by navigating to `http://localhost:3000/` in your browser.
|
|
84
84
|
|
|
85
|
-
You will see your local drive and a button to create a new drive.
|
|
85
|
+
You will see your local drive and a button to create a new drive.
|
|
86
|
+
If you local drive is not present navigate into Settings in the bottom left corner. Settings > Danger Zone > Clear Storage.
|
|
87
|
+
Clear the storage of your localhost application as it might has an old session cached.
|
|
86
88
|
|
|
87
89
|
:::tip
|
|
88
90
|
A **drive** is a folder to store and organize your documents in. Powerhouse offers the ability to build customized 'Drive Apps' for your documents. Think of a Drive App as a specialized lens—it offers **different ways to visualize, organize, and interact with** the data stored within a drive, making it more intuitive and efficient for specific use cases. To learn more, visit [Building A Drive App](/academy/MasteryTrack/BuildingUserExperiences/BuildingADriveExplorer)
|
|
@@ -79,7 +79,7 @@ To be able to define the document model, you need to open the document model edi
|
|
|
79
79
|
### The steps below show you how to do this:
|
|
80
80
|
|
|
81
81
|
1. In the Connect application, click on **'document model'** to open the document model specification editor.
|
|
82
|
-
2. Name your document model 'ToDoList' in the Connect application, paying close attention to capitalization.
|
|
82
|
+
2. Name your document model '**ToDoList**' in the Connect application, paying close attention to capitalization.
|
|
83
83
|
3. You'll be presented with a form to fill in metadata about the document model. Fill in the details in the respective fields.
|
|
84
84
|
|
|
85
85
|
In the **Document Type** field, type `powerhouse/todolist`. This defines the new type of document that will be created with this document model specification.
|
|
@@ -111,10 +111,10 @@ Here are the tests for the three operations implemented in the reducers file. Th
|
|
|
111
111
|
<details>
|
|
112
112
|
<summary>Operation Reducers Tests</summary>
|
|
113
113
|
```typescript
|
|
114
|
-
import utils from '../../gen/utils';
|
|
115
|
-
import { reducer } from '../../gen/reducer';
|
|
116
|
-
import * as creators from '../../gen/creators';
|
|
117
|
-
import { ToDoListDocument } from '../../gen/types';
|
|
114
|
+
import utils from '../../gen/utils.js';
|
|
115
|
+
import { reducer } from '../../gen/reducer.js';
|
|
116
|
+
import * as creators from '../../gen/creators.js';
|
|
117
|
+
import { ToDoListDocument } from '../../gen/types.js';
|
|
118
118
|
|
|
119
119
|
// REMARKS:
|
|
120
120
|
// These tests demonstrate the event sourcing principles of our document model.
|
|
@@ -29,7 +29,7 @@ Manual build steps are typically only needed when publishing packages.
|
|
|
29
29
|
|
|
30
30
|
## ToDoList Editor
|
|
31
31
|
|
|
32
|
-
Below is the complete code for the To-Do List editor.
|
|
32
|
+
Below is the complete code for the To-Do List editor. Paste this code in `editors/to-do-list/editor.tsx`.
|
|
33
33
|
|
|
34
34
|
<details>
|
|
35
35
|
<summary>Complete ToDoList Editor Example (using Tailwind CSS)</summary>
|
|
@@ -43,7 +43,7 @@ import {
|
|
|
43
43
|
ToDoItem,
|
|
44
44
|
actions,
|
|
45
45
|
ToDoListDocument,
|
|
46
|
-
} from '../../document-models/to-do-list';
|
|
46
|
+
} from '../../document-models/to-do-list/index.js';
|
|
47
47
|
import { useState } from 'react';
|
|
48
48
|
|
|
49
49
|
// EditorProps is a generic type that provides the document and a dispatch function.
|
|
@@ -207,16 +207,12 @@ The editor will update dynamically, so you can play around with your editor styl
|
|
|
207
207
|
Congratulations!
|
|
208
208
|
If you managed to follow this tutorial until this point, you have successfully implemented the **ToDoList** document model with its reducer operations and editor.
|
|
209
209
|
|
|
210
|
-
### Up Next: Drive Explorers & Drive Apps
|
|
211
|
-
|
|
212
|
-
Now you can move on to creating a [custom drive explorer](/academy/MasteryTrack/BuildingUserExperiences/BuildingADriveExplorer) for your ToDoList document.
|
|
213
|
-
Imagine you have many ToDoLists sitting in a drive. A custom drive explorer will allow you to organize and track them at a glance, opening up a new world of possibilities to increase the functionality of your documents!
|
|
214
|
-
|
|
215
|
-
|
|
216
210
|
### Up Next: Mastery Track
|
|
217
211
|
|
|
218
|
-
In the [Mastery Track chapther: Document Model Creation](/academy/MasteryTrack/DocumentModelCreation/WhatIsADocumentModel) we guide you through the theoretics of the previous steps while created a more advanced ToDoList.
|
|
212
|
+
In the [Mastery Track chapther: Document Model Creation](/academy/MasteryTrack/DocumentModelCreation/WhatIsADocumentModel) we guide you through the theoretics of the previous steps while created a more advanced version of the ToDoList.
|
|
213
|
+
|
|
219
214
|
You will learn:
|
|
220
215
|
- The in's & out's of a document model.
|
|
221
216
|
- How to use UI & Scalar components from the Document Engineering system.
|
|
217
|
+
- How to build Custom Drive Apps or Drive Explorers.
|
|
222
218
|
|
|
@@ -85,15 +85,7 @@ import BrowserOnly from '@docusaurus/BrowserOnly';
|
|
|
85
85
|
position: 'relative'
|
|
86
86
|
}}>
|
|
87
87
|
<img src="/img/Union.svg" alt="Powerhouse Union" width="250" />
|
|
88
|
-
<div
|
|
89
|
-
position: 'absolute',
|
|
90
|
-
top: '18px',
|
|
91
|
-
backgroundColor: 'white',
|
|
92
|
-
padding: '8px 16px',
|
|
93
|
-
borderRadius: '8px',
|
|
94
|
-
textAlign: 'center',
|
|
95
|
-
zIndex: 2,
|
|
96
|
-
}}>
|
|
88
|
+
<div className={styles.masteryTrackTitle}>
|
|
97
89
|
<h3 className="card-title" style={{ margin: 0 }}>Mastery Track</h3>
|
|
98
90
|
</div>
|
|
99
91
|
</div>
|
|
@@ -96,4 +96,35 @@
|
|
|
96
96
|
:global(.path-button:hover) {
|
|
97
97
|
background: #ffffff;
|
|
98
98
|
border-color: #d1d5db;
|
|
99
|
+
}
|
|
100
|
+
|
|
101
|
+
.masteryTrackTitle {
|
|
102
|
+
background-color: white;
|
|
103
|
+
padding: 8px 16px;
|
|
104
|
+
border-radius: 8px;
|
|
105
|
+
text-align: center;
|
|
106
|
+
z-index: 2;
|
|
107
|
+
position: absolute;
|
|
108
|
+
top: 18px;
|
|
109
|
+
}
|
|
110
|
+
|
|
111
|
+
:global([data-theme='dark']) .masteryTrackTitle {
|
|
112
|
+
background-color: var(--ifm-card-background-color);
|
|
113
|
+
border: 1px solid var(--ifm-color-emphasis-200);
|
|
114
|
+
}
|
|
115
|
+
|
|
116
|
+
:global([data-theme='dark']) .pathCard {
|
|
117
|
+
background: var(--ifm-card-background-color);
|
|
118
|
+
border: 1px solid var(--ifm-color-emphasis-200);
|
|
119
|
+
}
|
|
120
|
+
|
|
121
|
+
:global([data-theme='dark']) :global(.path-button) {
|
|
122
|
+
background: var(--ifm-color-emphasis-100);
|
|
123
|
+
border-color: var(--ifm-color-emphasis-200);
|
|
124
|
+
color: var(--ifm-font-color-primary);
|
|
125
|
+
}
|
|
126
|
+
|
|
127
|
+
:global([data-theme='dark']) :global(.path-button:hover) {
|
|
128
|
+
background: var(--ifm-color-emphasis-200);
|
|
129
|
+
border-color: var(--ifm-color-emphasis-300);
|
|
99
130
|
}
|
package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/02-StandardDocumentModelWorkflow.md
CHANGED
|
@@ -1,9 +1,13 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Create Powerhouse packages
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
:::warning
|
|
4
|
+
**This tutorial is a summary for builders that are familiar with building document models**.
|
|
5
|
+
It guides you through creating a Powerhouse Document Model, from initial setup to publishing a distributable package.
|
|
6
|
+
Please start with the '**Get Started**' Chapter or '**Document Model Creation**' section if you are unfamiliar with building a document model.
|
|
7
|
+
:::
|
|
4
8
|
|
|
5
9
|
<details>
|
|
6
|
-
<summary>Key Commands</summary>
|
|
10
|
+
<summary>Key Commands that you'll use in this flow</summary>
|
|
7
11
|
|
|
8
12
|
- `pnpm install -g ph-cmd`: Installs the Powerhouse CLI globally.
|
|
9
13
|
- `ph init`: Initializes a new Powerhouse project or sets up the local environment.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Powerhouse Builder Tooling
|
|
2
2
|
|
|
3
|
-
This page provides an overview of all the builder tooling offered by the Powerhouse ecosystem.
|
|
3
|
+
This page provides an overview of all the builder tooling offered by the Powerhouse ecosystem.
|
|
4
4
|
This list will be maintained and updated as our toolkit grows.
|
|
5
5
|
|
|
6
6
|
## Powerhouse Command Line Interface
|
|
@@ -2,10 +2,16 @@
|
|
|
2
2
|
|
|
3
3
|
:::tip
|
|
4
4
|
This chapter on **Document Model Creation** will help you with an in depth practicial understanding while building an **advanced ToDoList** document model.
|
|
5
|
-
|
|
5
|
+
Although not required, if you have completed the 'Get Started' tutorial you will revisit familiar topics and can update your existing document model.
|
|
6
6
|
:::
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
:::info **Definition: What is a Document Model?**
|
|
9
|
+
A Document Model is a programmable document structure that defines how data is stored, changed, and interpreted in a decentralized system. It acts like a living blueprint—capturing state, tracking changes, and enabling interaction through defined operations.
|
|
10
|
+
|
|
11
|
+
For instance, an invoice document model might define fields like *issuer*, *lineItems*, and *status*, with operations such as *AddLineItem* and *MarkAsPaid*.
|
|
12
|
+
:::
|
|
13
|
+
|
|
14
|
+
A Document Model can be understood as:
|
|
9
15
|
- A structured software framework that represents and **manages business logic** within a digital environment.
|
|
10
16
|
- A sophisticated template that **encapsulates the essential aspects of a digital process or a set of data**.
|
|
11
17
|
- A blueprints that define how data is **captured, manipulated, and visualised** within a system.
|
|
@@ -37,19 +43,19 @@ Example of a **GraphQL-like state schema** for an invoice document:
|
|
|
37
43
|
|
|
38
44
|
```graphql
|
|
39
45
|
type InvoiceState {
|
|
40
|
-
id: OID!
|
|
41
|
-
issuer: OID!
|
|
42
|
-
recipient: OID!
|
|
43
|
-
status: String
|
|
44
|
-
dueDate: DateTime
|
|
46
|
+
id: OID! # Unique identifier for the invoice
|
|
47
|
+
issuer: OID! # Reference to the issuing entity
|
|
48
|
+
recipient: OID! # Reference to the recipient entity
|
|
49
|
+
status: String # (value: "DRAFT") # Invoice status
|
|
50
|
+
dueDate: DateTime # Payment due date
|
|
45
51
|
lineItems: [LineItem!]! # List of line items
|
|
46
|
-
totalAmount: Currency
|
|
52
|
+
totalAmount: Currency # Computed field for total invoice value
|
|
47
53
|
}
|
|
48
54
|
|
|
49
55
|
type LineItem {
|
|
50
56
|
id: OID!
|
|
51
57
|
description: String
|
|
52
|
-
quantity: Int
|
|
58
|
+
quantity: Int
|
|
53
59
|
unitPrice: Currency
|
|
54
60
|
}
|
|
55
61
|
```
|
|
@@ -58,7 +64,6 @@ type LineItem {
|
|
|
58
64
|
|
|
59
65
|
- Uses **GraphQL-like definitions** for a **clear, structured schema**.
|
|
60
66
|
- Supports **custom scalar types** like `OID`, `Currency`, and `DateTime`. Or other Web3 specific scalars
|
|
61
|
-
- Allows **default values** using `@default(value: "DRAFT")`.
|
|
62
67
|
- Defines **relationships** using object references (`OID!`).
|
|
63
68
|
|
|
64
69
|
The state schema acts as a **template** for document instances. Every new invoice created will follow this structure.
|
|
@@ -75,7 +80,7 @@ Example operations for modifying an invoice:
|
|
|
75
80
|
input AddLineItemInput {
|
|
76
81
|
invoiceId: OID!
|
|
77
82
|
description: String
|
|
78
|
-
quantity: Int
|
|
83
|
+
quantity: Int
|
|
79
84
|
unitPrice: Currency
|
|
80
85
|
}
|
|
81
86
|
|
|
@@ -89,7 +94,8 @@ input MarkAsPaidInput {
|
|
|
89
94
|
}
|
|
90
95
|
```
|
|
91
96
|
|
|
92
|
-
Each operation **modifies the document state** without altering past data.
|
|
97
|
+
Each operation **modifies the document state** without altering past data.
|
|
98
|
+
Instead, a new event is appended to the document history.
|
|
93
99
|
|
|
94
100
|
---
|
|
95
101
|
|
|
@@ -184,14 +190,16 @@ This removes the need for **complex database joins** and allows for **fast, stru
|
|
|
184
190
|
|
|
185
191
|
Document Models offer a range of features that can be leveraged to create sophisticated, automated, and data-driven solutions:
|
|
186
192
|
|
|
187
|
-
- **
|
|
188
|
-
|
|
189
|
-
- **
|
|
190
|
-
|
|
191
|
-
- **Version Control**:
|
|
193
|
+
- **Automation**: Automate workflows using consistent, structured document logic.
|
|
194
|
+
- **Auditability**: Maintain a full history of changes for compliance and transparency.
|
|
195
|
+
- **API Integration**: Seamlessly connect with Switchboard or external APIs for data exchange.
|
|
196
|
+
- **Data Analysis**: Enable real-time and historical insights through structured read models.
|
|
197
|
+
- **Version Control**: Track and compare document states over time, similar to Git.
|
|
198
|
+
- **Collaboration**: Empower decentralized teams to build, modify, and share documents asynchronously.
|
|
199
|
+
- **Extensibility**: Add new fields, operations, and integrations over time without rewriting logic.
|
|
192
200
|
|
|
193
201
|
Document Models are a powerful primitive within the Powerhouse vision, offering a flexible, structured, and efficient way to manage business logic and data.
|
|
194
202
|
|
|
195
203
|
### Up Next: How to build a Document Model
|
|
196
204
|
|
|
197
|
-
In the next chapters, we'll teach you how to build a ToDoList document model while explaining all of the theory that is involved.
|
|
205
|
+
In the next chapters, we'll teach you how to build a ToDoList document model while explaining all of the theory that is involved.
|
|
@@ -31,6 +31,7 @@ You can modify types using lists and non-null indicators:
|
|
|
31
31
|
## Example: ToDoList State Schema
|
|
32
32
|
|
|
33
33
|
Let's revisit the `ToDoList` example from the "Define the ToDoList document specification" tutorial.
|
|
34
|
+
Only this time, we'll also add a 'Stats' type. Since we want to keep track of the number of completed To-Do's.
|
|
34
35
|
|
|
35
36
|
```graphql
|
|
36
37
|
# The state of our ToDoList
|
|
@@ -44,6 +45,12 @@ type ToDoItem {
|
|
|
44
45
|
text: String!
|
|
45
46
|
checked: Boolean!
|
|
46
47
|
}
|
|
48
|
+
# The statistics on our to-do's
|
|
49
|
+
type ToDoListStats {
|
|
50
|
+
total: Int!
|
|
51
|
+
checked: Int!
|
|
52
|
+
unchecked: Int!
|
|
53
|
+
}
|
|
47
54
|
```
|
|
48
55
|
|
|
49
56
|
### Breakdown:
|
|
@@ -59,6 +66,11 @@ type ToDoItem {
|
|
|
59
66
|
* `text: String!`: The textual description of the to-do item. It cannot be null, ensuring every to-do has a description.
|
|
60
67
|
* `checked: Boolean!`: Indicates whether the to-do item is completed. It defaults to a boolean value (true or false) and cannot be null.
|
|
61
68
|
|
|
69
|
+
* **`ToDoListStats` type**: This type holds the summary statistics for the to-do list.
|
|
70
|
+
* `total: Int!`: The total count of all to-do items. This field must be an integer and cannot be null.
|
|
71
|
+
* `checked: Int!`: The number of to-do items that are marked as completed. This must be an integer and cannot be null.
|
|
72
|
+
* `unchecked: Int!`: The number of to-do items that are still pending. This also must be an integer and cannot be null.
|
|
73
|
+
|
|
62
74
|
## Best Practices for Designing Your State Schema
|
|
63
75
|
|
|
64
76
|
1. **Start Simple, Iterate**: Begin with the core entities and properties. You can always expand and refine your schema as your understanding of the document's requirements grows.
|
|
@@ -73,5 +85,61 @@ type ToDoItem {
|
|
|
73
85
|
|
|
74
86
|
By carefully defining your state schema, you lay a solid foundation for your Powerhouse document model, making it robust, maintainable, and easy to work with. The schema dictates not only how data is stored but also how it can be queried and mutated through operations, which will be covered in the next section.
|
|
75
87
|
|
|
76
|
-
|
|
77
|
-
|
|
88
|
+
## Practical Implementation: Defining the State Schema in Connect
|
|
89
|
+
|
|
90
|
+
Now that you understand the concepts behind the state schema, let's put it into practice. This section will guide you through creating a document model specification for the advanced ToDoList example discussed above.
|
|
91
|
+
|
|
92
|
+
<details>
|
|
93
|
+
<summary>Tutorial: The State Schema Specification</summary>
|
|
94
|
+
|
|
95
|
+
### Prerequisites
|
|
96
|
+
|
|
97
|
+
- You have a Powerhouse project set up. If not, please follow the [Create a new Powerhouse Project](../../GetStarted/CreateNewPowerhouseProject) tutorial.
|
|
98
|
+
- Connect Studio is running. If not, navigate to your project directory in the terminal and run `ph connect`.
|
|
99
|
+
|
|
100
|
+
### Steps
|
|
101
|
+
|
|
102
|
+
1. **Create a New Document Model**:
|
|
103
|
+
- With Connect Studio open in your browser, navigate into your local drive.
|
|
104
|
+
- At the bottom of the page in the 'New Document' section, click the `DocumentModel` button to create a new document model specification.
|
|
105
|
+
|
|
106
|
+
2. **Define Document Metadata**:
|
|
107
|
+
- **Name**: Give your document model a descriptive name, for example, `ToDoList`. **Pay close attention to capitalization, as it influences our code.**
|
|
108
|
+
- **Document Type**: In the 'Document Type' field, enter a unique identifier for this document type, for instance, `powerhouse/todolist`.
|
|
109
|
+
|
|
110
|
+
3. **Specify the State Schema**:
|
|
111
|
+
- In the code editor provided, you'll see a template for a GraphQL schema.
|
|
112
|
+
- Replace the entire content of the editor with the advanced `ToDoList` schema we've designed in this chapter:
|
|
113
|
+
|
|
114
|
+
```graphql
|
|
115
|
+
# The state of our ToDoList
|
|
116
|
+
type ToDoListState {
|
|
117
|
+
items: [ToDoItem!]!
|
|
118
|
+
}
|
|
119
|
+
|
|
120
|
+
# A single to-do item
|
|
121
|
+
type ToDoItem {
|
|
122
|
+
id: ID!
|
|
123
|
+
text: String!
|
|
124
|
+
checked: Boolean!
|
|
125
|
+
}
|
|
126
|
+
# The statistics on our to-do's
|
|
127
|
+
type ToDoListStats {
|
|
128
|
+
total: Int!
|
|
129
|
+
checked: Int!
|
|
130
|
+
unchecked: Int!
|
|
131
|
+
}
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
4. **Sync Schema and View Initial State**:
|
|
135
|
+
- After pasting the schema, click the **'Sync with schema'** button.
|
|
136
|
+
- This action processes your schema and generates an initial JSON state for your document model based on the `ToDoListState` type. You can view this initial state, which helps you verify that your schema is structured correctly.
|
|
137
|
+
|
|
138
|
+
For now, you can ignore the "Modules & Operations" section. We will define and implement the operations that modify this state in the upcoming sections of this Mastery Track.
|
|
139
|
+
|
|
140
|
+
By completing these steps, you have successfully specified the data structure for the advanced ToDoList document model. The next step is to define the operations that will allow users to interact with and change this state.
|
|
141
|
+
|
|
142
|
+
</details>
|
|
143
|
+
|
|
144
|
+
For a complete, working example, you can always refer to the [Example ToDoList Repository](./07-ExampleToDoListRepository.md) which contains the full implementation of the concepts discussed in this Mastery Track.
|
|
145
|
+
|
package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/03-SpecifyDocumentOperations.md
CHANGED
|
@@ -16,10 +16,9 @@ Each operation acts as a command that, when applied, transitions the document fr
|
|
|
16
16
|
|
|
17
17
|
## Connecting Operations to the Schema
|
|
18
18
|
|
|
19
|
-
In the "Define ToDoList Document Model" guide, we used GraphQL `input` types to define the structure of the data required for each operation. Let's revisit that:
|
|
19
|
+
In the "Define ToDoList Document Model" chapter in the "Get Started" guide, we used GraphQL `input` types to define the structure of the data required for each operation. Let's revisit that:
|
|
20
20
|
|
|
21
21
|
```graphql
|
|
22
|
-
# From 02-DefineToDoListDocumentModel.md
|
|
23
22
|
# Defines a GraphQL input type for adding a new to-do item
|
|
24
23
|
input AddTodoItemInput {
|
|
25
24
|
id: ID!
|
|
@@ -96,7 +95,6 @@ The generated code from `ph generate` (as seen in `03-ImplementOperationReducers
|
|
|
96
95
|
For example, the `ToDoListToDoListOperations` type generated by Powerhouse will expect methods corresponding to `addTodoItemOperation`, `updateTodoItemOperation`, and `deleteTodoItemOperation`.
|
|
97
96
|
|
|
98
97
|
```typescript
|
|
99
|
-
// From 03-ImplementOperationReducers.md
|
|
100
98
|
import { ToDoListToDoListOperations } from '../../gen/to-do-list/operations.js';
|
|
101
99
|
|
|
102
100
|
export const reducer: ToDoListToDoListOperations = {
|
|
@@ -112,8 +110,65 @@ export const reducer: ToDoListToDoListOperations = {
|
|
|
112
110
|
};
|
|
113
111
|
```
|
|
114
112
|
|
|
113
|
+
## Practical Implementation: Defining Operations in Connect
|
|
114
|
+
|
|
115
|
+
Now that you understand the theory, let's walk through the practical steps of defining these operations for our `ToDoList` document model within the Powerhouse Connect application.
|
|
116
|
+
|
|
117
|
+
<details>
|
|
118
|
+
<summary>Tutorial: Specifying `ToDoList` Operations</summary>
|
|
119
|
+
|
|
120
|
+
Assuming you have already defined the state schema for the `ToDoList` as covered in the previous section, follow these steps to add the operations:
|
|
121
|
+
|
|
122
|
+
1. **Create a Module for Operations:**
|
|
123
|
+
Below the schema editor in Connect, find the input field labeled `Add module`. Modules help organize your operations.
|
|
124
|
+
* Type `to_do_list` into the field and press Enter.
|
|
125
|
+
|
|
126
|
+
2. **Add the `ADD_TODO_ITEM` Operation:**
|
|
127
|
+
A new field, `Add operation`, will appear under your new module.
|
|
128
|
+
* Type `ADD_TODO_ITEM` into this field and press Enter.
|
|
129
|
+
* An editor will appear for the operation's input type. You need to define the data required for this operation. Paste the following GraphQL `input` definition into the editor:
|
|
130
|
+
|
|
131
|
+
```graphql
|
|
132
|
+
# Defines a GraphQL input type for adding a new to-do item
|
|
133
|
+
input AddTodoItemInput {
|
|
134
|
+
id: ID!
|
|
135
|
+
text: String!
|
|
136
|
+
}
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
3. **Add the `UPDATE_TODO_ITEM` Operation:**
|
|
140
|
+
* In the `Add operation` field again, type `UPDATE_TODO_ITEM` and press Enter.
|
|
141
|
+
* Paste the corresponding `input` definition into its editor:
|
|
142
|
+
|
|
143
|
+
```graphql
|
|
144
|
+
# Defines a GraphQL input type for updating a to-do item
|
|
145
|
+
input UpdateTodoItemInput {
|
|
146
|
+
id: ID!
|
|
147
|
+
text: String
|
|
148
|
+
checked: Boolean
|
|
149
|
+
}
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
4. **Add the `DELETE_TODO_ITEM` Operation:**
|
|
153
|
+
* Finally, type `DELETE_TODO_ITEM` in the `Add operation` field and press Enter.
|
|
154
|
+
* Paste its `input` definition:
|
|
155
|
+
|
|
156
|
+
```graphql
|
|
157
|
+
# Defines a GraphQL input type for deleting a to-do item
|
|
158
|
+
input DeleteTodoItemInput {
|
|
159
|
+
id: ID!
|
|
160
|
+
}
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
5. **Review and Export:**
|
|
164
|
+
After adding all three operations, your document model specification in Connect is complete for now. You can see how each operation (`ADD_TODO_ITEM`, etc.) is now explicitly linked to an input type that defines its payload.
|
|
165
|
+
|
|
166
|
+
The next step in a real project would be to click the `Export` button to save this specification file. In the next chapter, we will see how this exported file is used to generate code for our reducers.
|
|
167
|
+
|
|
168
|
+
</details>
|
|
169
|
+
|
|
115
170
|
## Conclusion
|
|
116
171
|
|
|
117
|
-
Specifying document operations is a foundational step in building robust and predictable document models in Powerhouse. By clearly defining the "what" (the operation and its input) before implementing the "how" (the reducer logic)
|
|
172
|
+
Specifying document operations is a foundational step in building robust and predictable document models in Powerhouse. By clearly defining the **"what" (the operation and its input)** before implementing the **"how" (the reducer logic)**, you create a clear contract for state transitions. This approach enhances type safety, testability, and the overall maintainability of your document model.
|
|
118
173
|
|
|
119
174
|
In the next section, we will dive deeper into the implementation of the reducer functions for these specified operations.
|
package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/04-UseTheDocumentModelGenerator.md
CHANGED
|
@@ -90,22 +90,42 @@ Leveraging the `ph generate` command offers numerous advantages:
|
|
|
90
90
|
5. **Alignment with Powerhouse Ecosystem:** The generated code is designed to integrate seamlessly with other parts of the Powerhouse ecosystem, such as the reducer execution engine and UI components.
|
|
91
91
|
6. **Single Source of Truth:** Ensures that your codebase (especially types and action creators) stays synchronized with the document model specification defined in Connect. If the specification changes, regenerating the model will update these components accordingly.
|
|
92
92
|
|
|
93
|
-
##
|
|
93
|
+
## Practical Implementation: Generating the `ToDoList` Model
|
|
94
94
|
|
|
95
|
-
|
|
95
|
+
Now that you understand what the Document Model Generator does, let's walk through the practical steps of using it with our `ToDoList` example.
|
|
96
96
|
|
|
97
|
-
|
|
98
|
-
|
|
97
|
+
<details>
|
|
98
|
+
<summary>Tutorial: Generating the `ToDoList` Document Model</summary>
|
|
99
|
+
|
|
100
|
+
This tutorial assumes you have completed the previous steps in this Mastery Track, where you defined the state schema and operations for the `ToDoList` model in Connect and exported it.
|
|
101
|
+
|
|
102
|
+
### Prerequisites
|
|
103
|
+
|
|
104
|
+
* **`ToDoList.phdm.zip` file**: You must have the document model specification file exported from Connect. If you do not have this file, please revisit the previous sections on specifying the state schema and operations.
|
|
105
|
+
|
|
106
|
+
### Steps
|
|
107
|
+
|
|
108
|
+
1. **Place the Specification File in Your Project**:
|
|
109
|
+
* Navigate to the root directory of your Powerhouse project.
|
|
110
|
+
* Move or copy your `ToDoList.phdm.zip` file into this directory.
|
|
111
|
+
|
|
112
|
+
2. **Run the Generator Command**:
|
|
113
|
+
* Open your terminal in the root directory of your Powerhouse project.
|
|
114
|
+
* Execute the `ph generate` command, pointing to your specification file:
|
|
99
115
|
```bash
|
|
100
|
-
ph generate
|
|
116
|
+
ph generate ToDoList.phdm.zip
|
|
101
117
|
```
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
* `
|
|
105
|
-
*
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
118
|
+
|
|
119
|
+
3. **Explore the Generated Files**:
|
|
120
|
+
* After the command completes successfully, you will find a new directory: `document-models/to-do-list/`.
|
|
121
|
+
* Take a moment to explore its contents, which will match the structure described earlier in this document:
|
|
122
|
+
* `spec.json` and `schema.graphql`: The definition of your model.
|
|
123
|
+
* `gen/`: Type-safe, generated code including `types.ts`, `operations.ts`, etc.
|
|
124
|
+
* `src/`: The skeleton for your implementation, most importantly `src/reducers/to-do-list.ts`, which will contain empty functions for `addTodoItemOperation`, `updateTodoItemOperation`, and `deleteTodoItemOperation`, ready for you to implement.
|
|
125
|
+
|
|
126
|
+
With these files generated, you have successfully scaffolded your document model. The project is now set up for you to implement the core business logic.
|
|
127
|
+
|
|
128
|
+
</details>
|
|
109
129
|
|
|
110
130
|
## Next Steps
|
|
111
131
|
|