@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.
Files changed (29) hide show
  1. package/CHANGELOG.md +18 -0
  2. package/docs/academy/01-GetStarted/00-ExploreDemoPackage.md +4 -8
  3. package/docs/academy/01-GetStarted/01-CreateNewPowerhouseProject.md +3 -1
  4. package/docs/academy/01-GetStarted/02-DefineToDoListDocumentModel.md +1 -1
  5. package/docs/academy/01-GetStarted/03-ImplementOperationReducers.md +4 -4
  6. package/docs/academy/01-GetStarted/04-BuildToDoListEditor.md +5 -9
  7. package/docs/academy/01-GetStarted/home.mdx +1 -9
  8. package/docs/academy/01-GetStarted/styles.module.css +31 -0
  9. package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/02-StandardDocumentModelWorkflow.md +7 -3
  10. package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/03-BuilderTools.md +1 -1
  11. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/01-WhatIsADocumentModel.md +26 -18
  12. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/02-SpecifyTheStateSchema.md +70 -2
  13. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/03-SpecifyDocumentOperations.md +59 -4
  14. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/04-UseTheDocumentModelGenerator.md +32 -12
  15. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/05-ImplementDocumentReducers.md +103 -38
  16. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/06-ImplementDocumentModelTests.md +85 -228
  17. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/07-ExampleToDoListRepository.md +41 -1
  18. package/docs/academy/02-MasteryTrack/05-Launch/03-SetupEnvironment.md +5 -2
  19. package/docs/academy/05-Architecture/00-PowerhouseArchitecture.md +3 -0
  20. package/docs/academy/05-Architecture/images/PowerhouseArchitecture.png +0 -0
  21. package/docs/academy/06-ComponentLibrary/00-DocumentEngineering.md +27 -16
  22. package/docs/academy/06-ComponentLibrary/02-CreateCustomScalars.md +8 -7
  23. package/docs/academy/07-Cookbook.md +209 -0
  24. package/docs/academy/08-Glossary.md +19 -20
  25. package/docs/academy/09-AIResources +131 -0
  26. package/package.json +1 -1
  27. package/sidebars.ts +0 -2
  28. package/docs/academy/06-ComponentLibrary/04-ScalarVsUIComponents.md +0 -52
  29. 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 "**Contributor Billing**" package. This package demonstrates how you might track and bill for contributions in a project. First, you need the Powerhouse command-line interface (CLI). Open your terminal and run the installation command:
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/contributor-billing
40
+ ph install @powerhousedao/todo-demo-package.
40
41
  ```
41
42
 
42
- This command downloads and sets up the Contributor Billing package, making its features available in your Powerhouse environment.
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 style={{
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
  }
@@ -1,9 +1,13 @@
1
- # Creating Powerhouse packages
1
+ # Create Powerhouse packages
2
2
 
3
- This tutorial guides you through creating a Powerhouse Document Model, from initial setup to publishing a distributable package. We'll leverage the Powerhouse CLI and Connect Studio Mode for a streamlined development experience.
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
- If you have completed the Get Started tutorial you will revisit familiar topics.
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
- A Document Model is:
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! # Unique identifier for the invoice
41
- issuer: OID! # Reference to the issuing entity
42
- recipient: OID! # Reference to the recipient entity
43
- status: String @default(value: "DRAFT") # Invoice status
44
- dueDate: DateTime # Payment due date
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 # Computed field for total invoice value
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 @default(value: 1)
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 @default(value: 1)
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. Instead, a new event is appended to the document history.
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
- - **API Integration**: Document Models can be integrated with Switchboard API or external APIs, allowing for the exchange of data between Connect and other systems or services.
188
-
189
- - **Data Analysis**: The structured nature of Document Models makes them ideal for data analysis and reporting. Users can extract insights and generate reports based on the data captured within the models which is accessible through read models. (Operational data + Analytics data which takes into account time series of the data).
190
-
191
- - **Version Control**: Similar to how Git manages changes to source code, Document Models in Connect will support version control, enabling users to track changes, compare different versions, and ensure data integrity over time.
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
- At the end of this Document Model Creation Chapter you will find the ToDoList Repository where you can explore the code and implementation of all the items we have discussed.
77
- You'll be able to run the advanced ToDoList in Connect Studio and explore the reducers and editor code.
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
+
@@ -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), you create a clear contract for state transitions. This approach enhances type safety, testability, and the overall maintainability of your document model.
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.
@@ -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
- ## Example Workflow Snippet
93
+ ## Practical Implementation: Generating the `ToDoList` Model
94
94
 
95
- Let's assume you have defined a `ProjectTask` document model and exported `ProjectTask.phdm.zip`.
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
- 1. **Navigate to your Powerhouse project root in the terminal.**
98
- 2. **Run the generator:**
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 ProjectTask.phdm.zip
116
+ ph generate ToDoList.phdm.zip
101
117
  ```
102
- 3. **Explore the generated files:**
103
- You would now find a new directory `document-models/project-task/` containing:
104
- * `project-task/spec.json`
105
- * `project-task/schema.graphql`
106
- * `project-task/gen/types.ts` (with `ProjectTaskState`, `AssignUserInput`, etc.)
107
- * `project-task/gen/operations.ts` (with `creators.assignUser(...)`, `creators.completeTask(...)`, etc.)
108
- * `project-task/src/reducers/project-task.ts` (with empty functions like `assignUserOperation`, `completeTaskOperation` awaiting your implementation).
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