-10

docs/architecture.md

··· 1 1 - # Voidy Architecture Overview 2 2 - The Voidy architecture is a complete re-imagination of my previous bot's command and event organization architecture. 3 3 - 4 4 - Instead of relying on loose commands and events in respective top-level directories, the new approach groups all sorts of handlers into a single "module". 5 5 - 6 6 - And to allow even better handling of data, modules are managed by an even higher entity, "registries". 7 7 - 8 8 - Registries have a standalone database, used to store data of included modules. 9 9 - 10 10 - A more detailed explainer of each system can be found in the related markdown files.

-14

docs/architecture/module-level.md

··· 1 1 - # Module level architectural overview 2 2 - Modules are groups of commands, events and more. 3 3 - They export those, and provide a combined title, description and the discord name of the user who created them, using the author field. 4 4 - 5 5 - ## Modules 6 6 - Each module *can* contain a set of commands, events or subscribers. 7 7 - 8 8 - Subsribers are similar to events, but are related to the internal Lifecycle management of the bot, not Discord. 9 9 - 10 10 - These are the properties a module is required to provide: 11 11 - - name (a small and concise name for the module, e.g. "statistics") 12 12 - - description (a small text, which describes the use-cases of the module) 13 13 - - author (discord username of the module's author) 14 14 - - exports (an array of ModuleExportItem's, each containing a `source` and uninstantiated `loader` property)

-24

docs/architecture/registry-level.md

··· 1 1 - # Registry level architectural overview 2 2 - The Registry level of our architecture mainly focuses on Registries, exported Module data structure, Lifecycle events, and first database interactions, to track Registry/Module states. 3 3 - 4 4 - ## Registries 5 5 - All Registries will follow a common Registry structure. 6 6 - 7 7 - The following properties are required: 8 8 - - store (Where the raw structure of imported Modules is stored) 9 9 - 10 10 - The following methods are required: 11 11 - - collect (uses the ModuleLoader to collect the raw JSON output of all registry modules) [registry::preCollect, registry::postCollect] 12 12 - - prepare (uses various loaders to prepare Module contents, based on the Module's exports property, which exports an array of ModuleExportItem's.) [registry::prePrepare, registry::postPrepare] 13 13 - - activate (activates the registry and all contained features) [registry::preActivate, registry::postActivate] 14 14 - - unload (deactivates all modules stored in the registry and the registry itself) [registry::preUnload, registry::postUnload] 15 15 - 16 16 - 17 17 - ### ModuleExportItem 18 18 - Each Module provides a public `exports` property, which is an array of ModuleExportItem's, each ModuleFetchItem provides a `source` and a `loader` property. 19 19 - 20 20 - The `source` property is a simple path, pointing to a directory or file. 21 21 - The `loader` property takes an uninitialized loader class, which is then instantiated by the Registry, while loading the Module. 22 22 - 23 23 - 24 24 - @Todo: document registry error-notify feature, which uses a Module's author field, to notify the user of an error, directly within Discord.

-39

docs/architecture/top-level.md

··· 1 1 - # Top level architectural overview 2 2 - Anything happening before, or required by, our registries, is considered top-level architecture. 3 3 - 4 4 - This includes utilities such as the command and event handlers, which are consumed by lower levels of the system. 5 5 - 6 6 - We'll go through each of the top-level components below. 7 7 - 8 8 - ## Loaders 9 9 - Loaders are static classes, which provide utility methods for recursive loading of data from a data source, usually a directory. 10 10 - 11 11 - The constructor of a loader always takes one parameter, a string/path pointer to the desired data-source. 12 12 - 13 13 - Each loader additionally implements an asynchronous `collect` method for initial data collection. 14 14 - 15 15 - Additionally, each loader implements their own asynchronous `validate` method, which is invoked within `collect`, to validate the contents of a file, before adding it to the Loader store. 16 16 - 17 17 - Finally, loaders provide various means of exporting data in supported formats, through methods like `getJSON`, `getCSV` and more... 18 18 - 19 19 - ### Event loader 20 20 - The event loader walks a directory and stores data from any file exporting an object that follows the Event type structure. 21 21 - 22 22 - ### Command loader 23 23 - The command loader walks a directory and stores data from any file exporting an object that follows the Command type structure. 24 24 - 25 25 - ## Handlers 26 26 - Handlers are static classes, which are invoked, usually on discord events or interactions. 27 27 - 28 28 - Each handler has an `invoke` method, which is the one I mentioned calling above. 29 29 - 30 30 - The handler then queries the core registry and all other registries afterward, to find a fitting execution target. 31 31 - 32 32 - It's important to note that only repositories marked as active are taken into account. 33 33 - 34 34 - @Todo: document Handler lifecycle events 35 35 - 36 36 - ## Lifecycle manager 37 37 - The Lifecycle manager is a simple event manager with a fancy name, it stores subscribers of events in a map, with the event name as the key. 38 38 - 39 39 - Additionally, it implements two very simple methods, notify - which fires lifecycle events, and subscribe - which subscribes a callback function to an event.