@powerhousedao/academy 3.2.0-dev.8 → 3.2.0-dev.9
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 +11 -0
- package/docs/academy/01-GetStarted/00-ExploreDemoPackage.mdx +60 -51
- package/docs/academy/01-GetStarted/01-CreateNewPowerhouseProject.md +8 -28
- package/docs/academy/01-GetStarted/02-DefineToDoListDocumentModel.md +1 -1
- package/docs/academy/01-GetStarted/images/OperationsHistory.png +0 -0
- package/docs/academy/01-GetStarted/images/OperationsHistoryButton.png +0 -0
- package/docs/academy/01-GetStarted/images/OperationsHistorySignature.png +0 -0
- package/docs/academy/02-MasteryTrack/04-WorkWithData/05-AnalyticsProcessorTutorial/02-CreateNewPowerhouseProject.md +4 -2
- package/docs/academy/03-ExampleUsecases/Chatroom/02-CreateNewPowerhouseProject.md +2 -1
- package/docs/academy/06-ComponentLibrary/00-DocumentEngineering.md +52 -0
- package/docs/academy/07-Cookbook.md +2 -2
- package/package.json +1 -1
- package/src/css/custom.css +15 -0
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,14 @@
|
|
|
1
|
+
## 3.2.0-dev.9 (2025-07-02)
|
|
2
|
+
|
|
3
|
+
### 🩹 Fixes
|
|
4
|
+
|
|
5
|
+
- updated processor generator and added codegen test for it ([6af3bbcf7](https://github.com/powerhouse-inc/powerhouse/commit/6af3bbcf7))
|
|
6
|
+
- added test to generate and compile a generated document-model ([17bbca3bb](https://github.com/powerhouse-inc/powerhouse/commit/17bbca3bb))
|
|
7
|
+
|
|
8
|
+
### ❤️ Thank You
|
|
9
|
+
|
|
10
|
+
- Benjamin Jordan (@thegoldenmule)
|
|
11
|
+
|
|
1
12
|
## 3.2.0-dev.8 (2025-07-01)
|
|
2
13
|
|
|
3
14
|
### 🚀 Features
|
|
@@ -1,18 +1,5 @@
|
|
|
1
1
|
# Explore the demo package
|
|
2
2
|
|
|
3
|
-
<details>
|
|
4
|
-
<summary>How long will this tutorial take?</summary>
|
|
5
|
-
|
|
6
|
-
We've designed this "Get Started" track to be as smooth as possible. The time it takes will vary based on your familiarity with modern web development tools.
|
|
7
|
-
|
|
8
|
-
- **For Experienced Developers** (familiar with TypeScript, React, and CLIs), you can expect to complete the entire four-part tutorial in approximately **1 to 1.5 hours**.
|
|
9
|
-
- **For Developers New to This Stack**, we recommend setting aside **3.5 to 4.5 hours**. This allows for time to understand not just the steps, but the core concepts behind them.
|
|
10
|
-
|
|
11
|
-
This is just a guideline. The goal is to learn comfortably and build a solid foundation with Powerhouse!
|
|
12
|
-
|
|
13
|
-
A more theoretical and advanced version of this tutorial can also be found in [Mastery Track - Document Model Creation](../MasteryTrack/DocumentModelCreation/WhatIsADocumentModel).
|
|
14
|
-
</details>
|
|
15
|
-
|
|
16
3
|
## Let's get started
|
|
17
4
|
|
|
18
5
|
To give you a quick idea of how the Powerhouse ecosystem operates on document models and packages, why don't you try installing a package?
|
|
@@ -109,7 +96,55 @@ Here, you'll see that you've installed the `@powerhousedao/todo-demo-package`, w
|
|
|
109
96
|
<figcaption>The Package Manager showing the installed todo-demo-package.</figcaption>
|
|
110
97
|
</figure>
|
|
111
98
|
|
|
112
|
-
## Step 4:
|
|
99
|
+
## Step 4: Create a todo list document
|
|
100
|
+
|
|
101
|
+
:::tip What is a 'drive' at Powerhouse?
|
|
102
|
+
A **drive** is a folder to store and organize your documents in. Powerhouse offers the ability to build customized 'Drive Apps' for your documents. Think of a Drive App as a specialized lens—it offers **different ways to visualize, organize, and interact with** the data stored within a drive, making it more intuitive and efficient for specific use cases. To learn more, visit [Building A Drive App](/academy/MasteryTrack/BuildingUserExperiences/BuildingADriveExplorer)
|
|
103
|
+
:::
|
|
104
|
+
|
|
105
|
+
### 4.1 Create a local todolist app drive
|
|
106
|
+
|
|
107
|
+
First, let's create a dedicated drive for your to-do lists:
|
|
108
|
+
|
|
109
|
+
- Click the new drive icon in the interface
|
|
110
|
+
- In the **Drive App** field, select 'To-do Drive App'
|
|
111
|
+
- This creates a specialized drive that's optimized for to-do list documents
|
|
112
|
+
|
|
113
|
+
### 4.2 Create a todolist document
|
|
114
|
+
|
|
115
|
+
Now move into the drive you've just created:
|
|
116
|
+
|
|
117
|
+
- Click the button at the bottom of the page to create a new to-do list document
|
|
118
|
+
- This opens the to-do list editor where you can start managing your tasks
|
|
119
|
+
|
|
120
|
+
### 4.3 Add a few todos and inspect the document history
|
|
121
|
+
|
|
122
|
+
- Add a few to-dos that are on your mind
|
|
123
|
+
- You'll see a statistics widget that counts the open to-dos
|
|
124
|
+
- After closing the document, look at the To-do Drive App interface—you'll see that it tracks your tasks and displays a progress bar
|
|
125
|
+
|
|
126
|
+
<figure className="image-container">
|
|
127
|
+
<img src={require("./images/TodoDriveApp.png").default} alt="Todo Drive App" />
|
|
128
|
+
<figcaption>A list of todo's in the custom todo drive app. </figcaption>
|
|
129
|
+
</figure>
|
|
130
|
+
|
|
131
|
+
A key feature you get with Connect is the **Operations History**. Every change to a document is stored as an individual operation, creating an immutable and replayable history. This provides complete auditability and transparency, as you can inspect each revision, its details, and any associated signatures. For example, you can see a chronological list of all modifications, along with who made them and when.
|
|
132
|
+
|
|
133
|
+
<figure className="image-container">
|
|
134
|
+
<img src={require("./images/OperationsHistoryButton.png").default} alt="Operations History Button" />
|
|
135
|
+
<figcaption> You can find the button to visit the operations history in the document model toolbar </figcaption>
|
|
136
|
+
</figure>
|
|
137
|
+
|
|
138
|
+
<figure className="image-container">
|
|
139
|
+
<img src={require("./images/OperationsHistory.png").default} alt="Operations History" />
|
|
140
|
+
<figcaption>Example of the operations history for a document, showing all modifications made to it in a list. </figcaption>
|
|
141
|
+
</figure>
|
|
142
|
+
|
|
143
|
+
Learn more about the [Operations History](../MasteryTrack/BuildingUserExperiences/DocumentTools/OperationHistory) and other document tools you get for free.
|
|
144
|
+
|
|
145
|
+
This is the power of Drive Apps. They offer a customized interface that works well with the different documents inside your drive. Read more about drive apps in the Mastery Track: [Drive Apps and Drive Explorers](/academy/MasteryTrack/BuildingUserExperiences/BuildingADriveExplorer).
|
|
146
|
+
|
|
147
|
+
## Step 5: Enable operation signing and verification through Renown
|
|
113
148
|
|
|
114
149
|
Renown is Powerhouse's **decentralized identity and reputation system** designed to address the challenge of trust within open organizations, where contributors often operate under pseudonyms. In traditional organizations, personal identity and reputation are key to establishing trust and accountability. Renown replicates this dynamic in the digital space, allowing contributors to earn experience and build reputation without revealing their real-world identities.
|
|
115
150
|
|
|
@@ -117,16 +152,18 @@ Renown is Powerhouse's **decentralized identity and reputation system** designed
|
|
|
117
152
|
When signing in with Renown, use an Ethereum or blockchain address that can function as your 'identity', as this address will accrue more experience and history over time.
|
|
118
153
|
:::
|
|
119
154
|
|
|
120
|
-
###
|
|
121
|
-
|
|
155
|
+
### 5.1 Click the renown icon and connect your eth identity
|
|
156
|
+
|
|
157
|
+
"**Log in with Renown**" is a decentralized authentication flow that enables you to log into applications by signing a credential with your Ethereum wallet. Upon signing in, a Decentralized Identifier (DID) is created based on your Ethereum key.
|
|
122
158
|
|
|
123
159
|
<figure className="image-container">
|
|
124
160
|
<img src={require("./images/RenownLogin.png").default} alt="Renown Login" />
|
|
125
161
|
<figcaption>The Renown login screen, prompting for a signature from a wallet.</figcaption>
|
|
126
162
|
</figure>
|
|
127
163
|
|
|
128
|
-
###
|
|
129
|
-
|
|
164
|
+
### 5.2 Authorize Connect to sign document edits on your behalf
|
|
165
|
+
|
|
166
|
+
This DID is then associated with a credential that authorizes a specific Connect instance to act on your behalf. That credential is stored securely on Ceramic, a decentralized data network. When you perform actions through the Powerhouse Connect interface, those operations are signed with the DID and transmitted to Switchboard, which serves as the verifier.
|
|
130
167
|
|
|
131
168
|
<figure className="image-container">
|
|
132
169
|
<img src={require("./images/ConnectAddress.png").default} alt="Connect Address for DID" />
|
|
@@ -138,45 +175,17 @@ This DID is then associated with a credential that authorizes a specific Connect
|
|
|
138
175
|
<figcaption>Confirmation of a successful login with Renown.</figcaption>
|
|
139
176
|
</figure>
|
|
140
177
|
|
|
141
|
-
###
|
|
142
|
-
**Switchboard**, our (remote & local) data processing engine, acts as a verifier in the Renown authentication flow. Switchboard checks the validity of the DID and credential, ensuring the operation request is legitimate. This flow is designed to offer a verifiable, cryptographically secure login system that replaces traditional password-based authentication with decentralized identity and signature-based trust.
|
|
178
|
+
### 5.3 Verify the signatures of new operations in the todo list
|
|
143
179
|
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
<figure className="image-container">
|
|
147
|
-
<img src={require("./images/OperationsHistory.png").default} alt="Operations History" />
|
|
148
|
-
<figcaption>Example of the operations history for a document, showing all modifications made to it in a list. </figcaption>
|
|
149
|
-
</figure>
|
|
180
|
+
By leveraging this system, every operation or modification made to a document is cryptographically signed by the contributor's Renown identity. This ensures that each change is verifiable, traceable, and attributable to a specific pseudonymous user, providing a robust audit trail for all document activity.
|
|
150
181
|
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
A key feature you get with Connect is the **Operations History**. Every change to a document is stored as an individual operation, creating an immutable and replayable history. This provides complete auditability and transparency, as you can inspect each revision, its details, and any associated signatures. For example, you can see a chronological list of all modifications, along with who made them and when. This ensures every action is traceable and verifiable.
|
|
154
|
-
Learn more about the [Operations History](../MasteryTrack/BuildingUserExperiences/DocumentTools/OperationHistory) and other document tools you get for free.
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
### 5.1 Create a to-do list
|
|
158
|
-
|
|
159
|
-
Now, move back to your local drive and create a to-do list. Add a few to-dos that are on your mind. You'll see a statistics widget that counts the open to-dos.
|
|
160
|
-
|
|
161
|
-
### 5.2 Create a specific to-do drive app
|
|
162
|
-
|
|
163
|
-
:::tip What is a 'drive' at Powerhouse?
|
|
164
|
-
A **drive** is a folder to store and organize your documents in. Powerhouse offers the ability to build customized 'Drive Apps' for your documents. Think of a Drive App as a specialized lens—it offers **different ways to visualize, organize, and interact with** the data stored within a drive, making it more intuitive and efficient for specific use cases. To learn more, visit [Building A Drive App](/academy/MasteryTrack/BuildingUserExperiences/BuildingADriveExplorer)
|
|
165
|
-
:::
|
|
166
|
-
|
|
167
|
-
Since your previous to-do list was created inside a local drive with a general-purpose drive explorer, it didn't look particularly special.
|
|
168
|
-
|
|
169
|
-
- Now let's create a new drive by clicking the new drive icon. In the **Drive App** field, select 'To-do Drive App'.
|
|
170
|
-
- Now move into the drive you've just created and create a new to-do list by clicking the button at the bottom of the page.
|
|
171
|
-
- Add a new set of random to-dos
|
|
172
|
-
- After closing the document, look at the To-do Drive App interface. You'll see that it tracks your tasks and displays a progress bar.
|
|
182
|
+
Now, return to your to-do list and make some additional changes. You'll notice that these operations are now signed with your Renown identity, making every action traceable and verifiable in the operations history.
|
|
173
183
|
|
|
174
184
|
<figure className="image-container">
|
|
175
|
-
<img src={require("./images/
|
|
176
|
-
<figcaption>
|
|
185
|
+
<img src={require("./images/OperationsHistorySignature.png").default} alt="Operation History Signature" />
|
|
186
|
+
<figcaption>Your DID is now signing the operations that are being added to the history.</figcaption>
|
|
177
187
|
</figure>
|
|
178
188
|
|
|
179
|
-
This is the power of Drive Apps. They offer a customized interface that works well with the different documents inside your drive. Read more about drive apps in the Mastery Track: [Drive Apps and Drive Explorers](/academy/MasteryTrack/BuildingUserExperiences/BuildingADriveExplorer).
|
|
180
189
|
## Step 6: Export a document
|
|
181
190
|
|
|
182
191
|
Export the document as a `.phd` (Powerhouse Document) file using the export button in the document toolbar at the top. In this toolbar, you will find all available functionality for your documents. The `.phd` file can be sent through any of your preferred channels to other users on your network.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Create a to-do list document
|
|
1
|
+
# Create a new to-do list document
|
|
2
2
|
|
|
3
3
|
## Overview
|
|
4
4
|
This tutorial guides you through creating a simplified version of a 'Powerhouse project' for a **To-do List**.
|
|
@@ -18,52 +18,32 @@ Create a new Powerhouse project with a single command:
|
|
|
18
18
|
```bash
|
|
19
19
|
ph init
|
|
20
20
|
```
|
|
21
|
-
<details>
|
|
22
|
-
<summary>How to use different branches</summary>
|
|
23
|
-
|
|
24
|
-
When installing or using the Powerhouse CLI commands you are able to make use of the dev & staging branches.
|
|
25
|
-
These branches contain more experimental features then the latest stable release the PH CLI uses by default.
|
|
26
|
-
They can be used to get access to a bugfix or features under development.
|
|
27
|
-
|
|
28
|
-
| Command | Description |
|
|
29
|
-
|---------|-------------|
|
|
30
|
-
| **pnpm install -g ph-cmd** | Install latest stable version |
|
|
31
|
-
| **pnpm install -g ph-cmd@dev** | Install development version |
|
|
32
|
-
| **pnpm install -g ph-cmd@staging** | Install staging version |
|
|
33
|
-
| **ph init** | Use latest stable version of the boilerplate |
|
|
34
|
-
| **ph init --dev** | Use development version of the boilerplate |
|
|
35
|
-
| **ph init --staging** | Use staging version of the boilerplate |
|
|
36
|
-
| **ph use** | Switch all dependencies to latest production versions |
|
|
37
|
-
| **ph use dev** | Switch all dependencies to development versions |
|
|
38
|
-
| **ph use prod** | Switch all dependencies to production versions |
|
|
39
|
-
|
|
40
|
-
Please be aware that these versions can contain bugs and experimental features that aren't fully tested.
|
|
41
|
-
</details>
|
|
42
21
|
|
|
43
22
|
## Before you begin
|
|
44
23
|
1. Open your terminal (either your system terminal or IDE's integrated terminal)
|
|
45
|
-
2.
|
|
24
|
+
2. Optionally, create a folder first to keep your Powerhouse projects:
|
|
46
25
|
|
|
47
26
|
```bash
|
|
48
|
-
|
|
27
|
+
mkdir ph-projects
|
|
28
|
+
cd ph-projects
|
|
49
29
|
```
|
|
50
30
|
3. Ensure you're in the correct directory before running the `ph init` command.
|
|
51
31
|
In the terminal, you will be asked to enter the project name. Fill in the project name and press Enter.
|
|
52
32
|
```bash
|
|
53
|
-
you@yourmachine:~/
|
|
33
|
+
you@yourmachine:~/ph-projects % ph init
|
|
54
34
|
|
|
55
|
-
? What is the project name? ‣
|
|
35
|
+
? What is the project name? ‣ getting-started
|
|
56
36
|
```
|
|
57
37
|
|
|
58
38
|
Once the project is created, you will see the following output:
|
|
59
39
|
```bash
|
|
60
|
-
Initialized empty Git repository in /Users/
|
|
40
|
+
Initialized empty Git repository in /Users/you/ph-projects/getting-started/.git/
|
|
61
41
|
The installation is done!
|
|
62
42
|
```
|
|
63
43
|
|
|
64
44
|
Navigate to the newly created project directory:
|
|
65
45
|
```bash
|
|
66
|
-
cd
|
|
46
|
+
cd getting-started
|
|
67
47
|
```
|
|
68
48
|
Once in the project directory, run the `ph connect` command to start a local instance of the Connect application. This allows you to start your document model specification document.
|
|
69
49
|
Run the following command to start the Connect application:
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Write the document specification
|
|
2
2
|
|
|
3
3
|
In this tutorial, you will learn how to define the specifications for a **To-do List** document model within the Connect application using its GraphQL schema, and then export the resulting document model specification document for your Powerhouse project.
|
|
4
4
|
If you don't have a document specification file created yet, have a look at the previous step of this tutorial to create a new document specification.
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
@@ -16,7 +16,7 @@ Let's start with step 1 & 2 in the next section of the tutorial!
|
|
|
16
16
|
|
|
17
17
|
To create a new Powerhouse Document Model Library project, you can use the `ph init` command in your terminal. This command will create a new project in the current directory.
|
|
18
18
|
|
|
19
|
-
## Create new Powerhouse document model
|
|
19
|
+
## Create new Powerhouse document model project
|
|
20
20
|
|
|
21
21
|
:::info
|
|
22
22
|
This command will create a new project in the current directory.
|
|
@@ -24,8 +24,10 @@ You can run the command in the terminal window of your OS or you open the newly
|
|
|
24
24
|
You will need VSCode later in the tutorial once you have generated the document model.
|
|
25
25
|
Make sure the terminal reflects the directory where you want to create the new project.
|
|
26
26
|
To open a directory in a terminal, you use the cd command to change your current directory. The cd command takes an argument, usually the name of the folder you want to move to, so the full command is
|
|
27
|
+
|
|
27
28
|
```bash
|
|
28
|
-
|
|
29
|
+
mkdir ph-projects
|
|
30
|
+
cd ph-projects
|
|
29
31
|
```
|
|
30
32
|
This essentially opens that folder and places you in it.
|
|
31
33
|
:::
|
|
@@ -13,7 +13,8 @@ To create a new Powerhouse Document Model Library project, you can use the `ph i
|
|
|
13
13
|
This command will create a new project in the current directory. You can run the command in the terminal window of your OS or you open the newly installed VSCode and run the command in the terminal window of VSCode.Make sure the terminal reflects the directory where you want to create the new project.
|
|
14
14
|
|
|
15
15
|
```bash
|
|
16
|
-
|
|
16
|
+
mkdir ph-projects
|
|
17
|
+
cd ph-projects
|
|
17
18
|
```
|
|
18
19
|
This essentially opens that folder and places you in it.
|
|
19
20
|
|
|
@@ -15,6 +15,22 @@ Here are the key points to understand:
|
|
|
15
15
|
- **Custom Scalars:** Besides the built-in scalars, you can define custom scalars (e.g., a Date type) if you need to handle more specific formats or validations. Powerhouse does this specific for the web3 ecosystem.
|
|
16
16
|
:::
|
|
17
17
|
|
|
18
|
+
## What are Components?
|
|
19
|
+
|
|
20
|
+
In the context of Powerhouse Builder platform, components can be thought of as reusable elements, or ready-to-use building blocks that help builders implement **document editors & viewers** with little to no effort. An important utility aspect of a component is that it serves its users as a **data input field**, providing structured ways to enter and manipulate information within your document models.
|
|
21
|
+
|
|
22
|
+
## Document Editors vs Document Viewers
|
|
23
|
+
|
|
24
|
+
Understanding the relationship between document editors and viewers is crucial for component usage:
|
|
25
|
+
|
|
26
|
+
**Document Editor**: A specific document type that is used by one or more users to make data entries and update its state. Key utility is the ability to enter data in a structured format, making it a great tool for collaboration within a group of authorized users.
|
|
27
|
+
|
|
28
|
+
**Document Viewer**: Does not allow modifications. It's a great way to inform about the state of the document type, making it a great tool for providing a broader group or public with transparent insights. Document viewers do not have to match the view of the editor one-to-one - the data presented could be framed as a specific selection, or filtered to provide desired insights.
|
|
29
|
+
|
|
30
|
+
:::tip Component Behavior in Different Contexts
|
|
31
|
+
The same component that will be used in a document viewer will have a **disabled state** (not allowed to edit documents). Document editors precede document viewers - you would start by creating a document editor and then, if needed, decide which viewer format is useful.
|
|
32
|
+
:::
|
|
33
|
+
|
|
18
34
|
## Scalars vs. General UI Components
|
|
19
35
|
|
|
20
36
|
### Scalar Components
|
|
@@ -39,6 +55,42 @@ This category includes a broader range of UI elements such as simplified version
|
|
|
39
55
|
**Location:** @powerhousedao/document-engineering/ui
|
|
40
56
|
https://github.com/powerhouse-inc/document-engineering
|
|
41
57
|
|
|
58
|
+
## Component Types Classification
|
|
59
|
+
|
|
60
|
+
Inspired by atomic design methodology, Powerhouse classifies components into the following categories:
|
|
61
|
+
|
|
62
|
+
### Fragment
|
|
63
|
+
The smallest element that combined together makes up a scalar or other simple component.
|
|
64
|
+
**Examples:** Character counter, Checkbox field, Label
|
|
65
|
+
|
|
66
|
+
### Scalar (Simple Component)
|
|
67
|
+
The simplest component that contains the basic input field for one-dimensional data type (single value).
|
|
68
|
+
**Examples:** Integer, Boolean, String, Powerhouse ID (PHID)
|
|
69
|
+
|
|
70
|
+
### Complex Component
|
|
71
|
+
Compound component that has an object/array value. It's made up of multiple scalars combined to serve a specific function.
|
|
72
|
+
**Examples:** Sidebar (tree structure navigation component with content-style navigation for hierarchical data)
|
|
73
|
+
|
|
74
|
+
### Layout Component
|
|
75
|
+
Purpose-specific container for other components like lists of other components, color layouts, sections, etc.
|
|
76
|
+
**Examples:** Homepage section layout
|
|
77
|
+
|
|
78
|
+
:::info Component Library Philosophy
|
|
79
|
+
The Powerhouse team is building a Component library with a wide range of components embedding best UX practices & key functionality. This library establishes standards and best practices for building documents while fast-tracking the building process through facilitation of the most basic & useful component types.
|
|
80
|
+
:::
|
|
81
|
+
|
|
82
|
+
## Component Behavior & UX Principles
|
|
83
|
+
|
|
84
|
+
Besides the ability to input data, components have another crucial utility: they describe the mechanism of user interaction through implementing a defined set of behavior rules.
|
|
85
|
+
|
|
86
|
+
**Best Practices for Component Behavior:**
|
|
87
|
+
- Implementing behaviors at a component level is much more efficient than at the document level
|
|
88
|
+
- Good component behavior feels natural to the user and is easily understood
|
|
89
|
+
- Components should be intuitive and not require additional tutorials or explanations
|
|
90
|
+
- Start with the most simple/basic behaviors first, then layer additional behaviors on top
|
|
91
|
+
- Keep behaviors as simple as needed - less is more
|
|
92
|
+
|
|
93
|
+
|
|
42
94
|
## Exploring Components with Storybook
|
|
43
95
|
|
|
44
96
|
We use Storybook as an interactive catalog for our design system components. It allows you to visually explore each component, interact with different states, and understand how to integrate them into your projects. [https://storybook.powerhouse.academy](https://storybook.powerhouse.academy)
|
|
@@ -14,7 +14,7 @@ You need to install the Powerhouse CLI (`ph-cmd`) to create and manage Powerhous
|
|
|
14
14
|
|
|
15
15
|
## Prerequisites
|
|
16
16
|
- node.js 22 installed
|
|
17
|
-
- pnpm package manager installed
|
|
17
|
+
- pnpm package manager 10 installed
|
|
18
18
|
- Terminal or command prompt access
|
|
19
19
|
|
|
20
20
|
## Solution
|
|
@@ -169,7 +169,7 @@ You need to access experimental features, bugfixes, or development versions of P
|
|
|
169
169
|
|
|
170
170
|
## Prerequisites
|
|
171
171
|
- Terminal or command prompt access
|
|
172
|
-
- pnpm package manager installed
|
|
172
|
+
- pnpm package manager 10 installed
|
|
173
173
|
- Node.js 22 installed
|
|
174
174
|
|
|
175
175
|
## Solution
|
package/package.json
CHANGED
package/src/css/custom.css
CHANGED
|
@@ -157,6 +157,21 @@ a {
|
|
|
157
157
|
color: #003d7a; /* darker blue on hover */
|
|
158
158
|
}
|
|
159
159
|
|
|
160
|
+
/* Dark mode specific styles for better readability */
|
|
161
|
+
[data-theme='dark'] .docs-doc-page .theme-doc-markdown a,
|
|
162
|
+
[data-theme='dark'] .markdown a,
|
|
163
|
+
[data-theme='dark'] details a,
|
|
164
|
+
[data-theme='dark'] .theme-doc-markdown details a {
|
|
165
|
+
color: #66b3ff !important; /* lighter blue for dark mode */
|
|
166
|
+
}
|
|
167
|
+
|
|
168
|
+
[data-theme='dark'] .docs-doc-page .theme-doc-markdown a:hover,
|
|
169
|
+
[data-theme='dark'] .markdown a:hover,
|
|
170
|
+
[data-theme='dark'] details a:hover,
|
|
171
|
+
[data-theme='dark'] .theme-doc-markdown details a:hover {
|
|
172
|
+
color: #99ccff !important; /* even lighter blue on hover for dark mode */
|
|
173
|
+
}
|
|
174
|
+
|
|
160
175
|
/* Reset styling for navigation elements, category pages, and utility links */
|
|
161
176
|
.breadcrumbs a,
|
|
162
177
|
.pagination-nav a,
|