@powerhousedao/academy 2.5.0-dev.3 → 2.5.0-dev.30
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 +187 -0
- package/docs/academy/01-GetStarted/00-ExploreDemoPackage.md +19 -15
- package/docs/academy/01-GetStarted/01-CreateNewPowerhouseProject.md +38 -39
- package/docs/academy/01-GetStarted/02-DefineToDoListDocumentModel.md +22 -7
- package/docs/academy/01-GetStarted/03-ImplementOperationReducers.md +9 -4
- package/docs/academy/01-GetStarted/04-BuildToDoListEditor.md +146 -422
- package/docs/academy/01-GetStarted/_04-BuildToDoListEditor +360 -0
- package/docs/academy/01-GetStarted/home.mdx +16 -24
- package/docs/academy/01-GetStarted/styles.module.css +31 -0
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/02-StandardDocumentModelWorkflow.md +7 -3
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/03-BuilderTools.md +1 -1
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/01-WhatIsADocumentModel.md +33 -16
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/02-SpecifyTheStateSchema.md +73 -0
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/03-SpecifyDocumentOperations.md +59 -4
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/04-UseTheDocumentModelGenerator.md +32 -12
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/05-ImplementDocumentReducers.md +103 -38
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/06-ImplementDocumentModelTests.md +90 -228
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/07-ExampleToDoListRepository.md +41 -1
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/01-BuildingDocumentEditors.md +342 -67
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/02-ConfiguringDrives.md +5 -3
- package/docs/academy/02-MasteryTrack/05-Launch/02-PublishYourProject.md +70 -5
- package/docs/academy/02-MasteryTrack/05-Launch/03-SetupEnvironment.md +162 -73
- package/docs/academy/02-MasteryTrack/05-Launch/{03-RunOnACloudServer.md → _03-RunOnACloudServer} +8 -5
- package/docs/academy/04-APIReferences/00-PowerhouseCLI.md +7 -40
- package/docs/academy/05-Architecture/00-PowerhouseArchitecture.md +3 -0
- package/docs/academy/05-Architecture/images/PowerhouseArchitecture.png +0 -0
- package/docs/academy/06-ComponentLibrary/00-DocumentEngineering.md +86 -29
- package/docs/academy/06-ComponentLibrary/02-CreateCustomScalars.md +404 -0
- package/docs/academy/06-ComponentLibrary/03-IntegrateIntoAReactComponent.md +124 -0
- package/docs/academy/07-Cookbook.md +209 -4
- package/docs/academy/08-Glossary.md +20 -18
- package/docs/academy/09-AIResources +131 -0
- package/package.json +1 -1
- package/sidebars.ts +3 -45
- package/docs/academy/06-ComponentLibrary/02-BuildingWithScalars.md +0 -54
- package/docs/academy/06-ComponentLibrary/03-Scalar-Components/01-phid-field.mdx +0 -72
- package/docs/academy/06-ComponentLibrary/03-Scalar-Components/02-input-field.mdx +0 -0
- package/docs/academy/06-ComponentLibrary/04-Complex-Components/01-sidebar.mdx +0 -36
- package/docs/academy/06-ComponentLibrary/05-Layout-Components/01-test-toupdate.mdx +0 -61
- package/docs/academy/06-ComponentLibrary/06-Fragments/01-test-toupdate.mdx +0 -61
- /package/docs/academy/02-MasteryTrack/05-Launch/{02-IntroductionToPackages.md → 01-IntroductionToPackages.md} +0 -0
- /package/docs/academy/02-MasteryTrack/05-Launch/{00-IntegrateInAFront-End → _00-IntegrateInAFront-End} +0 -0
- /package/docs/academy/02-MasteryTrack/05-Launch/{01-IntroducingFusion → _01-IntroducingFusion} +0 -0
- /package/docs/academy/02-MasteryTrack/05-Launch/{04-GraphQLNamespacing → _04-GraphQLNamespacing} +0 -0
- /package/docs/academy/02-MasteryTrack/05-Launch/{05-LaunchYourBackend.md → _05-LaunchYourBackend} +0 -0
- /package/docs/academy/02-MasteryTrack/05-Launch/{06-LaunchYourFrontend.md → _06-LaunchYourFrontend} +0 -0
- /package/docs/academy/04-APIReferences/{01-ReactHooks.md → 01-ReactHooks} +0 -0
- /package/docs/academy/04-APIReferences/{02-ReactorAPI.md → 02-ReactorAPI} +0 -0
- /package/docs/academy/04-APIReferences/{03-Configuration.md → 03-Configuration} +0 -0
|
@@ -337,6 +337,75 @@ ph init --package-manager pnpm
|
|
|
337
337
|
- [Bun Installation Guide](https://bun.sh/docs/installation#how-to-add-your-path)
|
|
338
338
|
</details>
|
|
339
339
|
|
|
340
|
+
## Powerhouse Environment Recipes
|
|
341
|
+
This section covers recipes for setting up and managing Powerhouse environments, from local development to production servers.
|
|
342
|
+
|
|
343
|
+
<details id="setting-up-a-production-environment">
|
|
344
|
+
<summary>Setting up a Production Environment</summary>
|
|
345
|
+
|
|
346
|
+
## How to Set Up a Production Powerhouse Environment
|
|
347
|
+
---
|
|
348
|
+
|
|
349
|
+
## Problem Statement
|
|
350
|
+
You need to set up a new production-ready server to host and run your Powerhouse services (Connect and Switchboard).
|
|
351
|
+
|
|
352
|
+
## Prerequisites
|
|
353
|
+
- A Linux-based server (Ubuntu or Debian recommended) with `sudo` privileges.
|
|
354
|
+
- A registered domain name.
|
|
355
|
+
- DNS `A` records for your `connect` and `switchboard` subdomains pointing to your server's public IP address.
|
|
356
|
+
|
|
357
|
+
## Solution
|
|
358
|
+
|
|
359
|
+
### Step 1: Install Powerhouse Services
|
|
360
|
+
SSH into your server and run the universal installation script. This will install Node.js, pnpm, and prepare the system for Powerhouse services.
|
|
361
|
+
```bash
|
|
362
|
+
curl -fsSL https://apps.powerhouse.io/install | bash
|
|
363
|
+
```
|
|
364
|
+
|
|
365
|
+
### Step 2: Reload Your Shell
|
|
366
|
+
After the installation, reload your shell's configuration to recognize the new commands.
|
|
367
|
+
```bash
|
|
368
|
+
source ~/.bashrc # Or source ~/.zshrc if using zsh
|
|
369
|
+
```
|
|
370
|
+
|
|
371
|
+
### Step 3: Initialize a Project
|
|
372
|
+
Create a project directory for your services. The `ph-init` command sets up the basic structure. Move into the directory after creation.
|
|
373
|
+
```bash
|
|
374
|
+
ph-init my-powerhouse-services
|
|
375
|
+
cd my-powerhouse-services
|
|
376
|
+
```
|
|
377
|
+
|
|
378
|
+
### Step 4: Configure Services
|
|
379
|
+
Run the interactive setup command. This will guide you through configuring Nginx, PM2, databases, and SSL.
|
|
380
|
+
```bash
|
|
381
|
+
ph service setup
|
|
382
|
+
```
|
|
383
|
+
During the setup, you will be prompted for:
|
|
384
|
+
- **Packages to install:** You can pre-install any Powerhouse packages you need. (Optional)
|
|
385
|
+
- **Database:** Choose between a local PostgreSQL setup or connecting to a remote database.
|
|
386
|
+
- **SSL Certificate:** Select Let's Encrypt for a production setup. You will need to provide your domain and subdomains.
|
|
387
|
+
|
|
388
|
+
## Expected Outcome
|
|
389
|
+
- Powerhouse Connect and Switchboard services are installed, configured, and running on your server.
|
|
390
|
+
- Nginx is set up as a reverse proxy with SSL certificates from Let's Encrypt.
|
|
391
|
+
- Services are managed by PM2 and will restart automatically on boot or if they crash.
|
|
392
|
+
- You can access your services securely at `https://connect.yourdomain.com` and `https://switchboard.yourdomain.com`.
|
|
393
|
+
|
|
394
|
+
## Common Issues and Solutions
|
|
395
|
+
- **Issue:** `ph: command not found`
|
|
396
|
+
- **Solution:** Ensure you have reloaded your shell with `source ~/.bashrc` or have restarted your terminal session.
|
|
397
|
+
- **Issue:** Let's Encrypt SSL certificate creation fails.
|
|
398
|
+
- **Solution:** Verify that your domain's DNS records have fully propagated and are pointing to the correct server IP. This can take some time.
|
|
399
|
+
- **Issue:** Services fail to start.
|
|
400
|
+
- **Solution:** Check the service logs for errors using `ph service logs` or `pm2 logs`.
|
|
401
|
+
|
|
402
|
+
## Related Recipes
|
|
403
|
+
- [Installing a Custom Powerhouse Package](#installing-a-custom-powerhouse-package)
|
|
404
|
+
|
|
405
|
+
## Further Reading
|
|
406
|
+
- [Full Setup Guide](/academy/MasteryTrack/Launch/SetupEnvironment)
|
|
407
|
+
</details>
|
|
408
|
+
|
|
340
409
|
## Powerhouse Project Recipes
|
|
341
410
|
This section focuses on creating, configuring, and managing Powerhouse projects, which are collections of document models, editors, and other resources.
|
|
342
411
|
|
|
@@ -404,7 +473,6 @@ In the "New Document" section at the bottom of the page, click the `DocumentMode
|
|
|
404
473
|
- Implementing Document Model Reducers (Details to be added)
|
|
405
474
|
|
|
406
475
|
## Further Reading
|
|
407
|
-
- [Domain Modeling Guide](/domain-modeling)
|
|
408
476
|
- [GraphQL Schema Best Practices](/academy/MasteryTrack/WorkWithData/GraphQLAtPowerhouse)
|
|
409
477
|
</details>
|
|
410
478
|
|
|
@@ -451,9 +519,6 @@ The command will output the generated reducer scaffolding code in the designated
|
|
|
451
519
|
- [Initializing a New Project & Document Model](#initializing-a-new-project-and-document-model)
|
|
452
520
|
- Generating a Document Editor
|
|
453
521
|
|
|
454
|
-
## Further Reading
|
|
455
|
-
- [Domain Modeling Guide](/domain-modeling)
|
|
456
|
-
|
|
457
522
|
</details>
|
|
458
523
|
|
|
459
524
|
<details id="updating-your-powerhouse-project-dependencies">
|
|
@@ -927,6 +992,80 @@ You need to understand and manage different types of dependencies in your Powerh
|
|
|
927
992
|
|
|
928
993
|
</details>
|
|
929
994
|
|
|
995
|
+
<details id="packaging-and-publishing-a-powerhouse-project">
|
|
996
|
+
<summary>Packaging and Publishing a Powerhouse Project</summary>
|
|
997
|
+
|
|
998
|
+
## How to Package and Publish a Powerhouse Project
|
|
999
|
+
---
|
|
1000
|
+
|
|
1001
|
+
## Problem Statement
|
|
1002
|
+
You have created a collection of document models, editors, or other components and want to share it as a reusable package on a public or private npm registry. Publishing a package allows other projects to install and use your creations easily.
|
|
1003
|
+
|
|
1004
|
+
## Prerequisites
|
|
1005
|
+
- A completed Powerhouse project that you are ready to share.
|
|
1006
|
+
- An account on [npmjs.com](https://www.npmjs.com/) (or a private registry).
|
|
1007
|
+
- Your project's `package.json` should have a unique name and correct version.
|
|
1008
|
+
- You must be logged into your npm account via the command line.
|
|
1009
|
+
|
|
1010
|
+
## Solution
|
|
1011
|
+
|
|
1012
|
+
### Step 1: Build the Project
|
|
1013
|
+
First, compile your project to create a production-ready build in the `dist/` or `build/` directory.
|
|
1014
|
+
|
|
1015
|
+
```bash
|
|
1016
|
+
pnpm build
|
|
1017
|
+
```
|
|
1018
|
+
|
|
1019
|
+
### Step 2: Log In to npm
|
|
1020
|
+
If you aren't already, log in to your npm account. You will be prompted for your username, password, and one-time password.
|
|
1021
|
+
|
|
1022
|
+
```bash
|
|
1023
|
+
npm login
|
|
1024
|
+
```
|
|
1025
|
+
|
|
1026
|
+
### Step 3: Version Your Package
|
|
1027
|
+
Update the package version according to semantic versioning. This command updates `package.json` and creates a new Git tag.
|
|
1028
|
+
|
|
1029
|
+
```bash
|
|
1030
|
+
# Choose one depending on the significance of your changes
|
|
1031
|
+
pnpm version patch # For bug fixes (e.g., 1.0.0 -> 1.0.1)
|
|
1032
|
+
pnpm version minor # For new features (e.g., 1.0.1 -> 1.1.0)
|
|
1033
|
+
pnpm version major # For breaking changes (e.g., 1.1.0 -> 2.0.0)
|
|
1034
|
+
```
|
|
1035
|
+
|
|
1036
|
+
### Step 4: Publish the Package
|
|
1037
|
+
Publish your package to the npm registry. If it's your first time publishing a scoped package (e.g., `@your-org/your-package`), you may need to add the `--access public` flag.
|
|
1038
|
+
|
|
1039
|
+
```bash
|
|
1040
|
+
npm publish --access public
|
|
1041
|
+
```
|
|
1042
|
+
|
|
1043
|
+
### Step 5: Push Git Commits and Tags
|
|
1044
|
+
Push your new version commit and tag to your remote repository to keep it in sync.
|
|
1045
|
+
|
|
1046
|
+
```bash
|
|
1047
|
+
# Push your current branch
|
|
1048
|
+
git push
|
|
1049
|
+
|
|
1050
|
+
# Push the newly created version tag
|
|
1051
|
+
git push --tags
|
|
1052
|
+
```
|
|
1053
|
+
|
|
1054
|
+
## Expected Outcome
|
|
1055
|
+
- Your Powerhouse project is successfully published to the npm registry.
|
|
1056
|
+
- Other developers can now install your package into their projects using `ph install @your-org/your-package-name`.
|
|
1057
|
+
- Your Git repository is updated with the new version information.
|
|
1058
|
+
|
|
1059
|
+
## Common Issues and Solutions
|
|
1060
|
+
- **Issue**: "403 Forbidden" or "You do not have permission" error on publish.
|
|
1061
|
+
- **Solution**: Ensure your package name is unique and not already taken on npm. If it's a scoped package (`@scope/name`), make sure the organization exists and you have permission to publish to it. For public scoped packages, you must include `--access public`.
|
|
1062
|
+
|
|
1063
|
+
## Related Recipes
|
|
1064
|
+
- [Installing a Custom Powerhouse Package](#installing-a-custom-powerhouse-package)
|
|
1065
|
+
- [Managing Powerhouse Dependencies and Versions](#managing-powerhouse-dependencies-and-versions)
|
|
1066
|
+
|
|
1067
|
+
</details>
|
|
1068
|
+
|
|
930
1069
|
## Data Synchronisation Recipes
|
|
931
1070
|
This section helps troubleshoot and understand data synchronization within the Powerhouse ecosystem, including interactions between different services and components.
|
|
932
1071
|
|
|
@@ -992,3 +1131,69 @@ Understanding the different GraphQL endpoints in Powerhouse is crucial for effec
|
|
|
992
1131
|
- **Solution:** Consider cleaning the global Powerhouse setup by removing `~/.ph`
|
|
993
1132
|
|
|
994
1133
|
</details>
|
|
1134
|
+
|
|
1135
|
+
<details id="clearing-package-manager-caches">
|
|
1136
|
+
<summary>Clearing Package Manager Caches</summary>
|
|
1137
|
+
|
|
1138
|
+
## How to Clear Package Manager Caches
|
|
1139
|
+
---
|
|
1140
|
+
|
|
1141
|
+
## Problem Statement
|
|
1142
|
+
You are encountering unexpected issues with dependencies, `ph-cmd` installation, or package resolution. Corrupted or outdated caches for your package manager (pnpm, npm, yarn) can often be the cause. Clearing the cache forces the package manager to refetch packages, which can resolve these problems.
|
|
1143
|
+
|
|
1144
|
+
## Prerequisites
|
|
1145
|
+
- Terminal or command prompt access
|
|
1146
|
+
- A package manager (pnpm, npm, or yarn) installed
|
|
1147
|
+
|
|
1148
|
+
## Solution
|
|
1149
|
+
|
|
1150
|
+
Choose the commands corresponding to the package manager you are using.
|
|
1151
|
+
|
|
1152
|
+
### For pnpm
|
|
1153
|
+
`pnpm` has a robust set of commands to manage its content-addressable store.
|
|
1154
|
+
|
|
1155
|
+
```bash
|
|
1156
|
+
# Verify the integrity of the cache
|
|
1157
|
+
pnpm cache verify
|
|
1158
|
+
|
|
1159
|
+
# Remove orphaned packages from the store
|
|
1160
|
+
pnpm store prune
|
|
1161
|
+
```
|
|
1162
|
+
|
|
1163
|
+
### For npm
|
|
1164
|
+
`npm` provides commands to clean and verify its cache.
|
|
1165
|
+
|
|
1166
|
+
```bash
|
|
1167
|
+
# Verify the contents of the cache folder, which can fix some issues
|
|
1168
|
+
npm cache verify
|
|
1169
|
+
|
|
1170
|
+
# If verification doesn't solve the issue, force clean the cache
|
|
1171
|
+
npm cache clean --force
|
|
1172
|
+
```
|
|
1173
|
+
|
|
1174
|
+
### For Yarn (v1 Classic)
|
|
1175
|
+
Yarn Classic allows you to list and clean the cache.
|
|
1176
|
+
|
|
1177
|
+
```bash
|
|
1178
|
+
# List the contents of the cache
|
|
1179
|
+
yarn cache list
|
|
1180
|
+
|
|
1181
|
+
# Clean the cache
|
|
1182
|
+
yarn cache clean --force
|
|
1183
|
+
```
|
|
1184
|
+
|
|
1185
|
+
## Expected Outcome
|
|
1186
|
+
- The package manager's cache is cleared or verified.
|
|
1187
|
+
- Subsequent installations will fetch fresh versions of packages, potentially resolving dependency-related errors.
|
|
1188
|
+
- Your system is in a cleaner state for managing Powerhouse project dependencies.
|
|
1189
|
+
|
|
1190
|
+
## Common Issues and Solutions
|
|
1191
|
+
- **Issue**: Problems persist after clearing the cache.
|
|
1192
|
+
- **Solution**: The issue might not be cache-related. Consider completely removing `node_modules` and lockfiles (`pnpm-lock.yaml`, `package-lock.json`, `yarn.lock`) and running `pnpm install` (or equivalent) again.
|
|
1193
|
+
|
|
1194
|
+
## Related Recipes
|
|
1195
|
+
- [Installing 'ph-cmd'](#installing-ph-cmd)
|
|
1196
|
+
- [Uninstalling 'ph-cmd'](#uninstalling-ph-cmd)
|
|
1197
|
+
- [Managing Powerhouse Dependencies and Versions](#managing-powerhouse-dependencies-and-versions)
|
|
1198
|
+
|
|
1199
|
+
</details>
|
|
@@ -17,7 +17,7 @@
|
|
|
17
17
|
- **Powerhouse Academy** – A training platform for onboarding and upskilling SNO contributors.
|
|
18
18
|
- **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.
|
|
19
19
|
- **Powergrid** – A decentralized network of reactors that sync with each other.
|
|
20
|
-
- **
|
|
20
|
+
- **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.
|
|
21
21
|
- **Connect App (Connect Studio)** – The primary Powerhouse application for defining document models, building/testing editors (in Studio mode), and collaborating on documents.
|
|
22
22
|
- **Document Tools** – Built-in features within Powerhouse applications (e.g., Connect) that assist with document management, inspection, and interaction, such as Operations History.
|
|
23
23
|
- **Operations History** – A Document Tool in Connect providing a chronological, immutable log of all operations on a document for traceability.
|
|
@@ -25,58 +25,60 @@
|
|
|
25
25
|
- **Renown (Login Flow)** – The Powerhouse decentralized login process using an Ethereum wallet signature to generate/retrieve a user's DID for secure, pseudonymous actions.
|
|
26
26
|
- **Powerhouse Switchboard (Verifier Role)** – A function of Powerhouse Switchboard that validates DIDs and credentials for operations submitted via Connect, ensuring they are authorized.
|
|
27
27
|
|
|
28
|
-
##
|
|
28
|
+
## Document Modeling
|
|
29
29
|
- **Action Creators (for Document Operations)** – Auto-generated helper functions creating structured "action" objects for dispatching operations to a document model's reducer.
|
|
30
30
|
- **Actions (Document Actions)** – Typed objects representing an intent to change a document's state, dispatched to reducers, containing an operation type and input data.
|
|
31
31
|
- **API Integration (for Document Models)** – The capability of Document Models to connect with Switchboard API or external APIs, facilitating data exchange between Powerhouse applications and other systems.
|
|
32
|
-
- **Boilerplate (Powerhouse Project)** – The `ph init` command's initial project structure, providing a standard starting point for new Powerhouse packages.
|
|
33
32
|
- **Data Analysis (with Document Models)** – Leveraging the structured data within Document Models, often via read models, to extract insights, generate reports, and perform analytics on operational and historical data.
|
|
34
33
|
- **Dispatch (in Document Models)** – The act of sending an action (representing an operation) to a document model's reducer to trigger a state update.
|
|
35
|
-
- **Document Model Editors** – An interface or UI to a document model that allows users to create and modify the data captured by the document models.
|
|
36
34
|
- **Document Model Specification** – The formal definition of a document model (state, operations), created in Connect Studio (using GraphQL SDL) and exported (e.g., `.phdm.zip`) for code generation.
|
|
37
35
|
- **Document Models** – Structured data models that define how Powerhouse documents store and process information.
|
|
38
36
|
- **Document State** – The current data held by a document instance, structured according to its Document Model.
|
|
39
37
|
- **Document Type** – A unique string identifier (e.g., `powerhouse/todolist`) for a Document Model, used by host apps to select the correct editor/logic.
|
|
40
|
-
- **Drive** – A logical container in Powerhouse for storing, organizing, and managing collections of documents.
|
|
41
|
-
- **Drive App (Custom Drive Explorer)** – A UI application, often custom, providing tailored views and interactions with documents in a Drive.
|
|
42
38
|
- **Event History (Append-Only Log)** – An immutable, append-only log where every operation applied to a Powerhouse document is stored as an event. It provides a transparent audit trail and enables features like time travel debugging and state reconstruction.
|
|
43
39
|
- **GraphQL Scalars** – Data types used in Powerhouse document modeling (e.g., `String`, `Int`, `Currency`, `OID` for unique object IDs).
|
|
44
40
|
- **GraphQL Schema Definition Language (SDL) (for Document Models)** – Language used in Connect Studio to define a Document Model's data structure (state) and operations.
|
|
45
|
-
- **
|
|
41
|
+
- **Immutable Updates** – A principle where data is never altered in place; operations create new data versions, vital for Powerhouse's event sourcing.
|
|
46
42
|
- **Input Types (GraphQL for Document Operations)** – Custom data structures in SDL detailing parameters for document operations (e.g., `AddTodoItemInput`).
|
|
47
43
|
- **Model-Driven Development (MDD)** – A software approach that uses high-level models to generate system logic and configurations.
|
|
48
|
-
- **Modules (in Document Model Editor)** – An organizational feature in Connect Studio's model editor for grouping related operations.
|
|
49
44
|
- **Operations (Document Operations)** – Named commands (e.g., `ADD_TODO_ITEM`) in a Document Model representing all ways to change its state, forming its event log.
|
|
50
45
|
- **Powerhouse Document (`.phd` file)** – Standard file extension for an exported Powerhouse document instance, containing its data and history.
|
|
51
|
-
- **Powerhouse Package** – A collection of document models, document model editors, and other resources that are published as a package and can be used in any of the host applications.
|
|
52
|
-
- **Powerhouse Project** – A collection of document models, document model editors, and other resources being build in Connect Studio.
|
|
53
46
|
- **Pure Functions (for Reducers)** – Principle that document model reducers must be pure (output depends only on input, no side effects) for predictable state transitions.
|
|
54
47
|
- **Reducers (Document Model Reducers)** – Functions implementing a Document Model's logic; for each operation, a reducer takes current state and an action, returning new state.
|
|
55
48
|
- **Replay Events** – The process of re-applying recorded events from a document's Event History to reconstruct or restore its state, a core capability of Event Sourcing.
|
|
56
|
-
- **Scalars (Design System Components)** – Reusable UI building blocks (e.g., `Checkbox`, `InputField`) from `@powerhousedao/document-engineering/scalars`, used in editors (distinct from GraphQL scalars).
|
|
57
49
|
- **State (Global State in Document Model)** – The primary, persisted, shared data of a document instance, managed by its reducers.
|
|
58
|
-
- **State (Local State in Editor)** – Temporary, UI-specific data within an editor (e.g., form inputs), not persisted in the global document state.
|
|
59
50
|
- **State Schema** – The component of a Document Model that defines the structure of the document, including its fields, data types, and validation rules, typically using a GraphQL-like syntax. It serves as a blueprint for how data is stored and validated.
|
|
60
|
-
- **Storybook (for Powerhouse Design System)** – Interactive environment for browsing and testing Powerhouse Design System UI components.
|
|
61
51
|
- **Strands** – A single synchronization channel that connects exactly one unit of synchronization to another, with all four parameters (drive_url, doc_id, scope, branch) set to fixed values. This allows synchronization between two distinct points of instances of a document or document drive.
|
|
62
|
-
- **Tailwind CSS (in Connect Studio)** – Utility CSS framework integrated into Connect Studio for styling document editors.
|
|
63
52
|
- **Time Travel Debugging** – A debugging technique, enabled by a document's Event History, that allows developers to reconstruct and inspect past states of the document by replaying events up to a specific point in time.
|
|
64
53
|
- **Type Safety (in Document Modeling)** – Powerhouse's use of auto-generated TypeScript definitions from a model's schema (SDL) to prevent data type errors in development.
|
|
65
54
|
- **Version Control (for Document Models)** – A planned feature for Document Models in Connect that will allow tracking of changes, comparison of different versions, and maintenance of data integrity over time, similar to version control systems for source code.
|
|
66
55
|
|
|
56
|
+
## Development & Tooling
|
|
57
|
+
- **Boilerplate (Powerhouse Project)** – The `ph init` command's initial project structure, providing a standard starting point for new Powerhouse packages.
|
|
58
|
+
- **Connect Build** – The output of the `ph connect build` command, which packages a Connect project into a distributable format. This build includes all necessary local/external packages, assets, and styles, and can be previewed locally with `ph connect preview` or deployed.
|
|
59
|
+
- **Development Environment (Powerhouse)** – A local setup for developing Powerhouse applications, typically initiated with the `ph dev` command. It runs essential backend services like the Powerhouse Switchboard to enable real-time document model processing, code generation, and live updates, separate from the front-end Connect Studio.
|
|
60
|
+
- **Document Model Editors** – An interface or UI to a document model that allows users to create and modify the data captured by the document models.
|
|
61
|
+
- **Drive** – A logical container in Powerhouse for storing, organizing, and managing collections of documents.
|
|
62
|
+
- **Drive App (Custom Drive Explorer)** – A UI application, often custom, providing tailored views and interactions with documents in a Drive.
|
|
63
|
+
- **Environments (Powerhouse Environments)** – Pre-defined configurations for a project's Powerhouse dependencies, such as `dev` (development), `prod` (production/latest), and `local`. The Powerhouse CLI (`ph use` command) allows developers to easily switch between these environments to use different versions of packages (e.g., bleeding-edge, stable, or from a local monorepo).
|
|
64
|
+
- **Host Applications** – Applications that use the Powerhouse framework to create and manage documents and data.
|
|
65
|
+
- **Modules (in Document Model Editor)** – An organizational feature in Connect Studio's model editor for grouping related operations.
|
|
66
|
+
- **Powerhouse Package** – A collection of document models, document model editors, and other resources that are published as a package and can be used in any of the host applications.
|
|
67
|
+
- **Powerhouse Project** – A collection of document models, document model editors, and other resources being build in Connect Studio.
|
|
68
|
+
- **Scalars (Design System Components)** – Reusable UI building blocks (e.g., `Checkbox`, `InputField`) from `@powerhousedao/document-engineering/scalars`, used in editors (distinct from GraphQL scalars).
|
|
69
|
+
- **State (Local State in Editor)** – Temporary, UI-specific data within an editor (e.g., form inputs), not persisted in the global document state.
|
|
70
|
+
- **Storybook (for Powerhouse Design System)** – Interactive environment for browsing and testing Powerhouse Design System UI components.
|
|
71
|
+
- **Tailwind CSS (in Connect Studio)** – Utility CSS framework integrated into Connect Studio for styling document editors.
|
|
72
|
+
|
|
67
73
|
## AI & Automation
|
|
68
74
|
- **AI Assistants** – AI-powered contributors paired with human contributors to automate tasks and improve productivity.
|
|
69
75
|
- **AI Contributor Modes** – Configurable states that determine the AI assistant's behavior, permissions, and task focus.
|
|
70
76
|
- **Task Automation & Scaling** – The use of AI to streamline repetitive tasks, improve communications, and enhance decision-making.
|
|
71
77
|
- **Decentralized Identifier (DID)** – A user-controlled, globally unique ID, used in Renown to link a user's blockchain key to actions pseudonymously.
|
|
72
|
-
- **Immutable Updates** – A principle where data is never altered in place; operations create new data versions, vital for Powerhouse's event sourcing.
|
|
73
|
-
- **Type Safety (in Document Modeling)** – Powerhouse's use of auto-generated TypeScript definitions from a model's schema (SDL) to prevent data type errors in development.
|
|
74
78
|
|
|
75
79
|
## Organizational Concepts
|
|
76
80
|
- **Ceramic** – A decentralized network for storing verifiable data, used by Powerhouse Renown for secure credential management.
|
|
77
81
|
- **Decentralized Identifier (DID)** – A user-controlled, globally unique ID, used in Renown to link a user's blockchain key to actions pseudonymously.
|
|
78
|
-
- **Event History (Append-Only Log)** – An immutable, append-only log where every operation applied to a Powerhouse document is stored as an event. It provides a transparent audit trail and enables features like time travel debugging and state reconstruction.
|
|
79
82
|
- **Event-Driven Architecture (EDA)** – A software design approach where system flows are determined by events that trigger actions asynchronously.
|
|
80
|
-
- **Immutable Updates** – A principle where data is never altered in place; operations create new data versions, vital for Powerhouse's event sourcing.
|
|
81
83
|
- **Network Organization** – A group of independent contributors and teams working together towards a common purpose, relying on decentralization and resource sharing.
|
|
82
84
|
|
|
@@ -0,0 +1,131 @@
|
|
|
1
|
+
# AI Resources
|
|
2
|
+
|
|
3
|
+
We have a couple of AI resources to help you with your daily work or exploring our ecosystem.
|
|
4
|
+
|
|
5
|
+
:::warning
|
|
6
|
+
- Be aware that AI tooling can make mistakes.
|
|
7
|
+
- Documentation can be out of date or code can be work in progress.
|
|
8
|
+
- Always verify your coding agent's suggestions.
|
|
9
|
+
:::
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
| Tool | Description |
|
|
13
|
+
|---|---|
|
|
14
|
+
| [**Deepwiki**](https://deepwiki.com/powerhouse-inc/powerhouse) | A searchable/queriable wiki to understand our growing Powerhouse **Monorepository** better. <br /> DeepWiki provides up-to-date documentation you can talk to, for every repo in the world. Think Deep Research for GitHub. |
|
|
15
|
+
| [**Context7**](https://context7.com/powerhouse-inc/powerhouse) | The Powerhouse **Academy Documentation** is also available as context through the context7 MCP Server. <br /> LLMs rely on outdated or generic information about the libraries you use. <br /> Context7 pulls up-to-date, version-specific documentation and code examples directly from the source. <br /> Paste accurate, relevant documentation directly into tools like Cursor, Claude, or any LLM. <br /> The official repository can be found [here](https://github.com/upstash/context7). |
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
### Context7 Installation
|
|
19
|
+
|
|
20
|
+
<details>
|
|
21
|
+
<summary><b>Install in Cursor</b></summary>
|
|
22
|
+
|
|
23
|
+
Go to: `Settings` -> `Cursor Settings` -> `MCP` -> `Add new global MCP server`
|
|
24
|
+
|
|
25
|
+
Pasting the following configuration into your Cursor `~/.cursor/mcp.json` file is the recommended approach. You may also install in a specific project by creating `.cursor/mcp.json` in your project folder.
|
|
26
|
+
|
|
27
|
+
**Cursor Local Server Connection**
|
|
28
|
+
|
|
29
|
+
```json
|
|
30
|
+
{
|
|
31
|
+
"mcpServers": {
|
|
32
|
+
"context7": {
|
|
33
|
+
"command": "npx",
|
|
34
|
+
"args": ["-y", "@upstash/context7-mcp"]
|
|
35
|
+
}
|
|
36
|
+
}
|
|
37
|
+
}
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
</details>
|
|
41
|
+
|
|
42
|
+
<details>
|
|
43
|
+
<summary><b>Install in VS Code</b></summary>
|
|
44
|
+
|
|
45
|
+
Add this to your VS Code MCP config file. See [VS Code MCP docs](https://code.visualstudio.com/docs/copilot/chat/mcp-servers) for more info.
|
|
46
|
+
|
|
47
|
+
**VS Code Local Server Connection**
|
|
48
|
+
|
|
49
|
+
```json
|
|
50
|
+
"mcp": {
|
|
51
|
+
"servers": {
|
|
52
|
+
"context7": {
|
|
53
|
+
"type": "stdio",
|
|
54
|
+
"command": "npx",
|
|
55
|
+
"args": ["-y", "@upstash/context7-mcp"]
|
|
56
|
+
}
|
|
57
|
+
}
|
|
58
|
+
}
|
|
59
|
+
```
|
|
60
|
+
</details>
|
|
61
|
+
|
|
62
|
+
For other editors, please refer to the [official documentation](https://github.com/upstash/context7#%-installation).
|
|
63
|
+
|
|
64
|
+
### Context7 Troubleshooting
|
|
65
|
+
|
|
66
|
+
<details>
|
|
67
|
+
<summary><b>MCP, Documentation or Module Not Found Errors</b></summary>
|
|
68
|
+
|
|
69
|
+
If you encounter `ERR_MODULE_NOT_FOUND`, try using `bunx` instead of `npx`:
|
|
70
|
+
|
|
71
|
+
```json
|
|
72
|
+
{
|
|
73
|
+
"mcpServers": {
|
|
74
|
+
"context7": {
|
|
75
|
+
"command": "bunx",
|
|
76
|
+
"args": ["-y", "@upstash/context7-mcp"]
|
|
77
|
+
}
|
|
78
|
+
}
|
|
79
|
+
}
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
This often resolves module resolution issues in environments where `npx` doesn't properly install or resolve packages.
|
|
83
|
+
|
|
84
|
+
</details>
|
|
85
|
+
|
|
86
|
+
<details>
|
|
87
|
+
<summary><b>ESM Resolution Issues</b></summary>
|
|
88
|
+
|
|
89
|
+
For errors like `Error: Cannot find module 'uriTemplate.js'`, try the `--experimental-vm-modules` flag:
|
|
90
|
+
|
|
91
|
+
```json
|
|
92
|
+
{
|
|
93
|
+
"mcpServers": {
|
|
94
|
+
"context7": {
|
|
95
|
+
"command": "npx",
|
|
96
|
+
"args": ["-y", "--node-options=--experimental-vm-modules", "@upstash/context7-mcp@1.0.6"]
|
|
97
|
+
}
|
|
98
|
+
}
|
|
99
|
+
}
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
</details>
|
|
103
|
+
|
|
104
|
+
<details>
|
|
105
|
+
<summary><b>TLS/Certificate Issues</b></summary>
|
|
106
|
+
|
|
107
|
+
Use the `--experimental-fetch` flag to bypass TLS-related problems:
|
|
108
|
+
|
|
109
|
+
```json
|
|
110
|
+
{
|
|
111
|
+
"mcpServers": {
|
|
112
|
+
"context7": {
|
|
113
|
+
"command": "npx",
|
|
114
|
+
"args": ["-y", "--node-options=--experimental-fetch", "@upstash/context7-mcp"]
|
|
115
|
+
}
|
|
116
|
+
}
|
|
117
|
+
}
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
</details>
|
|
121
|
+
|
|
122
|
+
<details>
|
|
123
|
+
<summary><b>General MCP Client Errors</b></summary>
|
|
124
|
+
|
|
125
|
+
1. Try adding `@latest` to the package name
|
|
126
|
+
2. Use `bunx` as an alternative to `npx`
|
|
127
|
+
3. Consider using `deno` as another alternative
|
|
128
|
+
4. Ensure you're using Node.js v18 or higher for native fetch support
|
|
129
|
+
|
|
130
|
+
</details>
|
|
131
|
+
|
package/package.json
CHANGED
package/sidebars.ts
CHANGED
|
@@ -68,27 +68,7 @@ const sidebars = {
|
|
|
68
68
|
link: {
|
|
69
69
|
type: 'generated-index',
|
|
70
70
|
},
|
|
71
|
-
items: [
|
|
72
|
-
'academy/MasteryTrack/BuildingUserExperiences/BuildingDocumentEditors',
|
|
73
|
-
'academy/MasteryTrack/BuildingUserExperiences/ConfiguringDrives',
|
|
74
|
-
'academy/MasteryTrack/BuildingUserExperiences/BuildingADriveExplorer',
|
|
75
|
-
]
|
|
76
|
-
},
|
|
77
|
-
{
|
|
78
|
-
type: 'category',
|
|
79
|
-
label: 'Document Tools',
|
|
80
|
-
link: {
|
|
81
|
-
type: 'generated-index',
|
|
82
|
-
},
|
|
83
|
-
items: [{ type: 'autogenerated', dirName: 'academy/02-MasteryTrack/03-BuildingUserExperiences/07-DocumentTools' }]
|
|
84
|
-
},
|
|
85
|
-
{
|
|
86
|
-
type: 'category',
|
|
87
|
-
label: 'Authorization',
|
|
88
|
-
link: {
|
|
89
|
-
type: 'generated-index',
|
|
90
|
-
},
|
|
91
|
-
items: [{ type: 'autogenerated', dirName: 'academy/02-MasteryTrack/03-BuildingUserExperiences/08-Authorization' }]
|
|
71
|
+
items: [{ type: 'autogenerated', dirName: 'academy/02-MasteryTrack/03-BuildingUserExperiences' }]
|
|
92
72
|
},
|
|
93
73
|
{
|
|
94
74
|
type: 'category',
|
|
@@ -140,30 +120,8 @@ const sidebars = {
|
|
|
140
120
|
</a>
|
|
141
121
|
`,
|
|
142
122
|
},
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
id: 'academy/ComponentLibrary/BuildingWithScalars',
|
|
146
|
-
},
|
|
147
|
-
{
|
|
148
|
-
type: 'category',
|
|
149
|
-
label: 'Scalar Components',
|
|
150
|
-
items: [{type: 'autogenerated', dirName: 'academy/06-ComponentLibrary/03-Scalar-Components'}],
|
|
151
|
-
},
|
|
152
|
-
{
|
|
153
|
-
type: 'category',
|
|
154
|
-
label: 'Complex Components',
|
|
155
|
-
items: [{type: 'autogenerated', dirName: 'academy/06-ComponentLibrary/04-Complex-Components'}],
|
|
156
|
-
},
|
|
157
|
-
{
|
|
158
|
-
type: 'category',
|
|
159
|
-
label: 'Layout Components',
|
|
160
|
-
items: [{type: 'autogenerated', dirName: 'academy/06-ComponentLibrary/05-Layout-Components'}],
|
|
161
|
-
},
|
|
162
|
-
{
|
|
163
|
-
type: 'category',
|
|
164
|
-
label: 'Fragments',
|
|
165
|
-
items: [{type: 'autogenerated', dirName: 'academy/06-ComponentLibrary/06-Fragments'}],
|
|
166
|
-
},
|
|
123
|
+
'academy/ComponentLibrary/CreateCustomScalars',
|
|
124
|
+
'academy/ComponentLibrary/IntegrateIntoAReactComponent',
|
|
167
125
|
],
|
|
168
126
|
},
|
|
169
127
|
|
|
@@ -1,54 +0,0 @@
|
|
|
1
|
-
# Build with Scalars
|
|
2
|
-
|
|
3
|
-
Scalars are here to help you define custom fields in your document model schema and speed up the development process.
|
|
4
|
-
There are two applications of scalar components in the document model workflow:
|
|
5
|
-
|
|
6
|
-
1. At the **schema definition** level where you build your schema and write your GraphQL state schema.
|
|
7
|
-
2. At the **frontend / react** level where you import it and place it in your UI to represent the scalar field
|
|
8
|
-
|
|
9
|
-
## Scalar Definition in the Document Model Schema
|
|
10
|
-
|
|
11
|
-
As you might know, the document model schema defines the structure of the document and serves as the backbone of the document model. The GraphQL state schema defines how data is captured with the help of types & scalars. When you define a scalar in the document model schema, you are essentially defining a new field that can be used in the document model to capture data.
|
|
12
|
-
|
|
13
|
-
In the Document Model Editor, you can find all the custom scalar types available in our documentation under the 'Scalars' section.
|
|
14
|
-
|
|
15
|
-
Insert image of the feature.
|
|
16
|
-
|
|
17
|
-
````
|
|
18
|
-
scalar PHID <-- imported from the design system library? not sure
|
|
19
|
-
type MyType {
|
|
20
|
-
myScalar: PHID
|
|
21
|
-
}
|
|
22
|
-
````
|
|
23
|
-
|
|
24
|
-
## React Component Implementation in the Frontend
|
|
25
|
-
|
|
26
|
-
All of our reusable components are available in the Document-Engineering design system library or package.
|
|
27
|
-
This package comes as a dependency in your project when creating a new document model project.
|
|
28
|
-
````
|
|
29
|
-
import PHIDField from 'document-engineering'
|
|
30
|
-
const reactComponent = () => {
|
|
31
|
-
|
|
32
|
-
return (
|
|
33
|
-
<div>
|
|
34
|
-
<PHIDField
|
|
35
|
-
fetchOptionsCallback={function Js(){}}
|
|
36
|
-
fetchSelectedOptionCallback={function Js(){}}
|
|
37
|
-
label="PHID field"
|
|
38
|
-
name="phid-field"
|
|
39
|
-
placeholder="phd:"
|
|
40
|
-
/>
|
|
41
|
-
|
|
42
|
-
</div>
|
|
43
|
-
|
|
44
|
-
)
|
|
45
|
-
|
|
46
|
-
}
|
|
47
|
-
````
|
|
48
|
-
|
|
49
|
-
## Scalars & Reusable Components
|
|
50
|
-
|
|
51
|
-
To make your life easier, Powerhouse has defined all useful scalars with a set of reusable code and UI components.
|
|
52
|
-
The reusable components are essentially a set of front-end components based on GraphQL scalars. Powerhouse also has a set of custom scalars that are not part of the GraphQL standard but are specific to the web3 ecosystem.
|
|
53
|
-
|
|
54
|
-
Read the next chapter to get familiar with our reusable components.
|
|
@@ -1,72 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
sidebar_label: 'PHID Field'
|
|
3
|
-
sidebar_position: 1
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
import { Tabs, TabItem } from '@theme/Tabs';
|
|
7
|
-
|
|
8
|
-
# PHID Field Example
|
|
9
|
-
|
|
10
|
-
### **Scalar Definition**
|
|
11
|
-
|
|
12
|
-
- **Name:** `PHID` (Powerhouse ID)
|
|
13
|
-
- **Purpose:** Represents a unique identifier pointing to a document, branch, scope, or data object within the Powerhouse system.
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
<details>
|
|
17
|
-
<summary>**Formatting of the component:**</summary>
|
|
18
|
-
- **Basic Notation:** `phd:<documentID>`
|
|
19
|
-
- **Branch and Scope:** Optional components appended using colons `:`.
|
|
20
|
-
- **Full Notation:** `phd:<documentID>:<branch>:<scope>`
|
|
21
|
-
- **Branch:** Defaults to `main` if omitted.
|
|
22
|
-
- **Scope:** Defaults to `public` if omitted.
|
|
23
|
-
- **Data Object Reference:** `phd:<documentID>/<dataObjectID>`
|
|
24
|
-
- **URL Format:** `phd://<domain>/<documentID>`
|
|
25
|
-
- Example: `phd://switchboard.powerhouse.xyz/baefc2a4-f9a0-4950-8161-fd8d8cc7dea9`
|
|
26
|
-
|
|
27
|
-
**Examples of the component formatting:**
|
|
28
|
-
- **Basic PHID:** `phd:baefc2a4-f9a0-4950-8161-fd8d8cc7dea9`
|
|
29
|
-
- **With Branch:** `phd:baefc2a4...:draft`
|
|
30
|
-
- **With Scope:** `phd:baefc2a4...::local`
|
|
31
|
-
- **With Branch and Scope:** `phd:baefc2a4...:draft:local`
|
|
32
|
-
- **With Data Object ID:** `phd:baefc2a4.../3cf05e40...`
|
|
33
|
-
</details>
|
|
34
|
-
|
|
35
|
-
<details>
|
|
36
|
-
<summary>**Validation of the Component:**</summary>
|
|
37
|
-
- **Validate each format:**
|
|
38
|
-
1. **PHID only:** Ensure the document ID is a valid UUID.
|
|
39
|
-
2. **PHID with data element (OID):** Validate both the document ID and the data object ID.
|
|
40
|
-
3. **PHID with branch:** Validate the document ID and check if the branch is properly formatted.
|
|
41
|
-
4. **PHID with scope:** Validate the document ID and check if the scope is valid.
|
|
42
|
-
5. **PHID with branch and scope:** Validate all three components: document ID, branch, and scope.
|
|
43
|
-
- **Error Message Example:** "Invalid PHID format. Please check the document ID, branch, or scope."
|
|
44
|
-
</details>
|
|
45
|
-
|
|
46
|
-
The following is a the UI component for the PHID field and scalar in a storybook.
|
|
47
|
-
We use Storybook as our component development environment.
|
|
48
|
-
It allows us to build and test UI components in isolation, making it easier to develop, test, and document reusable components.
|
|
49
|
-
In our stories you'll find first find a basic UI implementation example of the component, followed by the component's properties, events, and validation options.
|
|
50
|
-
|
|
51
|
-
- A list of the **default properties** and their descriptions, and a list of the available events that can be triggered.
|
|
52
|
-
- A list of the **component's specific properties** and attributes based on the components functionality.
|
|
53
|
-
- A list of **validation options**, or ways to validate the component's desired input values.
|
|
54
|
-
|
|
55
|
-
Additionally, you'll find various **stories of the components in different states**.
|
|
56
|
-
|
|
57
|
-
<div style={{
|
|
58
|
-
border: '1px solid #E5E7EB',
|
|
59
|
-
borderRadius: '8px',
|
|
60
|
-
padding: '16px',
|
|
61
|
-
marginBottom: '20px',
|
|
62
|
-
}}>
|
|
63
|
-
<iframe
|
|
64
|
-
src="https://storybook.powerhouse.academy/iframe.html?id=scalars-phid-field--readme&viewMode=story"
|
|
65
|
-
style={{
|
|
66
|
-
width: '100%',
|
|
67
|
-
height: '4500px',
|
|
68
|
-
border: 'none',
|
|
69
|
-
}}
|
|
70
|
-
title="PhidField Component Demo"
|
|
71
|
-
/>
|
|
72
|
-
</div>
|
|
File without changes
|