@powerhousedao/academy 5.1.0-staging.0 → 5.1.0
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 +46 -1148
- package/blog/BeyondCommunication-ABlueprintForDevelopment.md +1 -2
- package/blog/TheChallengeOfChange.md +0 -1
- package/docs/academy/00-EthereumArgentinaHackathon.md +207 -0
- package/docs/academy/01-GetStarted/00-ExploreDemoPackage.mdx +27 -24
- package/docs/academy/01-GetStarted/01-CreateNewPowerhouseProject.md +10 -155
- package/docs/academy/01-GetStarted/02-DefineToDoListDocumentModel.md +35 -122
- package/docs/academy/01-GetStarted/03-ImplementOperationReducers.md +155 -178
- package/docs/academy/01-GetStarted/04-BuildToDoListEditor.md +218 -0
- package/docs/academy/{02-MasteryTrack/01-BuilderEnvironment → 01-GetStarted}/05-VetraStudio.md +22 -62
- package/docs/academy/01-GetStarted/06-ReactorMCP.md +58 -0
- package/docs/academy/01-GetStarted/_04-BuildToDoListEditor +1 -1
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/03-BuilderTools.md +2 -2
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/02-SpecifyTheStateSchema.md +44 -75
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/03-SpecifyDocumentOperations.md +22 -28
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/04-UseTheDocumentModelGenerator.md +31 -28
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/05-ImplementDocumentReducers.md +206 -211
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/06-ImplementDocumentModelTests.md +62 -176
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/07-ExampleToDoListRepository.md +0 -21
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/01-BuildingDocumentEditors.md +319 -309
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/00-DocumentToolbar.mdx +0 -4
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/01-OperationHistory.md +0 -4
- package/docs/academy/02-MasteryTrack/05-Launch/04-ConfigureEnvironment.md +1 -1
- package/docs/academy/03-ExampleUsecases/Chatroom/02-CreateNewPowerhouseProject.md +35 -111
- package/docs/academy/03-ExampleUsecases/Chatroom/03-DefineChatroomDocumentModel.md +79 -195
- package/docs/academy/03-ExampleUsecases/Chatroom/04-ImplementOperationReducers.md +241 -435
- package/docs/academy/03-ExampleUsecases/Chatroom/05-ImplementChatroomEditor.md +27 -388
- package/docs/academy/03-ExampleUsecases/Chatroom/06-LaunchALocalReactor.md +7 -95
- package/docs/academy/03-ExampleUsecases/Chatroom/_category_.json +1 -1
- package/docs/academy/04-APIReferences/00-PowerhouseCLI.md +2 -6
- package/docs/academy/04-APIReferences/01-ReactHooks.md +501 -291
- package/docs/academy/05-Architecture/00-PowerhouseArchitecture.md +39 -7
- package/docs/academy/05-Architecture/02-ReferencingMonorepoPackages +65 -0
- package/docs/academy/05-Architecture/04-MovingBeyondCRUD +61 -0
- package/docs/academy/06-ComponentLibrary/00-DocumentEngineering.md +24 -72
- package/docs/academy/08-Glossary.md +0 -7
- package/docusaurus.config.ts +3 -28
- package/package.json +1 -1
- package/sidebars.ts +13 -49
- package/src/css/custom.css +18 -26
- package/docs/academy/01-GetStarted/04-WriteDocumentModelTests.md +0 -425
- package/docs/academy/01-GetStarted/05-BuildToDoListEditor.md +0 -557
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/images/Modules.png +0 -0
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/images/VetraStudioDrive.png +0 -0
- package/docs/academy/02-MasteryTrack/05-Launch/05-DockerDeployment.md +0 -384
- package/docs/academy/03-ExampleUsecases/TodoList/00-GetTheStarterCode.md +0 -24
- package/docs/academy/03-ExampleUsecases/TodoList/01-GenerateTodoListDocumentModel.md +0 -211
- package/docs/academy/03-ExampleUsecases/TodoList/02-ImplementTodoListDocumentModelReducerOperationHandlers.md +0 -171
- package/docs/academy/03-ExampleUsecases/TodoList/03-AddTestsForTodoListActions.md +0 -462
- package/docs/academy/03-ExampleUsecases/TodoList/04-GenerateTodoListDocumentEditor.md +0 -45
- package/docs/academy/03-ExampleUsecases/TodoList/05-ImplementTodoListDocumentEditorUIComponents.md +0 -422
- package/docs/academy/03-ExampleUsecases/TodoList/06-GenerateTodoDriveExplorer.md +0 -61
- package/docs/academy/03-ExampleUsecases/TodoList/07-AddSharedComponentForShowingTodoListStats.md +0 -384
- package/docs/academy/03-ExampleUsecases/TodoList/_category_.json +0 -8
- package/docs/academy/03-ExampleUsecases/VetraPackageLibrary/VetraPackageLibrary.md +0 -7
- package/docs/academy/03-ExampleUsecases/VetraPackageLibrary/_category_.json +0 -9
- package/docs/academy/04-APIReferences/06-VetraRemoteDrive.md +0 -160
- package/docs/academy/04-APIReferences/renown-sdk/00-Overview.md +0 -316
- package/docs/academy/04-APIReferences/renown-sdk/01-Authentication.md +0 -672
- package/docs/academy/04-APIReferences/renown-sdk/02-APIReference.md +0 -957
- package/docs/academy/04-APIReferences/renown-sdk/_category_.json +0 -8
- package/docs/academy/10-TodoListTutorial/02-ImplementTodoListDocumentModelReducerOperationHandlers.md +0 -171
- package/docs/academy/10-TodoListTutorial/03-AddTestsForTodoListActions.md +0 -462
- package/docs/academy/10-TodoListTutorial/05-ImplementTodoListDocumentEditorUIComponents.md +0 -422
- package/docs/academy/10-TodoListTutorial/07-AddSharedComponentForShowingTodoListStats.md +0 -370
- package/static/img/Vetra-logo-dark.svg +0 -11
- package/static/img/vetra-logo-light.svg +0 -11
- /package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/{02-RevisionHistoryTimeline/360/237/232/247" → 02-RevisionHistoryTimeline} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{360/237/232/247 /01-WhatIsADocumentModel" → 01-WhatIsADocumentModel} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{360/237/232/247 /02-DAOandDocumentsModelsQ+A" → 02-DAOandDocumentsModelsQ+A} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{360/237/232/247 /02-domain-modeling" → 02-domain-modeling} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{360/237/232/247 /03-BenefitsOfDocumentModels" → 03-BenefitsOfDocumentModels} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{360/237/232/247 /04-UtilitiesAndTips" → 04-UtilitiesAndTips} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{360/237/232/247 /05-best-practices" → 05-best-practices} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{360/237/232/247 /_category_.json" → _category_.json} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{360/237/232/247 /three-data-layers.png" → three-data-layers.png} +0 -0
|
@@ -1,9 +1,6 @@
|
|
|
1
1
|
# Powerhouse Architecture
|
|
2
2
|
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
The Powerhouse ecosystem makes use of 4 core host applications that together form a modular, scalable operating system for decentralized organizations.
|
|
6
|
-
Each application serves a distinct role, yet they are interdependent, working as a unified system to streamline operations, enhance collaboration, and drive automation.
|
|
3
|
+
The Powerhouse ecosystem is built on five core host applications that together form a modular, scalable operating system for decentralized organizations. Each application serves a distinct role, yet they are interdependent, working as a unified system to streamline operations, enhance collaboration, and drive automation.
|
|
7
4
|
|
|
8
5
|
These five applications are:
|
|
9
6
|
|
|
@@ -11,10 +8,45 @@ These five applications are:
|
|
|
11
8
|
2. **Switchboard** – The data infrastructure and API engine.
|
|
12
9
|
3. **Fusion** – The public-facing collaboration hub.
|
|
13
10
|
4. **Renown** – The decentralized reputation and identity system.
|
|
11
|
+
5. **Academy** – The onboarding and learning modules.
|
|
12
|
+
|
|
13
|
+
Each application is designed to be modular yet complementary, ensuring smooth data flows, structured collaboration, and scalable automation. The functionality of the four host apps offers an integrated experience for running decentralized operations.
|
|
14
14
|
|
|
15
15
|

|
|
16
16
|
|
|
17
|
-
|
|
17
|
+
## How the Five Applications Work Together
|
|
18
|
+
|
|
19
|
+
The Powerhouse ecosystem functions as a decentralized operating system, where each of the four core applications works in synergy to ensure seamless collaboration, structured data management, and automated workflows. Each application has a distinct purpose, yet their interconnectivity is what makes the system powerful.
|
|
20
|
+
|
|
21
|
+
### 1. Connect: The Contributor's Workspace and Data Capture Point
|
|
22
|
+
|
|
23
|
+
Connect is the entry point for individual contributors, where they install apps and packages tailored to specific business solutions, enabling collaboration in public or private settings.
|
|
24
|
+
|
|
25
|
+
- All work in Connect is captured as document models, ensuring that data is structured, traceable, and immediately available for processing.
|
|
26
|
+
- This structured data flows into Switchboard, making it accessible for analytics, automation, and API-driven integrations.
|
|
27
|
+
- Fusion then utilizes this data to generate dashboards, summaries, and insights for decision-making.
|
|
28
|
+
- Renown serves as the authentication and access gateway, ensuring that contributors can securely interact with the system.
|
|
29
|
+
|
|
30
|
+
### 2. Switchboard: The Data Processing and Automation Engine
|
|
31
|
+
|
|
32
|
+
Switchboard acts as the central nervous system, ensuring that data flows efficiently between applications and powers real-time coordination.
|
|
33
|
+
|
|
34
|
+
- It ingests structured data from Connect and makes it available for further analysis, automation, and integrations.
|
|
35
|
+
- The API interface allows developers and data engineers to fuel the broader system, providing insights and feeding data-driven workflows.
|
|
36
|
+
- The processed data is then transmitted to Fusion, where it is transformed into dashboards, analytics, and key performance indicators (KPIs).
|
|
37
|
+
|
|
38
|
+
### 3. Fusion: The Public Collaboration and Data Visualization Layer
|
|
39
|
+
|
|
40
|
+
Fusion serves as the public-facing marketplace and collaboration hub, allowing contributors and organizations to interact with structured data captured from Connect and processed through Switchboard.
|
|
41
|
+
|
|
42
|
+
- Fusion structures, summarizes, and visualizes key metrics, enabling users to make data-driven decisions.
|
|
43
|
+
- It pulls relevant operational insights, helping stakeholders navigate and act on real-time data.
|
|
44
|
+
- Users can directly access work completed in Connect, viewing reports, summaries, and discussions within Fusion's public and private environments.
|
|
45
|
+
|
|
46
|
+
### 4. Renown: Authentication, Reputation, and Access Control
|
|
47
|
+
|
|
48
|
+
Renown is the trust and identity layer, ensuring security, reputation tracking, and access control across the ecosystem.
|
|
18
49
|
|
|
19
|
-
-
|
|
20
|
-
-
|
|
50
|
+
- It acts as the authentication gateway, determining who has permission to view, edit, or execute specific operations within the system.
|
|
51
|
+
- Every action performed in Connect is tracked in the document history, making it fully auditable through Switchboard.
|
|
52
|
+
- Fusion utilizes Renown to verify contributor credibility, ensuring that data-driven decisions are based on trusted and authenticated inputs.
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
# Referencing Monorepo Packages
|
|
2
|
+
|
|
3
|
+
## **Context**
|
|
4
|
+
|
|
5
|
+
In scenarios where a project is not part of the monorepo but needs to reference monorepo packages (e.g., using `@powerhousedeao/ph-cli`), there's a streamlined approach that avoids duplicating dependencies and maintains consistency with monorepo versions.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## **Approach**
|
|
10
|
+
|
|
11
|
+
### **1. Using `link:` in `package.json`**
|
|
12
|
+
|
|
13
|
+
Instead of manually copying dependencies or trying complex build setups, you can use the `link:` protocol to create a symlink to the monorepo package.
|
|
14
|
+
|
|
15
|
+
```json
|
|
16
|
+
{
|
|
17
|
+
"dependencies": {
|
|
18
|
+
"@powerhousedeao/ph-cli": "link:../monorepo/clis/ph-cli"
|
|
19
|
+
}
|
|
20
|
+
}
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
This approach creates a symlink under the node_modules directory, linking directly to the specified monorepo package.
|
|
24
|
+
|
|
25
|
+
### **2. Running the Linked CLI**
|
|
26
|
+
|
|
27
|
+
After linking, you can run the CLI tool using pnpm:
|
|
28
|
+
|
|
29
|
+
```bash
|
|
30
|
+
pnpm install
|
|
31
|
+
pnpm run ../powerhouse/clis/ph-cli
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Alternatively, use the command through the linked CLI:
|
|
35
|
+
|
|
36
|
+
```bash
|
|
37
|
+
ph connect
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
This will invoke the connect package from the monorepo.
|
|
41
|
+
|
|
42
|
+
### **3. Building Dependencies**
|
|
43
|
+
|
|
44
|
+
To ensure all dependencies are correctly built:
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
nx run @powerhousedeao/ph-cli
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
This command will build all necessary dependencies within the monorepo.
|
|
51
|
+
|
|
52
|
+
### **4. Key Insights**
|
|
53
|
+
|
|
54
|
+
- **Symlink Simplicity:** The link: protocol is the least disruptive, as it avoids version conflicts and unnecessary duplication.
|
|
55
|
+
- **Development Workflow:** Changes made to the connect code in the monorepo will be picked up automatically when using the linked CLI, as ph-cli defers calls to the respective packages.
|
|
56
|
+
|
|
57
|
+
### **5. Troubleshooting**
|
|
58
|
+
|
|
59
|
+
If dependencies aren't picked up correctly: Ensure the symlink path is accurate relative to the project root.
|
|
60
|
+
|
|
61
|
+
For isolated package builds: Use nx run to trigger specific package builds when needed.
|
|
62
|
+
|
|
63
|
+
### **6. Conclusion**
|
|
64
|
+
Using link: is an effective, developer-friendly method to reference monorepo packages in external boilerplate projects. It supports efficient development workflows, reduces redundancy, and ensures consistency across environments.
|
|
65
|
+
|
|
@@ -0,0 +1,61 @@
|
|
|
1
|
+
# Moving Beyond CRUD
|
|
2
|
+
|
|
3
|
+
Powerhouse uses "single field operations" as granular actions that go beyond traditional CRUD (Create, Read, Update, Delete) operations.
|
|
4
|
+
In a basic CRUD framework, the focus is on making entire objects or records editable as a whole, often leading to oversimplified data management that can't easily handle complex workflows or state transitions.
|
|
5
|
+
|
|
6
|
+
## What Are Single Field Operations?
|
|
7
|
+
These are focused, granular updates to individual fields within a document rather than treating the document as a whole. This approach allows for precise control and tracking of changes. For example:
|
|
8
|
+
|
|
9
|
+
- Setting a Document Number (simple string input)
|
|
10
|
+
- Changing Master Status (an enum dropdown selection)
|
|
11
|
+
|
|
12
|
+
Each of these operations targets only one field and has a corresponding form that collects and submits the new value.
|
|
13
|
+
|
|
14
|
+
## Why go beyond CRUD?
|
|
15
|
+
|
|
16
|
+
### Granular State Tracking:
|
|
17
|
+
Powerhouse's system emphasizes understanding how documents transition from one state to another in fine detail. By breaking down actions into specific field-level operations, it allows for tracking the exact sequence of changes, which is crucial for things like auditing, version control, and complex workflows.
|
|
18
|
+
|
|
19
|
+
### Operational Focus:
|
|
20
|
+
The system is designed around the idea of operations themselves—not just the data they manipulate. While traditional CRUD frameworks might treat each field as independently updatable without any logic or process attached, Powerhouse assigns specific operations that can enforce business rules and state transitions.
|
|
21
|
+
|
|
22
|
+
### Customization & Flexibility:
|
|
23
|
+
CRUD frameworks are often too rigid for real-world applications that need more nuanced behaviors. Powerhouse offers both the simplicity of CRUD for standard operations and the ability to go deeper, defining more complex, field-specific operations when needed. This hybrid approach ensures flexibility without sacrificing systematic structure.
|
|
24
|
+
|
|
25
|
+
### Automation Potential:
|
|
26
|
+
Even though creating these granular operations might seem tedious, the goal is to build a system where standard CRUD operations can eventually be auto-generated, leaving developers to focus only on defining the exceptional, non-standard behaviors.
|
|
27
|
+
|
|
28
|
+
### Improved Permissions and User Intent:
|
|
29
|
+
By having specific operations tied to individual fields, it becomes easier to manage permissions (e.g., who can change the master status but not the content) and to capture user intent more precisely, which is valuable in complex collaborative environments.
|
|
30
|
+
|
|
31
|
+
|
|
32
|
+
## Understanding the Code Example
|
|
33
|
+
|
|
34
|
+

|
|
35
|
+
|
|
36
|
+
| `SetDocNumberForm.tsx` (StringField) | `SetMasterStatusForm.tsx` (EnumField) |
|
|
37
|
+
|-------------------------------------|---------------------------------------|
|
|
38
|
+
| **Purpose:** To update the document number (a string field).<br /><br />**How it works:**<br />- A form is rendered with a StringField input<br />- The defaultValue comes from the document model (props.defaultValue.docNo)<br />- On submit (or onBlur), the new document number is dispatched via the dispatch function<br />- It uses a generic onSubmit handler that processes the collected input and triggers the document update<br /><br />**Key takeaway:**<br />- This is a simple, single field form that maps a scalar string to a reusable component (StringField)<br />- The form structure is systematic: label, name, placeholder, and onBlur event handler | **Purpose:** To update the master status (an enum field).<br /><br />**How it works:**<br />- A form is rendered with an EnumField dropdown<br />- The dropdown options are enum values like "APPROVED", "DEFERRED", etc.<br />- The default value is pre-filled from props.defaultValue.masterStatus<br />- On change, the form dispatches the updated status<br /><br />**Key takeaway:**<br />- This form uses an EnumField component, showcasing how different scalar types (in this case, enums) map to different input components<br />- Options are provided systematically, meaning they could potentially be auto-generated from the document model |
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
## Why Is This Granular Approach Important?
|
|
43
|
+
1. **Systematic Yet Customizable:**
|
|
44
|
+
Even we are manually building these forms now, the structure is simple and repeatable:
|
|
45
|
+
- Identify the scalar type (string, enum, etc.).
|
|
46
|
+
- Map it to a reusable component.
|
|
47
|
+
- Use a standardized form structure with an onSubmit handler and a dispatch function.
|
|
48
|
+
2. **Auto-Generation Potential:**
|
|
49
|
+
The systematic nature of these forms means they could be automatically generated in the future.
|
|
50
|
+
- For example, if a field is identified as a string, the system could auto-generate a form using a StringField.
|
|
51
|
+
- For enums, it could auto-generate the EnumField with all valid options.
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
## How to implement single field operations
|
|
55
|
+
|
|
56
|
+
### At the schema definition level
|
|
57
|
+
|
|
58
|
+
### At the frontend level
|
|
59
|
+
|
|
60
|
+
|
|
61
|
+
|
|
@@ -112,86 +112,38 @@ While Storybook aims for accuracy, there might occasionally be discrepancies or
|
|
|
112
112
|
|
|
113
113
|
## Implementing a Component
|
|
114
114
|
|
|
115
|
-
Let's walk through the typical workflow for using a component from the document-engineering system, using `
|
|
115
|
+
Let's walk through the typical workflow for using a component from the document-engineering system, using the `Checkbox` from the [To-do List editor](/academy/MasteryTrack/BuildingUserExperiences/BuildingDocumentEditors).
|
|
116
116
|
|
|
117
|
-
1. **Identify the Need:** While building your feature (e.g., the
|
|
117
|
+
1. **Identify the Need:** While building your feature (e.g., the To-do List editor in `editor.tsx`), you determine the need for a standard UI element, like a checkbox.
|
|
118
118
|
2. **Consult the Document Engineering Components in Storybook:**
|
|
119
119
|
- Open the Powerhouse Storybook instance. [https://storybook.powerhouse.academy](https://storybook.powerhouse.academy)
|
|
120
|
-
- Navigate or search to find the `
|
|
120
|
+
- Navigate or search to find the `Checkbox` component.
|
|
121
121
|
- Review the visual examples and interactive demo.
|
|
122
|
-
- Examine the "Usage" snippet and the **Props table** to understand the basic implementation and available configuration options (`
|
|
123
|
-
3. **Import the Component:** In your code editor, open the relevant file (e.g., `editors/
|
|
122
|
+
- Examine the "Usage" snippet and the **Props table** to understand the basic implementation and available configuration options (`label`, `value`, `onChange`, etc.).
|
|
123
|
+
3. **Import the Component:** In your code editor, open the relevant file (e.g., `editors/to-do-list/editor.tsx`). Add an import statement at the top to bring the component into your file's scope:
|
|
124
124
|
```typescript
|
|
125
|
-
import {
|
|
125
|
+
import { Checkbox } from "@powerhousedao/document-engineering/scalars";
|
|
126
|
+
// Or import other components as needed:
|
|
127
|
+
// import { Checkbox, InputField, Button } from '@powerhousedao/document-engineering/scalars';
|
|
126
128
|
```
|
|
127
|
-
This line instructs the build process to locate the `
|
|
128
|
-
|
|
129
|
-
:::info Form Wrapper Required
|
|
130
|
-
Scalar components like `BooleanField` must be wrapped in a `Form` component from the same package. This provides built-in validation and form state management.
|
|
131
|
-
:::
|
|
132
|
-
|
|
133
|
-
4. **Use and Configure the Component:** Place the component tag in your JSX where needed. Use the information from Storybook (usage snippet and props table) as a guide, but adapt the props to your specific requirements:
|
|
134
|
-
|
|
135
|
-
**Step 4a: Create a reusable Checkbox component**
|
|
136
|
-
```typescript
|
|
137
|
-
// editors/todo-list-editor/components/Checkbox.tsx
|
|
138
|
-
import { Form, BooleanField } from "@powerhousedao/document-engineering/scalars";
|
|
139
|
-
|
|
140
|
-
interface CheckboxProps {
|
|
141
|
-
value: boolean;
|
|
142
|
-
onChange: (value: boolean) => void;
|
|
143
|
-
}
|
|
144
|
-
|
|
145
|
-
export const Checkbox = ({ value, onChange }: CheckboxProps) => {
|
|
146
|
-
return (
|
|
147
|
-
<Form onSubmit={() => {}}>
|
|
148
|
-
<BooleanField
|
|
149
|
-
name="checked"
|
|
150
|
-
description="Mark as complete"
|
|
151
|
-
value={value}
|
|
152
|
-
onChange={onChange}
|
|
153
|
-
/>
|
|
154
|
-
</Form>
|
|
155
|
-
);
|
|
156
|
-
};
|
|
157
|
-
```
|
|
158
|
-
|
|
159
|
-
**Step 4b: Use it in your Todo component with the document model hook**
|
|
129
|
+
This line instructs the build process to locate the `Checkbox` component within the installed `@powerhousedao/document-engineering/scalars` package and make it available for use.
|
|
130
|
+
4. **Use and Configure the Component:** Place the component tag in your JSX where needed. Use the information from Storybook (usage snippet and props table) as a guide, but adapt the props to your specific requirements within `editor.tsx`:
|
|
160
131
|
```typescript
|
|
161
|
-
//
|
|
162
|
-
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
|
|
171
|
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
return (
|
|
175
|
-
<div className="flex items-center gap-2">
|
|
176
|
-
<Checkbox
|
|
177
|
-
value={todo.checked}
|
|
178
|
-
onChange={() => {
|
|
179
|
-
dispatch(updateTodoItem({
|
|
180
|
-
id: todo.id,
|
|
181
|
-
checked: !todo.checked,
|
|
182
|
-
}));
|
|
183
|
-
}}
|
|
184
|
-
/>
|
|
185
|
-
<span className={todo.checked ? "line-through" : ""}>
|
|
186
|
-
{todo.text}
|
|
187
|
-
</span>
|
|
188
|
-
</div>
|
|
189
|
-
);
|
|
190
|
-
}
|
|
132
|
+
// Example from the To-do List Editor:
|
|
133
|
+
<Checkbox
|
|
134
|
+
// Bind the checked state to data within editor.tsx
|
|
135
|
+
value={item.checked}
|
|
136
|
+
// Provide a function from editor.tsx to handle changes
|
|
137
|
+
onChange={() => {
|
|
138
|
+
dispatch(actions.updateTodoItem({
|
|
139
|
+
id: item.id,
|
|
140
|
+
checked: !item.checked,
|
|
141
|
+
}));
|
|
142
|
+
}}
|
|
143
|
+
// Other props like 'label' might be omitted or added as needed.
|
|
144
|
+
/>
|
|
191
145
|
```
|
|
192
|
-
|
|
193
|
-
You configure the component's appearance and behavior by passing the appropriate values to its props. Note the use of the `useSelectedTodoListDocument` hook to access the dispatch function.
|
|
194
|
-
|
|
146
|
+
You configure the component's appearance and behavior by passing the appropriate values to its props.
|
|
195
147
|
5. **Test and Refine:** Run your application (e.g., using `ph connect`) to see the component in context. Verify its appearance and functionality.
|
|
196
148
|
|
|
197
149
|
## Usage
|
|
@@ -13,17 +13,13 @@
|
|
|
13
13
|
|
|
14
14
|
## Software Components
|
|
15
15
|
|
|
16
|
-
- **Model Context Protocol (MCP)** – A standardized protocol that enables AI agents and external tools to interact with systems through structured operations. Powerhouse uses MCP to provide AI access to document management capabilities.
|
|
17
16
|
- **Reactor** – A storage node for Powerhouse documents and files with multiple storage adapters (local, cloud, decentralized).
|
|
18
|
-
- **Reactor-MCP** – A Model Context Protocol server for the Powerhouse ecosystem that provides AI agents and tools with structured access to document model operations, serving as a bridge between AI systems and Powerhouse document management infrastructure.
|
|
19
17
|
- **Powerhouse Switchboard** – A scalable API service that aggregates and processes document data.
|
|
20
18
|
- **Powerhouse Fusion** – A platform front-end that hosts the public marketplace for SNO interactions.
|
|
21
19
|
- **Powerhouse Renown** – A decentralized authentication system managing contributor reputation.
|
|
22
20
|
- **Powerhouse Academy** – A training platform for onboarding and upskilling SNO contributors.
|
|
23
21
|
- **Connect** – The contributor's public or private workspace, serving as the entry point for individual contributors to install apps and packages for specific business solutions.
|
|
24
22
|
- **Powergrid** – A decentralized network of reactors that sync with each other.
|
|
25
|
-
- **Preview Drive** – A local drive created in `--watch` mode during `ph vetra` development, used for testing local document models and editors without affecting the main synced drive.
|
|
26
|
-
- **Remote Drive** – A Powerhouse drive hosted on a remote server (e.g., Vetra) that syncs across team members, enabling collaborative development on shared documents and document models.
|
|
27
23
|
- **Powerhouse CLI (ph)** – The command-line tool for Powerhouse project initialization, code generation, package management, and running local development environments (Connect Studio). It also manages services, ensuring the terminology aligns with the updated setup guide.
|
|
28
24
|
- **Connect App (Connect Studio)** – The primary Powerhouse application for defining document models, building/testing editors (in Studio mode), and collaborating on documents.
|
|
29
25
|
- **Document Tools** – Built-in features within Powerhouse applications (e.g., Connect) that assist with document management, inspection, and interaction, such as Operations History.
|
|
@@ -78,13 +74,10 @@
|
|
|
78
74
|
- **State (Local State in Editor)** – Temporary, UI-specific data within an editor (e.g., form inputs), not persisted in the global document state.
|
|
79
75
|
- **Storybook (for Powerhouse Design System)** – Interactive environment for browsing and testing Powerhouse Design System UI components.
|
|
80
76
|
- **Tailwind CSS (in Connect Studio)** – Utility CSS framework integrated into Connect Studio for styling document editors.
|
|
81
|
-
- **Vetra** – A Powerhouse platform for hosting remote drives, enabling collaborative development and document synchronization across team members.
|
|
82
|
-
- **Watch Mode (`--watch`)** – A development mode flag for `ph vetra` that enables dynamic loading of local document models and editors, creating a separate Preview Drive for testing changes in real-time.
|
|
83
77
|
|
|
84
78
|
## AI & Automation
|
|
85
79
|
|
|
86
80
|
- **AI Assistants** – AI-powered contributors paired with human contributors to automate tasks and improve productivity.
|
|
87
|
-
- **Document Model Agent** – A specialized AI agent that guides users through creating document models, handling requirements gathering, design confirmation, and implementation using MCP tools for state schema definition, operation creation, and code generation.
|
|
88
81
|
- **AI Contributor Modes** – Configurable states that determine the AI assistant's behavior, permissions, and task focus.
|
|
89
82
|
- **Task Automation & Scaling** – The use of AI to streamline repetitive tasks, improve communications, and enhance decision-making.
|
|
90
83
|
- **Decentralized Identifier (DID)** – A user-controlled, globally unique ID, used in Renown to link a user's blockchain key to actions pseudonymously.
|
package/docusaurus.config.ts
CHANGED
|
@@ -19,6 +19,7 @@ const config: Config = {
|
|
|
19
19
|
projectName: "", // Usually your repo name.
|
|
20
20
|
|
|
21
21
|
onBrokenLinks: "warn",
|
|
22
|
+
onBrokenMarkdownLinks: "warn",
|
|
22
23
|
deploymentBranch: "gh-pages",
|
|
23
24
|
trailingSlash: false,
|
|
24
25
|
onBrokenAnchors: "ignore",
|
|
@@ -31,12 +32,6 @@ const config: Config = {
|
|
|
31
32
|
locales: ["en"],
|
|
32
33
|
},
|
|
33
34
|
|
|
34
|
-
markdown: {
|
|
35
|
-
hooks: {
|
|
36
|
-
onBrokenMarkdownLinks: "warn",
|
|
37
|
-
},
|
|
38
|
-
},
|
|
39
|
-
|
|
40
35
|
presets: [
|
|
41
36
|
[
|
|
42
37
|
"classic",
|
|
@@ -81,8 +76,8 @@ const config: Config = {
|
|
|
81
76
|
title: "",
|
|
82
77
|
logo: {
|
|
83
78
|
alt: "My Site Logo",
|
|
84
|
-
src: "img/
|
|
85
|
-
srcDark: "img/
|
|
79
|
+
src: "img/Powerhouse-main.svg",
|
|
80
|
+
srcDark: "img/Powerhouse-main-light.svg",
|
|
86
81
|
href: "/",
|
|
87
82
|
},
|
|
88
83
|
items: [
|
|
@@ -159,26 +154,6 @@ const config: Config = {
|
|
|
159
154
|
prism: {
|
|
160
155
|
theme: prismThemes.github,
|
|
161
156
|
darkTheme: prismThemes.dracula,
|
|
162
|
-
magicComments: [
|
|
163
|
-
// Default highlight
|
|
164
|
-
{
|
|
165
|
-
className: 'theme-code-block-highlighted-line',
|
|
166
|
-
line: 'highlight-next-line',
|
|
167
|
-
block: { start: 'highlight-start', end: 'highlight-end' },
|
|
168
|
-
},
|
|
169
|
-
// Green for additions
|
|
170
|
-
{
|
|
171
|
-
className: 'code-block-added-line',
|
|
172
|
-
line: 'added-line',
|
|
173
|
-
block: { start: 'added-start', end: 'added-end' },
|
|
174
|
-
},
|
|
175
|
-
// Red for deletions
|
|
176
|
-
{
|
|
177
|
-
className: 'code-block-removed-line',
|
|
178
|
-
line: 'removed-line',
|
|
179
|
-
block: { start: 'removed-start', end: 'removed-end' },
|
|
180
|
-
},
|
|
181
|
-
],
|
|
182
157
|
},
|
|
183
158
|
tableOfContents: {
|
|
184
159
|
minHeadingLevel: 2,
|
package/package.json
CHANGED
package/sidebars.ts
CHANGED
|
@@ -11,6 +11,14 @@
|
|
|
11
11
|
const sidebars = {
|
|
12
12
|
// By default, Docusaurus generates a sidebar from the docs folder structure
|
|
13
13
|
academySidebar: [
|
|
14
|
+
{
|
|
15
|
+
type: "doc",
|
|
16
|
+
id: "academy/EthereumArgentinaHackathon",
|
|
17
|
+
label: "ETH Argentina Hackathon",
|
|
18
|
+
customProps: {
|
|
19
|
+
icon: "/img/ethereum-logo.jpg",
|
|
20
|
+
},
|
|
21
|
+
},
|
|
14
22
|
{
|
|
15
23
|
type: "category",
|
|
16
24
|
label: "Get started",
|
|
@@ -23,8 +31,9 @@ const sidebars = {
|
|
|
23
31
|
"academy/GetStarted/CreateNewPowerhouseProject",
|
|
24
32
|
"academy/GetStarted/DefineToDoListDocumentModel",
|
|
25
33
|
"academy/GetStarted/ImplementOperationReducers",
|
|
26
|
-
"academy/GetStarted/WriteDocumentModelTests",
|
|
27
34
|
"academy/GetStarted/BuildToDoListEditor",
|
|
35
|
+
"academy/GetStarted/VetraStudio",
|
|
36
|
+
"academy/GetStarted/ReactorMCP",
|
|
28
37
|
],
|
|
29
38
|
},
|
|
30
39
|
{
|
|
@@ -41,7 +50,7 @@ const sidebars = {
|
|
|
41
50
|
items: [
|
|
42
51
|
"academy/MasteryTrack/BuilderEnvironment/Prerequisites",
|
|
43
52
|
"academy/MasteryTrack/BuilderEnvironment/StandardDocumentModelWorkflow",
|
|
44
|
-
"academy/MasteryTrack/BuilderEnvironment/
|
|
53
|
+
"academy/MasteryTrack/BuilderEnvironment/BuilderTools",
|
|
45
54
|
],
|
|
46
55
|
},
|
|
47
56
|
{
|
|
@@ -104,59 +113,13 @@ const sidebars = {
|
|
|
104
113
|
{
|
|
105
114
|
type: "category",
|
|
106
115
|
label: "Example usecases",
|
|
107
|
-
items: [
|
|
108
|
-
{
|
|
109
|
-
type: "category",
|
|
110
|
-
label: "Chatroom",
|
|
111
|
-
link: {
|
|
112
|
-
type: "generated-index",
|
|
113
|
-
description:
|
|
114
|
-
"Get started with the Chatroom tutorial: Jump into creating a new Powerhouse project if you have NodeJs, VSCode, and Git installed. We are going to create a new document model that represents a chat. So you as a user can post messages into that chat room, react to the messages. This chatroom will be synchronized between different connect instances. Let's explore the potential of the tools available in the powerhouse toolkit",
|
|
115
|
-
},
|
|
116
|
-
items: [
|
|
117
|
-
"academy/ExampleUsecases/Chatroom/CreateNewPowerhouseProject",
|
|
118
|
-
"academy/ExampleUsecases/Chatroom/DefineChatroomDocumentModel",
|
|
119
|
-
"academy/ExampleUsecases/Chatroom/ImplementOperationReducers",
|
|
120
|
-
"academy/ExampleUsecases/Chatroom/ImplementChatroomEditor",
|
|
121
|
-
"academy/ExampleUsecases/Chatroom/LaunchALocalReactor",
|
|
122
|
-
],
|
|
123
|
-
},
|
|
124
|
-
{
|
|
125
|
-
type: "category",
|
|
126
|
-
label: "Vetra Package Library",
|
|
127
|
-
link: {
|
|
128
|
-
type: "doc",
|
|
129
|
-
id: "academy/ExampleUsecases/VetraPackageLibrary/VetraPackageLibrary",
|
|
130
|
-
},
|
|
131
|
-
items: [],
|
|
132
|
-
},
|
|
133
|
-
{
|
|
134
|
-
type: "category",
|
|
135
|
-
label: "Todo List Tutorial",
|
|
136
|
-
link: {
|
|
137
|
-
type: "generated-index",
|
|
138
|
-
description:
|
|
139
|
-
"Build a complete Todo List application with Powerhouse: Learn how to create a document model, implement reducers, add tests, build a document editor UI, and create a drive explorer.",
|
|
140
|
-
},
|
|
141
|
-
items: [
|
|
142
|
-
"academy/ExampleUsecases/TodoList/GetTheStarterCode",
|
|
143
|
-
"academy/ExampleUsecases/TodoList/GenerateTodoListDocumentModel",
|
|
144
|
-
"academy/ExampleUsecases/TodoList/ImplementTodoListDocumentModelReducerOperationHandlers",
|
|
145
|
-
"academy/ExampleUsecases/TodoList/AddTestsForTodoListActions",
|
|
146
|
-
"academy/ExampleUsecases/TodoList/GenerateTodoListDocumentEditor",
|
|
147
|
-
"academy/ExampleUsecases/TodoList/ImplementTodoListDocumentEditorUIComponents",
|
|
148
|
-
"academy/ExampleUsecases/TodoList/GenerateTodoDriveExplorer",
|
|
149
|
-
"academy/ExampleUsecases/TodoList/AddSharedComponentForShowingTodoListStats",
|
|
150
|
-
],
|
|
151
|
-
},
|
|
152
|
-
],
|
|
116
|
+
items: [{ type: "autogenerated", dirName: "academy/03-ExampleUsecases" }],
|
|
153
117
|
},
|
|
154
118
|
{
|
|
155
119
|
type: "category",
|
|
156
120
|
label: "API References",
|
|
157
121
|
items: [
|
|
158
122
|
"academy/APIReferences/PowerhouseCLI",
|
|
159
|
-
"academy/APIReferences/VetraRemoteDrive",
|
|
160
123
|
"academy/APIReferences/ReactHooks",
|
|
161
124
|
"academy/APIReferences/RelationalDatabase",
|
|
162
125
|
"academy/APIReferences/PHDocumentMigrationGuide",
|
|
@@ -197,6 +160,7 @@ const sidebars = {
|
|
|
197
160
|
},
|
|
198
161
|
{ type: "doc", id: "academy/Cookbook", label: "Cookbook" },
|
|
199
162
|
{ type: "doc", id: "academy/Glossary", label: "Glossary" },
|
|
163
|
+
// ...add more as needed
|
|
200
164
|
],
|
|
201
165
|
};
|
|
202
166
|
|
package/src/css/custom.css
CHANGED
|
@@ -526,30 +526,22 @@ html[data-theme="dark"] .DocSearch-Hits > *:empty {
|
|
|
526
526
|
font-style: italic;
|
|
527
527
|
}
|
|
528
528
|
|
|
529
|
-
/*
|
|
530
|
-
.
|
|
531
|
-
|
|
532
|
-
|
|
533
|
-
|
|
534
|
-
|
|
535
|
-
|
|
529
|
+
/* Ethereum Argentina Hackathon sidebar icon */
|
|
530
|
+
.menu__link[href*="EthereumArgentinaHackathon"] {
|
|
531
|
+
display: flex !important;
|
|
532
|
+
align-items: center !important;
|
|
533
|
+
gap: 8px !important;
|
|
534
|
+
}
|
|
535
|
+
|
|
536
|
+
.menu__link[href*="EthereumArgentinaHackathon"]::before {
|
|
537
|
+
content: "" !important;
|
|
538
|
+
display: inline-block !important;
|
|
539
|
+
width: 24px !important;
|
|
540
|
+
height: 24px !important;
|
|
541
|
+
min-width: 24px !important;
|
|
542
|
+
background-image: url("/img/ethereum-logo.jpeg") !important;
|
|
543
|
+
background-size: cover !important;
|
|
544
|
+
background-position: center !important;
|
|
545
|
+
border-radius: 50% !important;
|
|
546
|
+
flex-shrink: 0 !important;
|
|
536
547
|
}
|
|
537
|
-
|
|
538
|
-
/* Code diff highlighting - Red for deletions */
|
|
539
|
-
.code-block-removed-line {
|
|
540
|
-
background-color: rgba(248, 81, 73, 0.15);
|
|
541
|
-
display: block;
|
|
542
|
-
margin: 0 calc(var(--ifm-pre-padding) * -1);
|
|
543
|
-
padding: 0 var(--ifm-pre-padding);
|
|
544
|
-
border-left: 3px solid #f85149;
|
|
545
|
-
}
|
|
546
|
-
|
|
547
|
-
/* Dark mode adjustments for diff highlighting */
|
|
548
|
-
[data-theme="dark"] .code-block-added-line {
|
|
549
|
-
background-color: rgba(46, 160, 67, 0.25);
|
|
550
|
-
}
|
|
551
|
-
|
|
552
|
-
[data-theme="dark"] .code-block-removed-line {
|
|
553
|
-
background-color: rgba(248, 81, 73, 0.25);
|
|
554
|
-
}
|
|
555
|
-
|