Getiyo-Public/Getiyo-Developer-Documentation
1
0
Fork 0
Code Issues 6 Releases Wiki Activity

Updated sidebar and module structure

Mees van der Wijk
2025-05-27 12:55:15 +02:00
parent c08ece6dbc
commit 59dbd338b1
2 changed files with 20 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
ModuleStructure.md

@@ -1,25 +1,30 @@
# Module Structure # Module Structure
Each module in Getiyo comprises four key components: module.json, a server-side script, a user page, and optionally a control/external page. The detailed structure of each component is outlined below. You can automatically set up this file structure by using the [GetiyoModuleTool](./GetiyoModuleTool), as described in the ["Setting up a development environment]"(./ModuleEnvironment) section of the documentation. Each module in Getiyo comprises four key components: module.json, a server-side script, a user page, and optionally a control/external page. The detailed structure of each component is outlined below. You can automatically set up this file structure by using the [GetiyoModuleTool](./GetiyoModuleTool), as described in the ["Setting up a development environment]"(./ModuleEnvironment) section of the documentation.
## Module.json ## Module.json
The module.json file serves as the central configuration file for each module in Getiyo. It contains essential metadata that informs Getiyo about the module's identity, as well as the module's properties, triggers, and conditions. The [GetiyoModuleTool](./GetiyoModuleTool) can automatically generate this file for you, streamlining the setup process. However, if you want to modify or add properties, triggers, or conditions, you can refer to the module.json section in the documentation. To learn more about configuring the [module.json](./ModuleJSON) file and its various elements, consult the Module JSON section in the documentation. The module.json file serves as the central configuration file for each module in Getiyo. It contains essential metadata that informs Getiyo about the module's identity, as well as the module's properties, triggers, and conditions. The [GetiyoModuleTool](./GetiyoModuleTool) can automatically generate this file for you, streamlining the setup process. However, if you want to modify or add properties, triggers, or conditions, you can refer to the module.json section in the documentation. To learn more about configuring the [module.json](./ModuleJSON) file and its various elements, consult the Module JSON section in the documentation.
## Server-Side ## Server-Side
The server-side component of a Getiyo module is comprised of one or more TypeScript or JavaScript files, organized according to the structure outlined below. The server-side code utilizes the [ModuleServerAPI](./ModuleServerAPI), which facilitates communication with the ModuleClientAPI, file management, show control, and more. For a comprehensive overview of the ModuleServerAPI's features and capabilities, visit the [ModuleServerAPI](./ModuleServerAPI) section in the documentation. By familiarizing yourself with the API, you can better leverage its functionality to create powerful and versatile Getiyo modules. The server-side component of a Getiyo module is comprised of one or more TypeScript or JavaScript files, organized according to the structure outlined below. The server-side code utilizes the [ModuleServerAPI](./ModuleServerAPI), which facilitates communication with the ModuleClientAPI, file management, show control, and more. For a comprehensive overview of the ModuleServerAPI's features and capabilities, visit the [ModuleServerAPI](./ModuleServerAPI) section in the documentation. By familiarizing yourself with the API, you can better leverage its functionality to create powerful and versatile Getiyo modules.
``` ```
Module Root Module Root
├── server ├── server
│ ├── **/*.ts │ ├── **/*.ts
│ └── **/*.js │ └── **/*.js
``` ```
*See bottom of the page for a complete directory structure*
_See bottom of the page for a complete directory structure_
## Page ## Page
A page of a module consists of an HTML file, TypeScript (or JavaScript), and Sass (or CSS). The user page is required because it is shown as the module to a user. The following representation illustrates the typical file structure for a module page:
A page of a module consists of an HTML file, TypeScript (or JavaScript), and Sass (or CSS). The user page is **required** because it is shown as the module to a user. The other pages are outside the renderer and not required. The following representation illustrates the typical file structure for a module page:
``` ```
Module Root Module Root
├── user ├── user
│ ├── ts (Required) │ ├── ts (Required)
│ │ ├── ModuleClientAPI.d.ts │ │ ├── ModuleClientAPI.d.ts
@@ -37,24 +42,28 @@ Module Root
│ │ └── **/*.css │ │ └── **/*.css
│ └── index.html │ └── index.html
``` ```
*See bottom of the page for a complete directory structure*
The only required directory is ts, as it contains the type definitions for the API in ModuleClientAPI.d.ts. If you prefer using plain JavaScript, create a js folder, but do not remove the ts directory. Each page has access to the ModuleClientAPI which will automatically be connected to its server-side ModuleServerAPI. For a comprehensive overview of the ModuleClientAPI's features and capabilities, visit the [ModuleClientAPI](./ModuleClientAPI). section in the documentation. _See bottom of the page for a complete directory structure_
The only required directory is ts, as it contains the type definitions for the API in ModuleClientAPI.d.ts. If you prefer using plain JavaScript, create a js folder, but do not remove the ts directory. If you want to include any libraries create a lib folder and add the TypeScript, Javascript, Sass or css files their. They will automatically be included infront of your own script/style. Each page has access to the ModuleClientAPI which will automatically be connected to its server-side ModuleServerAPI. For a comprehensive overview of the ModuleClientAPI's features and capabilities, visit the [ModuleClientAPI](./ModuleClientAPI). section in the documentation.
### Control Page ### Control Page
A control page is a specialized module page accessible only to moderators or admins of a Getiyo channel. This can be used to create a live control panel for your module. It can be opened directly or loaded into the broadcast view—a page where moderators or broadcasters can arrange a controller layout with control pages from different modules. The file structure for a control page is the same as that of a user page.
A control page is a specialized module page accessible only to moderators or admins of a Getiyo channel. This can be used to create a live control panel for your module. It can be opened directly or loaded into the broadcast view—a page where moderators or broadcasters can arrange a controller layout with control pages from different modules. The file structure for a control page is the same as that of a user page.
### External Page ### External Page
An external page is a unique module page without Getiyo UI elements that can be accessed by anyone with the URL. Unlike user and control pages, external pages are not scaled or queued. The file structure for an external page is the same as that of a user page. An external page is a unique module page without Getiyo UI elements that can be accessed by anyone with the URL. Unlike user and control pages, external pages are not scaled or queued. The file structure for an external page is the same as that of a user page.
## Static Files ## Static Files
It is possible to add static files to a module build that can be used by the [ModuleServerAPI](./ModuleServerAPI) later. Simple create a `Static` directory in the root of the module environment and place files inside it to add them to the build. It is possible to add static files to a module build that can be used by the [ModuleServerAPI](./ModuleServerAPI) later. Simple create a `Static` directory in the root of the module environment and place files inside it to add them to the build.
You can include static files in a module build for later use with the [ModuleServerAPI](./ModuleServerAPI). To do so, create a `static` directory at the root of the module environment and place the files inside. This will ensure that they are added to the build. By following this approach, you can easily store and manage static assets, such as images, fonts, or other files, that your module may need for its functionality. You can include static files in a module build for later use with the [ModuleServerAPI](./ModuleServerAPI). To do so, create a `static` directory at the root of the module environment and place the files inside. This will ensure that they are added to the build. By following this approach, you can easily store and manage static assets, such as images, fonts, or other files, that your module may need for its functionality.
## Example complete file structure ## Example complete file structure
``` ```
Module Root Module Root
├── user ├── user
│ ├── ts (Required) │ ├── ts (Required)
│ │ ├── ModuleClientAPI.d.ts │ │ ├── ModuleClientAPI.d.ts
@@ -110,4 +119,4 @@ Module Root
│ └── **/*.* │ └── **/*.*
├── .dist ├── .dist
└── module.json └── module.json
``` ```

1
_Sidebar.md

@@ -18,7 +18,6 @@
- [Important Principals](./ModuleServerAPIPrincipals) - [Important Principals](./ModuleServerAPIPrincipals)
- [Client](./ModuleServerAPIClient) - [Client](./ModuleServerAPIClient)
- [Property](./ModuleServerAPIProperty) - [Property](./ModuleServerAPIProperty)
- [ModuleData](./ModuleServerAPIModuleData)
- [Libs](./ModuleServerAPILibs) - [Libs](./ModuleServerAPILibs)
- [LibWebSocket](./ModuleServerAPILibsWebSocketLib) - [LibWebSocket](./ModuleServerAPILibsWebSocketLib)
- [Axios](https://axios-http.com/docs/instance) - [Axios](https://axios-http.com/docs/instance)