Skip to content
This repository has been archived by the owner on Sep 30, 2020. It is now read-only.

Architecture overview

Capuccino edited this page Aug 20, 2017 · 2 revisions

Clara is based of the idea of modularization, that is, no command module or a specific extension is hardcoded to be dependent to the main bot code and can be decoupled and repurposed for other means. A perfect example of that is the Logger class.

A TL;DR (if you don't want to read all of it)

Clara, by design, has bot-agnostic modules and can be redistributed as a seperate NPM package.

An example of this is Project Sagiri

It is also capable of reloading, turning off, loading commands without turning the bot itself off.

Commands

Commands is the most focused part of Clara's systems. Every command can be hot reloaded, unloaded and loaded without regression to the bot core and each command object is isolated to each other.

Preloading and command object loading

Commands are scanned for their package.json which declares their dependencies. All of the commands' dependencies are resolved and cached for reuse. Once all of the commands' dependencies are satisifed, the CommandHolder class is responsible on loading the command objects and making them accessible through specific keywords set out for them to execute. Any failing commands are unloaded and logged for the reason they won't load. If the user wants to unload a command, the CommandHolder unloads that command object so it won't be accessible until reloaded.

Bot extensions

Most of the utilities and extensions (Context override for the Eris#Message class, Logger, Utils, etc.) can be decoupled from the main code and be reused for other projects. There would be no regressions whilst being decoupled because they were designed to be reusable.