@powerhousedao/academy 3.2.0-dev.3 → 3.2.0-dev.4
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 +10 -0
- package/docs/academy/01-GetStarted/home.mdx +6 -6
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/02-StandardDocumentModelWorkflow.md +3 -2
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/07-ExampleToDoListRepository.md +4 -4
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/01-BuildingDocumentEditors.md +5 -4
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/02-ConfiguringDrives.md +0 -2
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/03-BuildingADriveExplorer.md +483 -89
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-DocumentTools/{00-DocumentToolbar.md → 00-DocumentToolbar.mdx} +7 -2
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-DocumentTools/01-OperationHistory.md +3 -3
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-DocumentTools/02-RevisionHistoryTimeline.md +14 -3
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-DocumentTools/images/DocumentToolbar.png +0 -0
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-DocumentTools/images/revision-history-timeline.png +0 -0
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/08-Authorization/01-RenownAuthenticationFlow.md +14 -3
- package/docs/academy/02-MasteryTrack/04-WorkWithData/01-ReadingAndWritingThroughTheAPI.mdx +9 -15
- package/docs/academy/04-APIReferences/01-ReactHooks.md +209 -0
- package/package.json +1 -1
- package/docs/academy/04-APIReferences/01-ReactHooks +0 -98
|
@@ -2,11 +2,16 @@
|
|
|
2
2
|
|
|
3
3
|
The Document Toolbar is a central component in Powerhouse Connect, appearing at the top of every document view. It provides quick access to a variety of tools and functions designed to streamline your workflow and enhance document management.
|
|
4
4
|
|
|
5
|
+
<figure className="image-container">
|
|
6
|
+
<img src={require("./images/DocumentToolbar.png").default} alt="Document Toolbar" />
|
|
7
|
+
<figcaption>The Document Toolbar can be found at the top of any generic document.</figcaption>
|
|
8
|
+
</figure>
|
|
9
|
+
|
|
5
10
|
## Overview
|
|
6
11
|
|
|
7
12
|
The toolbar is designed to be intuitive and context-aware, offering relevant options based on the document type and your current task. Its capabilities range from basic actions to more advanced document control features.
|
|
8
13
|
|
|
9
|
-
Key functionalities
|
|
14
|
+
### Key functionalities in the future will include:
|
|
10
15
|
* **Switchboard API Access:** Access the Switchboard API via its logo in the toolbar. This opens the Apollo Studio Sandbox, pre-populating the DocumentID for your current document model. This feature is unavailable for locally stored documents.
|
|
11
16
|
* **Navigation and Versioning:** Tools for managing [document versions](/academy/MasteryTrack/BuildingUserExperiences/DocumentTools/OperationHistory), such as undo/redo, and accessing the [revision history timeline](/academy/MasteryTrack/BuildingUserExperiences/DocumentTools/RevisionHistoryTimeline).
|
|
12
17
|
* **Document Actions:** Buttons for common operations like exporting or deleting documents.
|
|
@@ -17,4 +22,4 @@ Key functionalities often include:
|
|
|
17
22
|
|
|
18
23
|
The specific set of tools available on the toolbar can be configured and may evolve as new features are introduced. This section will detail the various components and options you may encounter.
|
|
19
24
|
|
|
20
|
-
*(Detailed
|
|
25
|
+
*(Detailed information on each toolbar feature, such as "Export Button", "Title Display", "Search Functionality", "Toggle Switches", "Icon Buttons", etc., will follow here.)*
|
|
@@ -6,8 +6,8 @@ A **document model** in Powerhouse is the core unit for managing business data.
|
|
|
6
6
|
- **State schema:** What data the document contains
|
|
7
7
|
- **Operations:** What actions can modify that document
|
|
8
8
|
|
|
9
|
-
## What is operations history?
|
|
10
|
-
Every time a user edits a document, they do so by submitting a document operation (e.g., `ADD_LINE_ITEM`, `UPDATE_RECIPIENT`). These operations are:
|
|
9
|
+
## What is an operations history?
|
|
10
|
+
Every time a user edits a document, they do so by submitting a document operation or a 'command' in CQRS (e.g., `ADD_LINE_ITEM`, `UPDATE_RECIPIENT`). These operations are:
|
|
11
11
|
|
|
12
12
|
- **Appended** to the document's history
|
|
13
13
|
- **Immutable** (you never overwrite; you always append)
|
|
@@ -33,7 +33,7 @@ UPDATE_DUE_DATE(date: "2025-06-01")
|
|
|
33
33
|
|
|
34
34
|
The document's state at any time is the result of running those operations in order.
|
|
35
35
|
|
|
36
|
-
## Visualizing operations history
|
|
36
|
+
## Visualizing the operations history
|
|
37
37
|
|
|
38
38
|
### Revision list and details
|
|
39
39
|
In Connect the Powerhouse UI displays a chronologic list of all applied modifications to the document, each with a unique event ID, state hash, and commit message. You can inspect each revision for signatures and errors.
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
# Revision history timeline
|
|
2
2
|
|
|
3
|
-
The timeline feature enables users to view document history and navigate through different revisions of a document. This guide explains how to implement and customize the timeline functionality in your Powerhouse application.
|
|
3
|
+
The history timeline feature enables users to view document history and navigate through different revisions of a document. This guide explains how to implement and customize the timeline functionality in your Powerhouse application.
|
|
4
4
|
|
|
5
|
-
##
|
|
5
|
+
## How to enable the timeline feature
|
|
6
6
|
|
|
7
7
|
To enable the timeline feature in your document editor, you need to set `timelineEnabled: true` in your editor module configuration:
|
|
8
8
|
|
|
@@ -23,7 +23,18 @@ export const module: EditorModule<ToDoDocument> = {
|
|
|
23
23
|
|
|
24
24
|
This setting enables the timeline button in the document toolbar.
|
|
25
25
|
|
|
26
|
-
|
|
26
|
+
:::warning Heads Up!
|
|
27
|
+
The revision history timeline will only become visible once your document model has some operations or 'history'.
|
|
28
|
+
Add a few to-do's or some data in the model you are working on and the revision history timeline button in the Document Toolbar will be activated.
|
|
29
|
+
Click the button to see the timeline expand and see the first history 'candle' appear.
|
|
30
|
+
:::
|
|
31
|
+
|
|
32
|
+
<figure className="image-container">
|
|
33
|
+
<img src={require("./images/revision-history-timeline.png").default} alt="revision history timeline" />
|
|
34
|
+
<figcaption>Once your document has a few operations added to it's history the revision history timeline gets activated.</figcaption>
|
|
35
|
+
</figure>
|
|
36
|
+
|
|
37
|
+
## How to implement the timeline feature
|
|
27
38
|
|
|
28
39
|
### Default drive explorer
|
|
29
40
|
|
|
Binary file
|
|
Binary file
|
|
@@ -3,7 +3,10 @@
|
|
|
3
3
|
The Renown login flow leverages decentralized identity (DID) creation and the Ceramic network for credential storage and verification, ensuring secure and verifiable actions within decentralized organizations. Below is a detailed breakdown of the process, aimed at developers integrating the Renown, Connect, and Switchboard components.
|
|
4
4
|
|
|
5
5
|
### Renown in the decentralized workplace
|
|
6
|
-
Renown provides a decentralized identity and reputation hub, where users connect their Ethereum address, creating a **Decentralized Identifier (DID)** tied to their wallet.
|
|
6
|
+
Renown provides a decentralized identity and reputation hub, where users connect their Ethereum address, creating a **Decentralized Identifier (DID)** tied to their wallet.
|
|
7
|
+
|
|
8
|
+
#### Why an integrated identity solution?
|
|
9
|
+
Renown is designed to address the challenge of trust within DAOs, 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. Over time, contributors can share their pseudonymous profiles with other organizations as cryptographic resumes, helping to secure new opportunities while maintaining privacy.
|
|
7
10
|
|
|
8
11
|
### Detailed login flow
|
|
9
12
|
|
|
@@ -11,7 +14,11 @@ Renown provides a decentralized identity and reputation hub, where users connect
|
|
|
11
14
|
- The user starts by logging into Renown using their Ethereum address. This is done by signing a message with their wallet.
|
|
12
15
|
- The Ethereum key is used to create a DID (Decentralized Identifier), which uniquely represents the user without exposing their personal identity.
|
|
13
16
|
|
|
14
|
-
|
|
17
|
+
|
|
18
|
+
<figure className="image-container">
|
|
19
|
+
<img src={require("./images/ConnectAddress.png").default} alt="Connect Address" />
|
|
20
|
+
<figcaption>Connecting your Ethereum address to generate Decentralized Identifier with Renown.</figcaption>
|
|
21
|
+
</figure>
|
|
15
22
|
|
|
16
23
|
#### 2. DID creation
|
|
17
24
|
- A Decentralized Identifier (DID) is created based on the user's Ethereum key. The DID follows a specific format:
|
|
@@ -26,7 +33,11 @@ Renown provides a decentralized identity and reputation hub, where users connect
|
|
|
26
33
|
- Connect uses the newly created DID to sign operations performed by the user. For example, when a document or transaction is edited in Connect, the operation is signed with the user's DID.
|
|
27
34
|
- This ensures that every action taken within the Connect system is linked to the user's decentralized identity, maintaining transparency and accountability.
|
|
28
35
|
|
|
29
|
-
|
|
36
|
+
|
|
37
|
+
<figure className="image-container">
|
|
38
|
+
<img src={require("./images/OperationsHistory.png").default} alt="Renown Login" />
|
|
39
|
+
<figcaption>Your DID is used to sign operations performed by the user.</figcaption>
|
|
40
|
+
</figure>
|
|
30
41
|
|
|
31
42
|
#### 5. Switchboard verification
|
|
32
43
|
- Once an operation is signed by the DID through Connect, it is sent to Switchboard for verification.
|
|
@@ -4,27 +4,21 @@
|
|
|
4
4
|
|
|
5
5
|
**Switchboard** is the API interface that allows developers and data engineers to get access to the data, that is being collected through the use of document models in Connect & Fusion.
|
|
6
6
|
After structurally capturing the desired data of your formalised business processes the data can be used to build insightful experiences in external websites, drive widgets or create specific reports and dashboard in fusion.
|
|
7
|
-
**Since your document models have been defined with a GraphQL schema, you can use the same objects and fields in your queries and mutations to retrieve or write data from and to your document models.**
|
|
8
7
|
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
Your API requests are authenticated using API keys or tokens. Any request that doesn't include an API key will return an error. You can generate an API token from your Switchboard instance at any time [by logging in with your Ethereum address here](https://apps.powerhouse.io/develop/powerhouse/switchboard/user).
|
|
13
|
-
|
|
14
|
-
</details>
|
|
8
|
+
:::tip Using the state schema of your document
|
|
9
|
+
Since your document models have been defined with a GraphQL schema, you can use the same objects and fields in your queries and mutations to retrieve or write data from and to your document models.
|
|
10
|
+
:::
|
|
15
11
|
|
|
16
12
|
## Querying a document with the GraphQL API
|
|
17
13
|
|
|
18
14
|
### Starting the reactor locally
|
|
19
15
|
|
|
20
|
-
In this
|
|
16
|
+
In this tutorial we'll show how to use a **GraphQL** query to query a document model. We'll **continue on the To-do List example** from our [introduction tutorial](/academy/GetStarted/CreateNewPowerhouseProject) , but the process can be applied to any other document model.
|
|
21
17
|
To make our document model available in the Apollo Studio Sandbox we'll need to store it on a remote [Reactor](/academy/Architecture/WorkingWithTheReactor).
|
|
22
18
|
|
|
23
|
-
:::info
|
|
19
|
+
:::info What are reactors?
|
|
24
20
|
**Powerhouse Reactors** are the nodes in the network that store documents, resolve conflicts and rerun operations to verify document event histories.
|
|
25
21
|
Reactors can be configured for local storage, centralized cloud storage or on a decentralized storage network.
|
|
26
|
-
|
|
27
|
-
A reactor allows you to store multiple documents, but also host **drives** with different organisational purposes, users, access rights and more.
|
|
28
22
|
:::
|
|
29
23
|
|
|
30
24
|
Just like we can run Connect locally in studio mode we can run a remote node or a Reactor locally.
|
|
@@ -50,12 +44,12 @@ If the remote drive or Reactor isn't present yet in connect you can add it by cl
|
|
|
50
44
|
and using the localhost url to add a new drive with it's underlying reactor. Usually http://localhost:4001/d/powerhouse
|
|
51
45
|
|
|
52
46
|
Get access to an **organisations drive** instances by adding their drive to your Connect Drive navigation tree view with the help of the correct drive url.
|
|
53
|
-
|
|
47
|
+
Click the (+) to add a public drive. To add a new drive you'll have to know the correct public URL of the drive.
|
|
54
48
|
|
|
55
49
|
## Querying the state of a document
|
|
56
50
|
|
|
57
51
|
Now that we have our remote reactor and/or drive running we can store our document model on it.
|
|
58
|
-
Let's quickly create a new
|
|
52
|
+
Let's quickly create a new to-do list document to test the process.
|
|
59
53
|
|
|
60
54
|
Add to following todo's to your list:
|
|
61
55
|
- [ ] Sign up for Powerhouse
|
|
@@ -68,7 +62,7 @@ Now that we have some data in our document model we can query it through the Gra
|
|
|
68
62
|
|
|
69
63
|
### 1. The complete state of the document
|
|
70
64
|
|
|
71
|
-
Whenever you want to start a query from a document within connect you can open up
|
|
65
|
+
Whenever you want to start a query from a document within connect you can open up Switchboard by looking for the Switchboard logo in the top right hand corner of the document editor interface.
|
|
72
66
|
This will prepopulate the Apollo Studio Sandbox with the correct **DocumentID** for your document model. This feature will not be available for documents stored on local drives.
|
|
73
67
|
|
|
74
68
|

|
|
@@ -79,7 +73,7 @@ The documentation on the left hand side of the Apollo Sandbox will show you all
|
|
|
79
73
|
|
|
80
74
|
Alternatively we can just use our reactor url and endpoint to figure out the document id.
|
|
81
75
|
We can find out what the id of our document is by querying the drive for it's documents.
|
|
82
|
-
Since we only have one document in our drive it will return the id of our
|
|
76
|
+
Since we only have one document in our drive it will return the id of our to-do list document.
|
|
83
77
|
|
|
84
78
|
This example query is structured to request a document by its unique identifier (id).
|
|
85
79
|
It extracts common fields such as **id**, **name**, **documentType**, **revision**, **created**, and **lastModified**.
|
|
@@ -0,0 +1,209 @@
|
|
|
1
|
+
# React Hooks
|
|
2
|
+
|
|
3
|
+
On this page we're providing an overview of the available hooks you can make use of as a builder.
|
|
4
|
+
|
|
5
|
+
<details>
|
|
6
|
+
<summary>Need a refresher on React Hooks?</summary>
|
|
7
|
+
|
|
8
|
+
React Hooks allow you to use various React features directly within your functional components. You can use built-in Hooks or combine them to create your own custom Hooks.
|
|
9
|
+
|
|
10
|
+
**What are Custom Hooks?**
|
|
11
|
+
A custom hook is a JavaScript function whose name starts with "use" and that calls other Hooks. They are used to:
|
|
12
|
+
- Reuse stateful logic between components.
|
|
13
|
+
- Abstract complex logic into a simpler interface.
|
|
14
|
+
- Isolate side effects, particularly those managed by `useEffect`.
|
|
15
|
+
|
|
16
|
+
**Key Built-in Hooks Examples:**
|
|
17
|
+
- `useState`: Lets a component "remember" information (state).
|
|
18
|
+
- `useEffect`: Lets a component perform side effects (e.g., data fetching, subscriptions, manually changing the DOM).
|
|
19
|
+
- `useContext`: Lets a component receive information from distant parent components without explicitly passing props through every level of the component tree.
|
|
20
|
+
|
|
21
|
+
**Naming Convention:**
|
|
22
|
+
Hook names must always start with `use` followed by a capital letter (e.g., `useState`, `useOnlineStatus`).
|
|
23
|
+
|
|
24
|
+
**Rules of Hooks:**
|
|
25
|
+
1. **Only Call Hooks at the Top Level**: Don't call Hooks inside loops, conditions, or nested functions.
|
|
26
|
+
2. **Only Call Hooks from React Functions**: Call Hooks from React functional components or from custom Hooks.
|
|
27
|
+
|
|
28
|
+
It's important to note that a function should only be named and treated as a hook if it actually utilizes one or more built-in React hooks. If a function (even if named `useSomething`) doesn't call any built-in hooks, it behaves like a regular JavaScript function, and making it a "hook" offers no specific React advantages.
|
|
29
|
+
|
|
30
|
+
For more details, see the official documentation and API references of React:
|
|
31
|
+
- [Reusing Logic with Custom Hooks (react.dev)](https://react.dev/learn/reusing-logic-with-custom-hooks)
|
|
32
|
+
- [Rules of Hooks (react.dev)](https://react.dev/reference/rules/rules-of-hooks)
|
|
33
|
+
- [Powerhouse React Hooks API Reference](docs/academy/APIReferences/ReactHooks)
|
|
34
|
+
|
|
35
|
+
</details>
|
|
36
|
+
|
|
37
|
+
The idea is to make the usage of our hooks feel as simple and familiar as using `useState`.
|
|
38
|
+
The Powerhouse team is currently working on a happy path for builders that look like this:
|
|
39
|
+
|
|
40
|
+
```js
|
|
41
|
+
// in a component that only needs to read a value, you can use
|
|
42
|
+
const invoiceName = useReadDocumentField('myInvoiceDocumentId', 'name') // returns a string which is the `name`
|
|
43
|
+
// and for documents that need to update data as well, you would have
|
|
44
|
+
const updateInvoiceName = useUpdateDocumentField('myInvoiceDocumentId', 'name') // returns a function that takes a new string for the new name and dispatches the update
|
|
45
|
+
// finally, we can combine these into a single hook which works like react's useState hook returning both the value and updater function
|
|
46
|
+
const [invoiceName, updateInvoiceName] = useDocumentField('myInvoiceDocumentId', 'name')
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
// Read-only value
|
|
50
|
+
const invoiceName = useReadDocumentField('docId', 'name')
|
|
51
|
+
|
|
52
|
+
// Write-only updater
|
|
53
|
+
const updateInvoiceName = useUpdateDocumentField('docId', 'name')
|
|
54
|
+
|
|
55
|
+
// Combined read + write (like useState)
|
|
56
|
+
const [invoiceName, updateInvoiceName] = useDocumentField('docId', 'name')
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
## An overview of currently available hooks
|
|
61
|
+
|
|
62
|
+
### 1. Getting or changing data
|
|
63
|
+
These are tools you can use in your app to get or change data:
|
|
64
|
+
|
|
65
|
+
<details>
|
|
66
|
+
<summary>`useDrives`, `useDriveById(id)`: Lets you access folders (called "drives").</summary>
|
|
67
|
+
|
|
68
|
+
### Hook Name and Signature
|
|
69
|
+
The name of the hook and its TypeScript (or JavaScript) signature.
|
|
70
|
+
### Description
|
|
71
|
+
A brief explanation of what the hook does and when to use it.
|
|
72
|
+
### Usage Example
|
|
73
|
+
A code snippet showing how to use the hook in a real-world scenario.
|
|
74
|
+
### Parameters
|
|
75
|
+
A table or list describing each parameter, its type, and its purpose.
|
|
76
|
+
### Return Value
|
|
77
|
+
A description (and sometimes a table) of what the hook returns.
|
|
78
|
+
### Notes / Caveats
|
|
79
|
+
Any important details, gotchas, or best practices.
|
|
80
|
+
### Related Hooks
|
|
81
|
+
Links to other relevant hooks or documentation.
|
|
82
|
+
</details>
|
|
83
|
+
|
|
84
|
+
<details>
|
|
85
|
+
<summary>`useDocuments`, `useDocumentById(id)`: Lets you access files (called "documents").</summary>
|
|
86
|
+
|
|
87
|
+
### Hook Name and Signature
|
|
88
|
+
The name of the hook and its TypeScript (or JavaScript) signature.
|
|
89
|
+
### Description
|
|
90
|
+
A brief explanation of what the hook does and when to use it.
|
|
91
|
+
### Usage Example
|
|
92
|
+
A code snippet showing how to use the hook in a real-world scenario.
|
|
93
|
+
### Parameters
|
|
94
|
+
A table or list describing each parameter, its type, and its purpose.
|
|
95
|
+
### Return Value
|
|
96
|
+
A description (and sometimes a table) of what the hook returns.
|
|
97
|
+
### Notes / Caveats
|
|
98
|
+
Any important details, gotchas, or best practices.
|
|
99
|
+
### Related Hooks
|
|
100
|
+
Links to other relevant hooks or documentation.
|
|
101
|
+
</details>
|
|
102
|
+
|
|
103
|
+
<details>
|
|
104
|
+
<summary>`useEditorModules`, `useEditor(documentType)`: Loads the relevant editor UI/tools for a document.</summary>
|
|
105
|
+
|
|
106
|
+
### Hook Name and Signature
|
|
107
|
+
The name of the hook and its TypeScript (or JavaScript) signature.
|
|
108
|
+
### Description
|
|
109
|
+
A brief explanation of what the hook does and when to use it.
|
|
110
|
+
### Usage Example
|
|
111
|
+
A code snippet showing how to use the hook in a real-world scenario.
|
|
112
|
+
### Parameters
|
|
113
|
+
A table or list describing each parameter, its type, and its purpose.
|
|
114
|
+
### Return Value
|
|
115
|
+
A description (and sometimes a table) of what the hook returns.
|
|
116
|
+
### Notes / Caveats
|
|
117
|
+
Any important details, gotchas, or best practices.
|
|
118
|
+
### Related Hooks
|
|
119
|
+
Links to other relevant hooks or documentation.
|
|
120
|
+
</details>
|
|
121
|
+
|
|
122
|
+
<details>
|
|
123
|
+
<summary>`useDocumentModule`, `useDocumentModel(documentType)`: Gets the technical model behind a document type—like its schema and operations.</summary>
|
|
124
|
+
|
|
125
|
+
### Hook Name and Signature
|
|
126
|
+
The name of the hook and its TypeScript (or JavaScript) signature.
|
|
127
|
+
### Description
|
|
128
|
+
A brief explanation of what the hook does and when to use it.
|
|
129
|
+
### Usage Example
|
|
130
|
+
A code snippet showing how to use the hook in a real-world scenario.
|
|
131
|
+
### Parameters
|
|
132
|
+
A table or list describing each parameter, its type, and its purpose.
|
|
133
|
+
### Return Value
|
|
134
|
+
A description (and sometimes a table) of what the hook returns.
|
|
135
|
+
### Notes / Caveats
|
|
136
|
+
Any important details, gotchas, or best practices.
|
|
137
|
+
### Related Hooks
|
|
138
|
+
Links to other relevant hooks or documentation.
|
|
139
|
+
</details>
|
|
140
|
+
|
|
141
|
+
### 2. Managing selection state
|
|
142
|
+
You can now use the following to manage and track what's currently selected:
|
|
143
|
+
|
|
144
|
+
<details>
|
|
145
|
+
<summary>`useSelectedDrive` and `useSetSelectedDrive(driveId)`: Get/set the selected folder.</summary>
|
|
146
|
+
|
|
147
|
+
### Hook Name and Signature
|
|
148
|
+
The name of the hook and its TypeScript (or JavaScript) signature.
|
|
149
|
+
### Description
|
|
150
|
+
A brief explanation of what the hook does and when to use it.
|
|
151
|
+
### Usage Example
|
|
152
|
+
A code snippet showing how to use the hook in a real-world scenario.
|
|
153
|
+
### Parameters
|
|
154
|
+
A table or list describing each parameter, its type, and its purpose.
|
|
155
|
+
### Return Value
|
|
156
|
+
A description (and sometimes a table) of what the hook returns.
|
|
157
|
+
### Notes / Caveats
|
|
158
|
+
Any important details, gotchas, or best practices.
|
|
159
|
+
### Related Hooks
|
|
160
|
+
Links to other relevant hooks or documentation.
|
|
161
|
+
</details>
|
|
162
|
+
|
|
163
|
+
<details>
|
|
164
|
+
<summary>`useSelectedDocument` and `useSetSelectedDocument(documentId)`: Get/set the selected file.</summary>
|
|
165
|
+
|
|
166
|
+
### Hook Name and Signature
|
|
167
|
+
The name of the hook and its TypeScript (or JavaScript) signature.
|
|
168
|
+
### Description
|
|
169
|
+
A brief explanation of what the hook does and when to use it.
|
|
170
|
+
### Usage Example
|
|
171
|
+
A code snippet showing how to use the hook in a real-world scenario.
|
|
172
|
+
### Parameters
|
|
173
|
+
A table or list describing each parameter, its type, and its purpose.
|
|
174
|
+
### Return Value
|
|
175
|
+
A description (and sometimes a table) of what the hook returns.
|
|
176
|
+
### Notes / Caveats
|
|
177
|
+
Any important details, gotchas, or best practices.
|
|
178
|
+
### Related Hooks
|
|
179
|
+
Links to other relevant hooks or documentation.
|
|
180
|
+
</details>
|
|
181
|
+
|
|
182
|
+
## More documentation coming soon!
|
|
183
|
+
|
|
184
|
+
Global access to drive state: A top-level, possibly context-based, way to introspect and interact with any document and its state tree without manually passing things around.
|
|
185
|
+
|
|
186
|
+
Global dispatcher access: A utility or API (probably a hook or service function) where they give a document ID and get back all the relevant dispatch functions — kind of like a command palette for document ops.
|
|
187
|
+
|
|
188
|
+
### Core Hooks & Patterns
|
|
189
|
+
- useDocumentField
|
|
190
|
+
- useReadDocumentField
|
|
191
|
+
- useUpdateDocumentField
|
|
192
|
+
- useDocumentDispatch(docId): updateX, delete, ...
|
|
193
|
+
|
|
194
|
+
### Global Drive Access
|
|
195
|
+
- How to access and manipulate the global document tree
|
|
196
|
+
- How to inspect children from parent context
|
|
197
|
+
- Tree traversal utilities (if any)
|
|
198
|
+
|
|
199
|
+
### Convenience APIs
|
|
200
|
+
- Utility functions like getDispatchFunctions(docId)
|
|
201
|
+
- "Quick Start" to manipulate any document like a pro
|
|
202
|
+
|
|
203
|
+
### Working with Context
|
|
204
|
+
- DriveContext: what lives there, how to use it
|
|
205
|
+
- Example: using context to get current doc, sibling docs
|
|
206
|
+
|
|
207
|
+
### Best Practices & Patterns
|
|
208
|
+
- When to use useDocumentField vs getDispatch
|
|
209
|
+
- Composing document fields into custom logic
|
package/package.json
CHANGED
|
@@ -1,98 +0,0 @@
|
|
|
1
|
-
# React Hooks (WIP)
|
|
2
|
-
|
|
3
|
-
The idea is to make this feel as simple and familiar as using useState.
|
|
4
|
-
Happy Path would look something like this:
|
|
5
|
-
|
|
6
|
-
```js
|
|
7
|
-
// in a component that only needs to read a value, you can use
|
|
8
|
-
const invoiceName = useReadDocumentField('myInvoiceDocumentId', 'name') // returns a string which is the `name`
|
|
9
|
-
// and for documents that need to update data as well, you would have
|
|
10
|
-
const updateInvoiceName = useUpdateDocumentField('myInvoiceDocumentId', 'name') // returns a function that takes a new string for the new name and dispatches the update
|
|
11
|
-
// finally, we can combine these into a single hook which works like react's useState hook returning both the value and updater function
|
|
12
|
-
const [invoiceName, updateInvoiceName] = useDocumentField('myInvoiceDocumentId', 'name')
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
// Read-only value
|
|
16
|
-
const invoiceName = useReadDocumentField('docId', 'name')
|
|
17
|
-
|
|
18
|
-
// Write-only updater
|
|
19
|
-
const updateInvoiceName = useUpdateDocumentField('docId', 'name')
|
|
20
|
-
|
|
21
|
-
// Combined read + write (like useState)
|
|
22
|
-
const [invoiceName, updateInvoiceName] = useDocumentField('docId', 'name')
|
|
23
|
-
```
|
|
24
|
-
|
|
25
|
-
Request Translation
|
|
26
|
-
Global access to drive state: A top-level, possibly context-based, way to introspect and interact with any document and its state tree without manually passing things around.
|
|
27
|
-
Global dispatcher access: A utility or API (probably a hook or service function) where they give a document ID and get back all the relevant dispatch functions — kind of like a command palette for document ops.
|
|
28
|
-
Time spent wiring > time spent building Frustration with current DX (developer experience) — they want abstractions and helpers to just do the thing.
|
|
29
|
-
|
|
30
|
-
Core Hooks & Patterns
|
|
31
|
-
- useDocumentField
|
|
32
|
-
- useReadDocumentField
|
|
33
|
-
- useUpdateDocumentField
|
|
34
|
-
- useDocumentDispatch(docId): updateX, delete, ...
|
|
35
|
-
|
|
36
|
-
Global Drive Access
|
|
37
|
-
- How to access and manipulate the global document tree
|
|
38
|
-
- How to inspect children from parent context
|
|
39
|
-
- Tree traversal utilities (if any)
|
|
40
|
-
|
|
41
|
-
Convenience APIs
|
|
42
|
-
- Utility functions like getDispatchFunctions(docId)
|
|
43
|
-
- “Quick Start” to manipulate any document like a pro
|
|
44
|
-
|
|
45
|
-
Working with Context
|
|
46
|
-
- DriveContext: what lives there, how to use it
|
|
47
|
-
- Example: using context to get current doc, sibling docs
|
|
48
|
-
|
|
49
|
-
Best Practices & Patterns
|
|
50
|
-
- When to use useDocumentField vs getDispatch
|
|
51
|
-
- Composing document fields into custom logic
|
|
52
|
-
|
|
53
|
-
<details>
|
|
54
|
-
<summary>Refresher on React Hooks</summary>
|
|
55
|
-
|
|
56
|
-
React Hooks allow you to use various React features directly within your functional components. You can use built-in Hooks or combine them to create your own custom Hooks.
|
|
57
|
-
|
|
58
|
-
**What are Custom Hooks?**
|
|
59
|
-
A custom hook is a JavaScript function whose name starts with "use" and that calls other Hooks. They are used to:
|
|
60
|
-
- Reuse stateful logic between components.
|
|
61
|
-
- Abstract complex logic into a simpler interface.
|
|
62
|
-
- Isolate side effects, particularly those managed by `useEffect`.
|
|
63
|
-
|
|
64
|
-
**Key Built-in Hooks Examples:**
|
|
65
|
-
- `useState`: Lets a component "remember" information (state).
|
|
66
|
-
- `useEffect`: Lets a component perform side effects (e.g., data fetching, subscriptions, manually changing the DOM).
|
|
67
|
-
- `useContext`: Lets a component receive information from distant parent components without explicitly passing props through every level of the component tree.
|
|
68
|
-
|
|
69
|
-
**Naming Convention:**
|
|
70
|
-
Hook names must always start with `use` followed by a capital letter (e.g., `useState`, `useOnlineStatus`).
|
|
71
|
-
|
|
72
|
-
**Rules of Hooks:**
|
|
73
|
-
1. **Only Call Hooks at the Top Level**: Don't call Hooks inside loops, conditions, or nested functions.
|
|
74
|
-
2. **Only Call Hooks from React Functions**: Call Hooks from React functional components or from custom Hooks.
|
|
75
|
-
|
|
76
|
-
It's important to note that a function should only be named and treated as a hook if it actually utilizes one or more built-in React hooks. If a function (even if named `useSomething`) doesn't call any built-in hooks, it behaves like a regular JavaScript function, and making it a "hook" offers no specific React advantages.
|
|
77
|
-
|
|
78
|
-
For more details, see the official documentation and our API reference:
|
|
79
|
-
- [Reusing Logic with Custom Hooks (react.dev)](https://react.dev/learn/reusing-logic-with-custom-hooks)
|
|
80
|
-
- [Rules of Hooks (react.dev)](https://react.dev/reference/rules/rules-of-hooks)
|
|
81
|
-
- [Powerhouse React Hooks API Reference](docs/academy/APIReferences/ReactHooks)
|
|
82
|
-
|
|
83
|
-
</details>
|
|
84
|
-
|
|
85
|
-
### Hook Name and Signature
|
|
86
|
-
The name of the hook and its TypeScript (or JavaScript) signature.
|
|
87
|
-
### Description
|
|
88
|
-
A brief explanation of what the hook does and when to use it.
|
|
89
|
-
### Usage Example
|
|
90
|
-
A code snippet showing how to use the hook in a real-world scenario.
|
|
91
|
-
### Parameters
|
|
92
|
-
A table or list describing each parameter, its type, and its purpose.
|
|
93
|
-
### Return Value
|
|
94
|
-
A description (and sometimes a table) of what the hook returns.
|
|
95
|
-
### Notes / Caveats
|
|
96
|
-
Any important details, gotchas, or best practices.
|
|
97
|
-
### Related Hooks
|
|
98
|
-
Links to other relevant hooks or documentation.
|