@powerhousedao/academy 5.1.0-dev.1 → 5.1.0-dev.10
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 +74 -0
- package/blog/BeyondCommunication-ABlueprintForDevelopment.md +2 -1
- package/blog/TheChallengeOfChange.md +1 -0
- package/docs/academy/01-GetStarted/00-ExploreDemoPackage.mdx +24 -27
- package/docs/academy/01-GetStarted/01-CreateNewPowerhouseProject.md +118 -9
- package/docs/academy/01-GetStarted/02-DefineToDoListDocumentModel.md +110 -28
- package/docs/academy/01-GetStarted/03-ImplementOperationReducers.md +191 -145
- package/docs/academy/01-GetStarted/04-WriteDocumentModelTests.md +378 -0
- package/docs/academy/01-GetStarted/05-BuildToDoListEditor.md +560 -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/{01-GetStarted → 02-MasteryTrack/01-BuilderEnvironment}/05-VetraStudio.md +48 -6
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/02-SpecifyTheStateSchema.md +75 -44
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/03-SpecifyDocumentOperations.md +28 -22
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/04-UseTheDocumentModelGenerator.md +28 -31
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/05-ImplementDocumentReducers.md +211 -206
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/06-ImplementDocumentModelTests.md +176 -62
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/07-ExampleToDoListRepository.md +21 -0
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/01-BuildingDocumentEditors.md +309 -319
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/00-DocumentToolbar.mdx +4 -0
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/01-OperationHistory.md +4 -0
- package/docs/academy/02-MasteryTrack/05-Launch/04-ConfigureEnvironment.md +1 -1
- package/docs/academy/03-ExampleUsecases/Chatroom/02-CreateNewPowerhouseProject.md +111 -35
- package/docs/academy/03-ExampleUsecases/Chatroom/03-DefineChatroomDocumentModel.md +255 -76
- package/docs/academy/03-ExampleUsecases/Chatroom/04-ImplementOperationReducers.md +281 -160
- package/docs/academy/03-ExampleUsecases/Chatroom/05-ImplementChatroomEditor.md +188 -35
- package/docs/academy/03-ExampleUsecases/Chatroom/06-LaunchALocalReactor.md +95 -7
- package/docs/academy/03-ExampleUsecases/Chatroom/_category_.json +1 -1
- package/docs/academy/03-ExampleUsecases/TodoList/00-GetTheStarterCode.md +24 -0
- package/docs/academy/03-ExampleUsecases/TodoList/01-GenerateTodoListDocumentModel.md +211 -0
- package/docs/academy/03-ExampleUsecases/TodoList/02-ImplementTodoListDocumentModelReducerOperationHandlers.md +171 -0
- package/docs/academy/03-ExampleUsecases/TodoList/03-AddTestsForTodoListActions.md +462 -0
- package/docs/academy/03-ExampleUsecases/TodoList/04-GenerateTodoListDocumentEditor.md +45 -0
- package/docs/academy/03-ExampleUsecases/TodoList/05-ImplementTodoListDocumentEditorUIComponents.md +422 -0
- package/docs/academy/03-ExampleUsecases/TodoList/06-GenerateTodoDriveExplorer.md +61 -0
- package/docs/academy/03-ExampleUsecases/TodoList/07-AddSharedComponentForShowingTodoListStats.md +384 -0
- package/docs/academy/03-ExampleUsecases/TodoList/_category_.json +8 -0
- package/docs/academy/03-ExampleUsecases/VetraPackageLibrary/VetraPackageLibrary.md +7 -0
- package/docs/academy/03-ExampleUsecases/VetraPackageLibrary/_category_.json +9 -0
- package/docs/academy/04-APIReferences/00-PowerhouseCLI.md +6 -2
- package/docs/academy/04-APIReferences/01-ReactHooks.md +2 -2
- package/docs/academy/04-APIReferences/06-VetraRemoteDrive.md +160 -0
- package/docs/academy/04-APIReferences/renown-sdk/00-Overview.md +316 -0
- package/docs/academy/04-APIReferences/renown-sdk/01-Authentication.md +672 -0
- package/docs/academy/04-APIReferences/renown-sdk/02-APIReference.md +957 -0
- package/docs/academy/04-APIReferences/renown-sdk/_category_.json +8 -0
- package/docs/academy/05-Architecture/00-PowerhouseArchitecture.md +7 -39
- package/docs/academy/06-ComponentLibrary/00-DocumentEngineering.md +72 -24
- package/docs/academy/08-Glossary.md +7 -0
- package/docs/academy/10-TodoListTutorial/02-ImplementTodoListDocumentModelReducerOperationHandlers.md +171 -0
- package/docs/academy/10-TodoListTutorial/03-AddTestsForTodoListActions.md +462 -0
- package/docs/academy/10-TodoListTutorial/05-ImplementTodoListDocumentEditorUIComponents.md +422 -0
- package/docs/academy/10-TodoListTutorial/07-AddSharedComponentForShowingTodoListStats.md +370 -0
- package/docusaurus.config.ts +28 -3
- package/package.json +1 -1
- package/sidebars.ts +49 -12
- package/src/css/custom.css +26 -18
- package/static/img/Vetra-logo-dark.svg +11 -0
- package/static/img/vetra-logo-light.svg +11 -0
- package/docs/academy/00-EthereumArgentinaHackathon.md +0 -207
- package/docs/academy/01-GetStarted/04-BuildToDoListEditor.md +0 -218
- package/docs/academy/01-GetStarted/06-ReactorMCP.md +0 -58
- package/docs/academy/05-Architecture/02-ReferencingMonorepoPackages +0 -65
- package/docs/academy/05-Architecture/04-MovingBeyondCRUD +0 -61
- /package/docs/academy/{01-GetStarted → 02-MasteryTrack/01-BuilderEnvironment}/images/Modules.png +0 -0
- /package/docs/academy/{01-GetStarted → 02-MasteryTrack/01-BuilderEnvironment}/images/VetraStudioDrive.png +0 -0
- /package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/{02-RevisionHistoryTimeline → 02-RevisionHistoryTimeline/360/237/232/247"} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{01-WhatIsADocumentModel → 360/237/232/247 /01-WhatIsADocumentModel"} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{02-DAOandDocumentsModelsQ+A → 360/237/232/247 /02-DAOandDocumentsModelsQ+A"} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{02-domain-modeling → 360/237/232/247 /02-domain-modeling"} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{03-BenefitsOfDocumentModels → 360/237/232/247 /03-BenefitsOfDocumentModels"} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{04-UtilitiesAndTips → 360/237/232/247 /04-UtilitiesAndTips"} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{05-best-practices → 360/237/232/247 /05-best-practices"} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{_category_.json → 360/237/232/247 /_category_.json"} +0 -0
- /package/docs/academy/05-Architecture/05-DocumentModelTheory/{three-data-layers.png → 360/237/232/247 /three-data-layers.png"} +0 -0
|
@@ -1,207 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
id: EthereumArgentinaHackathon
|
|
3
|
-
title: Ethereum Argentina Hackathon
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Ethereum Argentina Hackathon
|
|
7
|
-
|
|
8
|
-
**November 19-20, 2024**
|
|
9
|
-
|
|
10
|
-
Welcome to the Vetra hacker page for the Ethereum Argentina Hackathon! We're excited to support developers building with Powerhouse during this event.
|
|
11
|
-
|
|
12
|
-
## Overview
|
|
13
|
-
|
|
14
|
-
Join us for two days of intensive development support as you build decentralized applications using the Vetra framework. Our team will be available online and at the mentor's table to help you navigate the builder platform, answer questions, and guide you through best practices.
|
|
15
|
-
|
|
16
|
-
## 📅 Event Details
|
|
17
|
-
|
|
18
|
-
- **Dates**: November 19-20, 2024
|
|
19
|
-
- **Format**: Online & IRL Developer Support
|
|
20
|
-
- **Time Zone**: Argentina Time (ART)
|
|
21
|
-
- **Support Hours at Mentor Table @ la Rural**: Please get in touch [on Discord to schedule](https://discord.gg/pwQJwgaQKd)
|
|
22
|
-
- **Hackathon informations**: [Taiki Hackathon](https://taikai.network/ethargentina/hackathons/tierra-de-buidlers-2025/overview)
|
|
23
|
-
|
|
24
|
-
## 🚀 Getting Started
|
|
25
|
-
|
|
26
|
-
<details>
|
|
27
|
-
<summary> Vetra Introduction & Follow Along Demo </summary>
|
|
28
|
-
|
|
29
|
-
Please Rewatch our Hackathon introduction & follow along tutorial.
|
|
30
|
-
|
|
31
|
-
<iframe width="560" height="315" src="https://www.youtube.com/embed/R5MAaGaopJg" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
|
|
32
|
-
|
|
33
|
-
Find a complete overview of how to use the Vetra Studio for you project [here](./01-GetStarted/05-VetraStudio.md)
|
|
34
|
-
|
|
35
|
-
**Quick Start Summary**
|
|
36
|
-
|
|
37
|
-
- Step 1: Install the powerhouse-CLI: `pnpm install -g ph-cmd`
|
|
38
|
-
- Step 2: Initialize a project & directory `ph init my-project-name`
|
|
39
|
-
- Step 3: CD into you project directory
|
|
40
|
-
- Step 4: Launch Vetra Studio with the `ph vetra`command
|
|
41
|
-
- Step 5: Add the necessary document models & editors for your intended solution in Vetra Studio
|
|
42
|
-
- Step 6: If you're well versed in schema creation or graphql. Just talk with an agent about your imagined solution.
|
|
43
|
-
- Step 7: Start your preferred agent to help you with the initial scaffolding of your schema, operations and reducers.
|
|
44
|
-
- Step 8: Test your implementation in the "Vetra Preview Drive" with the `ph vetra --watch`command.
|
|
45
|
-
- Step 9: Run pnpm build and push your project to a remote repository. Follow the package publishing [Tutorial](./02-MasteryTrack/05-Launch/02-PublishYourProject.md)
|
|
46
|
-
|
|
47
|
-
**Basic tips**
|
|
48
|
-
- 1️⃣ Write a detailed description of your intented functionality inside the document model specification manifest
|
|
49
|
-
- 2️⃣ Ask your agent to ask for clarifying questions before starting any ideation process.
|
|
50
|
-
- 3️⃣ For each document model you'll want to create an accompanying editor in vetra studio.
|
|
51
|
-
- 4️⃣ An 'App' specifcation is an drive that can act as an app because of the specific interface you create for it.
|
|
52
|
-
|
|
53
|
-
### Before the Hackathon
|
|
54
|
-
|
|
55
|
-
1. **Set Up Your Environment**
|
|
56
|
-
- Install the Powerhouse CLI
|
|
57
|
-
- Set up your development environment
|
|
58
|
-
- Review the [Get Started Guide](./01-GetStarted/home.mdx)
|
|
59
|
-
|
|
60
|
-
2. **Explore the Platform**
|
|
61
|
-
- Check out the [Demo Package](./01-GetStarted/00-ExploreDemoPackage.mdx)
|
|
62
|
-
- Familiarize yourself with [Document Models](./02-MasteryTrack/02-DocumentModelCreation/01-WhatIsADocumentModel.md)
|
|
63
|
-
|
|
64
|
-
3. **Join Our Community**
|
|
65
|
-
- Discord: [Join our server](#)
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
</details>
|
|
69
|
-
|
|
70
|
-
:::tip Use your preferred AI agent
|
|
71
|
-
Vetra studio is compatible with Cursor, Claude and Gemini. Find the dedicated markdown files to guide your agent with the correct instruction in your directory. Your agent should also have access to the MCP's available.
|
|
72
|
-
:::
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
## **Hackathon Project Ideas**
|
|
76
|
-
|
|
77
|
-
Powerhouse is perfect for building:
|
|
78
|
-
|
|
79
|
-
- **Real World Use-cases**: Every document can act as a mini ledger/blockchain.
|
|
80
|
-
- **Decentralized Applications**: Create apps with built-in version control and collaboration.
|
|
81
|
-
- **Document-Based Systems**: Build structured data applications.
|
|
82
|
-
- **Collaborative Tools**: Enable real-time multi-user editing.
|
|
83
|
-
- **Data Management Platforms**: Create systems with queryable, structured data.
|
|
84
|
-
|
|
85
|
-
### Coordination & DAO Design
|
|
86
|
-
|
|
87
|
-
- 🧩 **What if** DAOs weren't chaotic? What documents would you need to make them coordinate like space X and ship like stripe?
|
|
88
|
-
- 🎯 **What if** making decisions as a group felt like playing a co-op strategy game. With a clearly aligned vision, instant dashboards and a way to capture hard won knowledge in expertise into custom software for the Dao?
|
|
89
|
-
|
|
90
|
-
:::tip IDEA
|
|
91
|
-
The ultimate DAO Template toolkit where vision & mission documents influence guidelines & onboarding for contributors.
|
|
92
|
-
:::
|
|
93
|
-
|
|
94
|
-
---
|
|
95
|
-
|
|
96
|
-
### GovTech & Public Infrastructure
|
|
97
|
-
|
|
98
|
-
- 🗳 **What if** local governments had to reach consensus with residents before making a decision? How would that look like?
|
|
99
|
-
- 🚧 **What if** you could submit pothole fixes or transit complaints into a civic DAO, and track the response like GitHub issues?
|
|
100
|
-
- 🧾 **What if** municipal budgets were editable public documents with community feedback loops?
|
|
101
|
-
|
|
102
|
-
:::tip IDEA
|
|
103
|
-
An Open Source Enterprise Resource Planning-suite for municipalities & governments
|
|
104
|
-
:::
|
|
105
|
-
|
|
106
|
-
---
|
|
107
|
-
|
|
108
|
-
### Education & Group Work
|
|
109
|
-
|
|
110
|
-
- 📝 **What if** your group project auto-divided work, tracked contributions, and paid out in real-time?
|
|
111
|
-
- 👾 **What if** "homework" was a multiplayer quest, and grades came from the DAO?
|
|
112
|
-
- 🏫 **What if** we DAO-ified a classroom and let the students vote on rules, roles, and rewards?
|
|
113
|
-
|
|
114
|
-
:::tip IDEA
|
|
115
|
-
The remote classroom SAAS back-end that fosters connection, gives purpose to bullies and empowers younger generation to dream big again.
|
|
116
|
-
:::
|
|
117
|
-
|
|
118
|
-
---
|
|
119
|
-
|
|
120
|
-
### 💸 Grants, Crypto, and Incentive Design
|
|
121
|
-
|
|
122
|
-
- 💰 **What if** grant tooling felt like bounty hunting across a galaxy of projects?
|
|
123
|
-
- 📊 **What if** every grant had a live budget dashboard, contributor feed, and impact score?
|
|
124
|
-
- 🎮 **What if** you could stake on coordination itself, betting that people will work together well?
|
|
125
|
-
|
|
126
|
-
:::tip IDEA
|
|
127
|
-
The future of grant platforms that dares to imagine grants in new ways. With follow up, tracking and impact visualisations of teams, time, risk & resources invested.
|
|
128
|
-
:::
|
|
129
|
-
|
|
130
|
-
---
|
|
131
|
-
|
|
132
|
-
### 💸 Lawmaking, Legislation & Legal
|
|
133
|
-
|
|
134
|
-
- 🧑⚖️ **What if** any government or DAO could fork a legal template, customize it, and track changes in a public, composable way?
|
|
135
|
-
- 🎨 **What if** legislation could be transparently co-created by citizens, NGOs, and governments all with aligned incentives?
|
|
136
|
-
- 💻 **What if** legislation, contracts & templates could exist on an open-source market place like software?
|
|
137
|
-
- 🤖 **What if** a network agent could create a legal vehicle by simply inputing set of requirements and risk preferences (in non legalese)?
|
|
138
|
-
- 🤝 **What if** 2 agents in a network could negotiate terms of an agreement according to predefined functions and risk parameters, without lawyers?
|
|
139
|
-
|
|
140
|
-
:::tip IDEA
|
|
141
|
-
Build a Decentralized Lawmaking Engine using Reactive Document Models
|
|
142
|
-
:::
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
## 🛠️ Resources
|
|
146
|
-
|
|
147
|
-
### Documentation
|
|
148
|
-
|
|
149
|
-
- [Quick Start Guide](./01-GetStarted/home.mdx)
|
|
150
|
-
- [Create a New Project](./01-GetStarted/01-CreateNewPowerhouseProject.md)
|
|
151
|
-
- [Define Document Models](./01-GetStarted/02-DefineToDoListDocumentModel.md)
|
|
152
|
-
- [Build Editors](./01-GetStarted/04-BuildToDoListEditor.md)
|
|
153
|
-
- [API References](./04-APIReferences/00-PowerhouseCLI.md)
|
|
154
|
-
|
|
155
|
-
### Tutorials
|
|
156
|
-
|
|
157
|
-
- [To-Do List Example](./01-GetStarted/02-DefineToDoListDocumentModel.md)
|
|
158
|
-
- [Chatroom Use Case](./03-ExampleUsecases/Chatroom/02-CreateNewPowerhouseProject.md)
|
|
159
|
-
|
|
160
|
-
## 🏆 Judging Criteria
|
|
161
|
-
|
|
162
|
-
Projects will be evaluated based on:
|
|
163
|
-
|
|
164
|
-
- **Usefulness & Impact**: How well does it solve a certain job or problem?
|
|
165
|
-
- **Composability/Structure**: How are the different document models and / or drive apps collaborating?
|
|
166
|
-
- **Clarity of the developer or user experience**: Did you unlock the secret sauce of UX & reactive documents?
|
|
167
|
-
- **Alignment with Vetra/Powerhouse principles**: Local-first, auditable, usefull for common good.
|
|
168
|
-
|
|
169
|
-
## 📋 Submission Guidelines
|
|
170
|
-
|
|
171
|
-
### What to Submit
|
|
172
|
-
|
|
173
|
-
- GitHub repository with your code
|
|
174
|
-
- (Video) presentation (2-3 minutes)
|
|
175
|
-
- README with:
|
|
176
|
-
- Project description
|
|
177
|
-
- Setup instructions
|
|
178
|
-
- Screenshots/demos
|
|
179
|
-
- Technologies used
|
|
180
|
-
|
|
181
|
-
The Powerhouse team will add you as a builder on the Vetra platform and host your application and drive.
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
## Tips for Success
|
|
185
|
-
|
|
186
|
-
### Development Tips
|
|
187
|
-
|
|
188
|
-
1. **Start Simple**: Begin with a basic implementation and iterate
|
|
189
|
-
2. **Use Templates**: Leverage existing examples and templates
|
|
190
|
-
3. **Ask Questions**: Don't hesitate to reach out for help
|
|
191
|
-
4. **Test Early**: Test your application frequently during development
|
|
192
|
-
5. **Document**: Keep notes on your decisions and implementations
|
|
193
|
-
|
|
194
|
-
### Presentation Tips
|
|
195
|
-
|
|
196
|
-
1. **Show, Don't Tell**: Live demos are more impactful than slides
|
|
197
|
-
2. **Tell a Story**: Explain the problem you're solving
|
|
198
|
-
3. **Highlight Innovation**: Show what makes your solution unique
|
|
199
|
-
4. **Be Concise**: Respect the time limits for presentations
|
|
200
|
-
5. **Prepare Backup**: Have screenshots/video in case of technical issues
|
|
201
|
-
|
|
202
|
-
---
|
|
203
|
-
|
|
204
|
-
**Good luck, and happy hacking! 🚀**
|
|
205
|
-
|
|
206
|
-
*Last updated: November 17, 2025*
|
|
207
|
-
|
|
@@ -1,218 +0,0 @@
|
|
|
1
|
-
# Build a to-do list editor
|
|
2
|
-
|
|
3
|
-
In this chapter we will continue with the interface or editor implementation of the **To-do List** document model. This means you will create a simple user interface for the **To-do List** document model which will be used inside the Connect app to create, update and delete your ToDoList items.
|
|
4
|
-
|
|
5
|
-
## Generate the editor template
|
|
6
|
-
|
|
7
|
-
Run the command below to generate the editor template for the **To-do List** document model.
|
|
8
|
-
This command reads the **To-do List** document model definition from the `document-models` folder and generates the editor template in the `editors/to-do-list` folder as `editor.tsx`.
|
|
9
|
-
|
|
10
|
-
Notice the `--editor` flag which specifies the **To-do List** document model, and the `--document-types` flag defines the document type `powerhouse/todolist`.
|
|
11
|
-
|
|
12
|
-
```bash
|
|
13
|
-
ph generate --editor ToDoList --document-types powerhouse/todolist
|
|
14
|
-
```
|
|
15
|
-
|
|
16
|
-
Once complete, navigate to the `editors/to-do-list/editor.tsx` file and open it in your editor.
|
|
17
|
-
|
|
18
|
-
### Editor implementation options
|
|
19
|
-
|
|
20
|
-
When building your editor component within the Powerhouse ecosystem, you have several options for styling, allowing you to leverage your preferred methods:
|
|
21
|
-
|
|
22
|
-
1. **Default HTML Styling:** Standard HTML tags (`<h1>`, `<p>`, `<button>`, etc.) will render with default styles offered through the boilerplate.
|
|
23
|
-
2. **Tailwind CSS:** Connect Studio comes with Tailwind CSS integrated. You can directly use Tailwind utility classes for rapid, consistent styling without writing separate CSS files.
|
|
24
|
-
3. **Custom CSS Files:** You can import traditional CSS files (`.css`) to apply custom styles or integrate existing style libraries.
|
|
25
|
-
|
|
26
|
-
Connect Studio provides a dynamic local environment, by running `ph connect` to visualize your components instantly as you build them, regardless of the styling method you choose.
|
|
27
|
-
Manual build steps are typically only needed when publishing packages.
|
|
28
|
-
|
|
29
|
-
## To-do List editor
|
|
30
|
-
|
|
31
|
-
Below is the complete code for the To-Do List editor. Paste this code in `editors/to-do-list/editor.tsx`.
|
|
32
|
-
|
|
33
|
-
<details>
|
|
34
|
-
<summary>Complete ToDoList Editor Example (using Tailwind CSS)</summary>
|
|
35
|
-
|
|
36
|
-
```typescript
|
|
37
|
-
import { EditorProps } from 'document-model';
|
|
38
|
-
import {
|
|
39
|
-
ToDoListState,
|
|
40
|
-
ToDoListAction,
|
|
41
|
-
ToDoListLocalState,
|
|
42
|
-
ToDoItem,
|
|
43
|
-
actions,
|
|
44
|
-
ToDoListDocument,
|
|
45
|
-
} from '../../document-models/to-do-list/index.js';
|
|
46
|
-
import { useState } from 'react';
|
|
47
|
-
|
|
48
|
-
// EditorProps is a generic type that provides the document and a dispatch function.
|
|
49
|
-
// The dispatch function is used to send actions to the document's reducer to update the state.
|
|
50
|
-
export type IProps = EditorProps<ToDoListDocument>;
|
|
51
|
-
|
|
52
|
-
export default function Editor(props: IProps) {
|
|
53
|
-
// Destructure document and dispatch from props.
|
|
54
|
-
const { document, dispatch } = props;
|
|
55
|
-
// Get the global state from the document. This state is shared across all editors of this document.
|
|
56
|
-
const {
|
|
57
|
-
state: { global: state },
|
|
58
|
-
} = document;
|
|
59
|
-
|
|
60
|
-
// React's useState hook is used for local component state.
|
|
61
|
-
// This state is not shared with other components.
|
|
62
|
-
// `todoItem` stores the text of the new to-do item being added.
|
|
63
|
-
const [todoItem, setTodoItem] = useState('');
|
|
64
|
-
// `editingItemId` stores the ID of the item currently being edited.
|
|
65
|
-
const [editingItemId, setEditingItemId] = useState<string | null>(null);
|
|
66
|
-
// `editedText` stores the text of the item while it's being edited.
|
|
67
|
-
const [editedText, setEditedText] = useState('');
|
|
68
|
-
|
|
69
|
-
return (
|
|
70
|
-
<div className="p-4 font-sans max-w-lg mx-auto">
|
|
71
|
-
<h1 className="text-2xl font-bold mb-4 text-center">To-do List</h1>
|
|
72
|
-
<div className="w-96 mx-auto">
|
|
73
|
-
<div className="flex mb-4">
|
|
74
|
-
<input
|
|
75
|
-
className="border border-gray-300 p-2 rounded-l-md flex-grow"
|
|
76
|
-
placeholder="Insert task here..."
|
|
77
|
-
value={todoItem}
|
|
78
|
-
onChange={e => setTodoItem(e.target.value)}
|
|
79
|
-
onKeyDown={e => {
|
|
80
|
-
if (e.key === 'Enter') {
|
|
81
|
-
// Dispatch an action to add a new to-do item.
|
|
82
|
-
// `actions.addTodoItem` is an action creator from our document model.
|
|
83
|
-
dispatch(
|
|
84
|
-
actions.addTodoItem({
|
|
85
|
-
id: Math.random().toString(), // In a real app, use a more robust ID generation.
|
|
86
|
-
text: todoItem,
|
|
87
|
-
})
|
|
88
|
-
);
|
|
89
|
-
setTodoItem('');
|
|
90
|
-
}
|
|
91
|
-
}}
|
|
92
|
-
/>
|
|
93
|
-
<button
|
|
94
|
-
className="bg-blue-500 hover:bg-blue-600 text-white p-2 rounded-r-md"
|
|
95
|
-
onClick={() => {
|
|
96
|
-
// Also add item on button click.
|
|
97
|
-
dispatch(
|
|
98
|
-
actions.addTodoItem({
|
|
99
|
-
id: Math.random().toString(),
|
|
100
|
-
text: todoItem,
|
|
101
|
-
})
|
|
102
|
-
);
|
|
103
|
-
setTodoItem('');
|
|
104
|
-
}}
|
|
105
|
-
>
|
|
106
|
-
Add
|
|
107
|
-
</button>
|
|
108
|
-
</div>
|
|
109
|
-
<ul className="list-none p-0">
|
|
110
|
-
{/* Map over the items in the global state to render each to-do item. */}
|
|
111
|
-
{state.items.map((item: ToDoItem) => (
|
|
112
|
-
<li
|
|
113
|
-
key={item.id}
|
|
114
|
-
className="flex items-center p-2 relative border-b border-gray-200"
|
|
115
|
-
>
|
|
116
|
-
<input
|
|
117
|
-
type="checkbox"
|
|
118
|
-
checked={item.checked}
|
|
119
|
-
className="mr-3"
|
|
120
|
-
onChange={() => {
|
|
121
|
-
// Dispatch an action to update the checked status of an item.
|
|
122
|
-
dispatch(
|
|
123
|
-
actions.updateTodoItem({
|
|
124
|
-
id: item.id,
|
|
125
|
-
checked: !item.checked,
|
|
126
|
-
})
|
|
127
|
-
);
|
|
128
|
-
}}
|
|
129
|
-
/>
|
|
130
|
-
{/* Conditional rendering: show an input field if the item is being edited, otherwise show the text. */}
|
|
131
|
-
{editingItemId === item.id ? (
|
|
132
|
-
<input
|
|
133
|
-
value={editedText}
|
|
134
|
-
onChange={e =>
|
|
135
|
-
setEditedText(e.target.value)
|
|
136
|
-
}
|
|
137
|
-
onKeyDown={e => {
|
|
138
|
-
if (e.key === 'Enter') {
|
|
139
|
-
// Dispatch an action to update the item's text.
|
|
140
|
-
dispatch(
|
|
141
|
-
actions.updateTodoItem({
|
|
142
|
-
id: item.id,
|
|
143
|
-
text: editedText,
|
|
144
|
-
})
|
|
145
|
-
);
|
|
146
|
-
// Exit editing mode.
|
|
147
|
-
setEditingItemId(null);
|
|
148
|
-
}
|
|
149
|
-
}}
|
|
150
|
-
className="flex-grow"
|
|
151
|
-
autoFocus // Automatically focus the input when it appears.
|
|
152
|
-
/>
|
|
153
|
-
) : (
|
|
154
|
-
<div className="flex items-center flex-grow gap-1">
|
|
155
|
-
<span
|
|
156
|
-
onClick={() => {
|
|
157
|
-
// Enter editing mode when the text is clicked.
|
|
158
|
-
setEditingItemId(item.id);
|
|
159
|
-
setEditedText(item.text);
|
|
160
|
-
}}
|
|
161
|
-
className={`cursor-pointer ${
|
|
162
|
-
item.checked
|
|
163
|
-
? 'line-through text-gray-500'
|
|
164
|
-
: ''
|
|
165
|
-
}`}
|
|
166
|
-
>
|
|
167
|
-
{item.text}
|
|
168
|
-
</span>
|
|
169
|
-
<span
|
|
170
|
-
onClick={() =>
|
|
171
|
-
dispatch(
|
|
172
|
-
actions.deleteTodoItem({
|
|
173
|
-
id: item.id,
|
|
174
|
-
})
|
|
175
|
-
)
|
|
176
|
-
}
|
|
177
|
-
className="text-gray-400 cursor-pointer opacity-40 transition-all duration-200 text-base font-bold inline-flex items-center pl-1 hover:opacity-100 hover:text-red-500"
|
|
178
|
-
>
|
|
179
|
-
×
|
|
180
|
-
</span>
|
|
181
|
-
</div>
|
|
182
|
-
)}
|
|
183
|
-
</li>
|
|
184
|
-
))}
|
|
185
|
-
</ul>
|
|
186
|
-
</div>
|
|
187
|
-
</div>
|
|
188
|
-
);
|
|
189
|
-
}
|
|
190
|
-
```
|
|
191
|
-
|
|
192
|
-
</details>
|
|
193
|
-
|
|
194
|
-
Now you can run the Connect app and see the **To-do List** editor in action.
|
|
195
|
-
|
|
196
|
-
```bash
|
|
197
|
-
ph connect
|
|
198
|
-
```
|
|
199
|
-
|
|
200
|
-
In Connect, in the bottom right corner you'll find a new Document Model that you can create: **To-do List**.
|
|
201
|
-
Click on it to create a new To-do List document.
|
|
202
|
-
|
|
203
|
-
:::info
|
|
204
|
-
The editor will update dynamically, so you can play around with your editor styling while seeing your results appear in Connect Studio.
|
|
205
|
-
:::
|
|
206
|
-
|
|
207
|
-
Congratulations!
|
|
208
|
-
If you managed to follow this tutorial until this point, you have successfully implemented the **To-do List** document model with its reducer operations and editor.
|
|
209
|
-
|
|
210
|
-
### Up next: Mastery Track
|
|
211
|
-
|
|
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 To-do List.
|
|
213
|
-
|
|
214
|
-
You will learn:
|
|
215
|
-
|
|
216
|
-
- The in's & out's of a document model.
|
|
217
|
-
- How to use UI & Scalar components from the Document Engineering system.
|
|
218
|
-
- How to build Custom Drive Apps or Drive Explorers.
|
|
@@ -1,58 +0,0 @@
|
|
|
1
|
-
# Tool: Reactor MCP
|
|
2
|
-
|
|
3
|
-
**Reactor-mcp** is a Model Context Protocol (MCP) server for the Powerhouse ecosystem that provides AI agents and tools with structured access to document model operations.
|
|
4
|
-
It serves as a bridge between AI systems and the Powerhouse document management infrastructure.
|
|
5
|
-
|
|
6
|
-
## Main Functions of the Reactor-mcp
|
|
7
|
-
|
|
8
|
-
**Document Operations**:
|
|
9
|
-
- createDocument - Create new documents
|
|
10
|
-
- getDocument - Retrieve documents by ID
|
|
11
|
-
- addActions - Add actions to modify document state
|
|
12
|
-
- deleteDocument - Remove documents
|
|
13
|
-
|
|
14
|
-
**Drive Operations**:
|
|
15
|
-
- getDrives - List all document drives
|
|
16
|
-
- addDrive - Create new drives
|
|
17
|
-
- getDrive - Retrieve specific drives
|
|
18
|
-
- addRemoteDrive - Connect to remote drives
|
|
19
|
-
|
|
20
|
-
**Document Model Operations**:
|
|
21
|
-
- getDocumentModels - List available document model types
|
|
22
|
-
- getDocumentModelSchema - Get schema for specific document models
|
|
23
|
-
|
|
24
|
-
<details>
|
|
25
|
-
<summary>Architecture Context</summary>
|
|
26
|
-
|
|
27
|
-
Within the broader Powerhouse ecosystem:
|
|
28
|
-
|
|
29
|
-
- Document Model: Defines structure and operations for document types
|
|
30
|
-
- Document Drive: Manages collections of documents with sync capabilities
|
|
31
|
-
- Reactor-MCP: Provides AI/tool access to document operations
|
|
32
|
-
- Connect/Switchboard: User interfaces and synchronization servers
|
|
33
|
-
|
|
34
|
-
The reactor-mcp essentially makes the sophisticated document model system accessible to AI agents and external tools through a standardized protocol, enabling programmatic document creation, modification, and management within the Powerhouse ecosystem.
|
|
35
|
-
|
|
36
|
-
</details>
|
|
37
|
-
|
|
38
|
-
### Document Model Agent
|
|
39
|
-
|
|
40
|
-
Alongside the MCP is a **specialized AI agent** for document model creation:
|
|
41
|
-
|
|
42
|
-
- Purpose: Guide users through creating document models
|
|
43
|
-
- Workflow: Requirements gathering → Design confirmation → Implementation
|
|
44
|
-
- Tools: Comprehensive set of MCP tools for model management
|
|
45
|
-
- Capabilities:
|
|
46
|
-
- State schema definition
|
|
47
|
-
- Operation creation
|
|
48
|
-
- Module organization
|
|
49
|
-
- Code generation
|
|
50
|
-
|
|
51
|
-
:::tip Supports with:
|
|
52
|
-
|
|
53
|
-
1. **AI-Assisted Document Model Creation**: AI agents can use the MCP tools to help users create and modify document models
|
|
54
|
-
2. **Automated Document Management**: Programmatic creation and management of documents and drives
|
|
55
|
-
3. **Integration with AI Tools**: Claude, GPT, or other AI systems can use this as an MCP server to interact with Powerhouse
|
|
56
|
-
4. **Development Tooling**: CLI and development server for working with document models locally
|
|
57
|
-
:::
|
|
58
|
-
|
|
@@ -1,65 +0,0 @@
|
|
|
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
|
-
|
|
@@ -1,61 +0,0 @@
|
|
|
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
|
-
|
/package/docs/academy/{01-GetStarted → 02-MasteryTrack/01-BuilderEnvironment}/images/Modules.png
RENAMED
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|