@powerhousedao/academy 2.5.0-dev.25 → 2.5.0-dev.27

package/docs/academy/06-ComponentLibrary/00-DocumentEngineering.md

@@ -15,19 +15,29 @@ Here are the key points to understand:
 - **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. 
 :::
 
-In the next few chapters of our documentation, we will start with the simplest scalar components first, then move on to more complex, Powerhouse-specific components, and combine these in the Layout components.
+## Scalars vs. General UI Components
 
-## **3 types of components**
+### Scalar Components
 
-1. **Scalar Component** has a simple scalar value as input 
-    - Component, Composition of smaller UI controls (e.g. Scalar component)
-2. **Complex Component** has an object/array value 
-    - Group of components (e.g. sidebar tree view)
-3. **Layout Component** will contain other components 
-    - Containers for other components, Sections (e.g. list of other components, color layouts, etc.)
-4. **fragments Component** 
+Scalars are here to help you define custom fields in your document model schema and speed up the development process.
+There are two applications of scalar components in the document model workflow:
 
-For each of these components an implementation example will be given in our documentation. 
+1. At the **schema definition** level where you build your schema and write your GraphQL state schema.
+2. At the **frontend / react** level where you import it and place it in your UI to represent the scalar field
+
+These are specialized form components, each corresponding to a GraphQL scalar type (e.g., String, Number, Boolean, Currency, PHID). They are built on top of react-hook-form, offering out-of-the-box validation but must be wrapped with a Form component in order to work properly.
+
+**Location:** @powerhousedao/document-engineering/scalars    
+https://github.com/powerhouse-inc/document-engineering
+
+**Key Feature**: Must be used within a Form component provided by this library.
+
+### General-Purpose UI Components
+
+This category includes a broader range of UI elements such as simplified versions of the Scalar components (which don't require a Form wrapper but lack built-in validation), as well as other versatile components like Dropdown, Tooltip, Sidebar, ObjectSetTable and more. These are designed for crafting diverse and complex user interfaces.
+
+**Location:** @powerhousedao/document-engineering/ui   
+https://github.com/powerhouse-inc/document-engineering
 
 ## Exploring Components with Storybook
 
@@ -39,8 +49,15 @@ We use Storybook as an interactive catalog for our design system components. It
 2.  **Usage Snippet:** Below the demo, you'll typically find a basic code example demonstrating how to include the component in your code (e.g., `<Checkbox defaultValue label="Accept terms and conditions" />`). This provides a starting point for implementation.
 3.  **Props Table:** Further down, a table lists the properties (`props`) the component accepts. Props are like settings or configuration options. For the `Checkbox`, this table would show props like `label`, `defaultValue`, `value`, `onChange`, etc., often with descriptions of what they control.
 
+## **Storybook vs. Source Code:**
+
+Storybook serves as essential documentation and a usage guide. Our developers write Storybook "stories" to demonstrate components and document their common props. However, the **ultimate source of truth** for a component's capabilities is its actual source code (e.g., the `.tsx` file within the `@powerhousedao/document-engineering/scalars` package).
+While Storybook aims for accuracy, there might occasionally be discrepancies or undocumented props.
+
 ## Implementing a Component
 
+@callme-t
+
 Let's walk through the typical workflow for using a component from the document-engineering system, using the `Checkbox` from the [To-do List editor](/academy/GetStarted/BuildToDoListEditor).
 
 1.  **Identify the Need:** While building your feature (e.g., the To-do List editor in `editor.tsx`), you determine the need for a standard UI element, like a checkbox.
@@ -124,12 +141,6 @@ Within the project, the following import maps are available:
 - `#ui` - UI components 
 - `#graphql` - GraphQL related utilities
 
-
-## **Storybook vs. Source Code:**
-
-Storybook serves as essential documentation and a usage guide. Our developers write Storybook "stories" to demonstrate components and document their common props. However, the **ultimate source of truth** for a component's capabilities is its actual source code (e.g., the `.tsx` file within the `@powerhousedao/document-engineering/scalars` package).
-While Storybook aims for accuracy, there might occasionally be discrepancies or undocumented props.
-
 Please don't hesitate to reach out in our discord channels with any questions.    
 Happy designing! 
 

package/docs/academy/06-ComponentLibrary/02-CreateCustomScalars.md

@@ -3,13 +3,6 @@
 This tutorial provides step-by-step instructions for creating custom scalars & components, and to contributing to the document-engineering project.
 The github repo for the Document-Engineering can be found [here](https://github.com/powerhouse-inc/document-engineering/tree/main)
 
-:::info
-When contributing as an open source developer please submit a pull request to the Powerhouse team. 
-Although a design or UI for your scalar is not mandatory, it definitely helps reviewers if there's a visual reference. 
-That said, not all scalars require a dedicated UI component. 
-Some scalars, like scalar Title or scalar Description, might both map to a string and use the same UI, in this case scalars plays more semantic role than a type definition.
-:::
-
 ## Table of Contents
 
 - [Creating New GraphQL Scalars](#creating-new-graphql-scalars)
@@ -393,6 +386,14 @@ export const type = 'string'
 export const schema = z.string().datetime()
 ```
 
+:::info
+**Contributing and UI for Scalars**
+
+- **Open Source**: Please submit contributions as a pull request to the Powerhouse team.
+- **UI is Optional but Helpful**: A design or UI for your scalar isn't required, but it helps reviewers understand its purpose.
+- **Semantic Scalars**: Some scalars don't need a unique UI. For instance, `Title` and `Description` might both use a simple text input but serve a semantic role by adding specific meaning and validation to the schema.
+:::
+
 ### Tips
 
 - Always follow the naming convention: use PascalCase for scalar names

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@powerhousedao/academy",
-  "version": "2.5.0-dev.25",
+  "version": "2.5.0-dev.27",
   "homepage": "https://powerhouse.academy",
   "repository": {
     "type": "git",

package/sidebars.ts

@@ -122,7 +122,6 @@ const sidebars = {
         },
         'academy/ComponentLibrary/CreateCustomScalars',
         'academy/ComponentLibrary/IntegrateIntoAReactComponent',
-        'academy/ComponentLibrary/ScalarVsUIComponents',
       ],
     },
 
@@ -134,7 +133,6 @@ const sidebars = {
     },
     { type: 'doc', id: 'academy/Cookbook', label: 'Cookbook' },
     { type: 'doc', id: 'academy/Glossary', label: 'Glossary' },
-    { type: 'doc', id: 'academy/AIResources', label: 'AI Resources' },
     // ...add more as needed
   ],
 };

package/docs/academy/06-ComponentLibrary/04-ScalarVsUIComponents.md

@@ -1,28 +0,0 @@
-import { Tabs, TabItem } from '@theme/Tabs';
-
-# Scalar vs. UI component
-
-Scalars are here to help you define custom fields in your document model schema and speed up the development process.
-There are two applications of scalar components in the document model workflow:
-
-1. At the **schema definition** level where you build your schema and write your GraphQL state schema.
-2. At the **frontend / react** level where you import it and place it in your UI to represent the scalar field
-
-## Overview
-The Document Engineering library provides two main categories of components.
-
-https://github.com/powerhouse-inc/document-engineering
-
-### Scalar Components
-
-These are specialized form components, each corresponding to a GraphQL scalar type (e.g., String, Number, Boolean, Currency, PHID). They are built on top of react-hook-form, offering out-of-the-box validation but must be wrapped with a Form component in order to work properly.
-
-Location: @powerhousedao/document-engineering/scalars
-
-**Key Feature**: Must be used within a Form component provided by this library.
-
-### General-Purpose UI Components
-
-This category includes a broader range of UI elements such as simplified versions of the Scalar components (which don't require a Form wrapper but lack built-in validation), as well as other versatile components like Dropdown, Tooltip, Sidebar, ObjectSetTable and more. These are designed for crafting diverse and complex user interfaces.
-
-Location: @powerhousedao/document-engineering/ui