A very advanced robot
-
Clone this repo
-
cd bottothennpm install --no-optional -
Edit
config.jsaccording toexample.config.jsin the root directory -
Bring up a fresh postgres database with schema.sql. Seed the database with seed.sql, commenting out any modules you do not want (note: you can also !unmount them while botto is running)
-
Launch your botto with
node botto.js
Botto uses 2 types of listeners when responding to events: commands and observers.
the _commandHandler and _observerHandler both act as routing layers to call
their respective modules. The modules themselves contain the logic for whatever the
module is responsible for. This allows us to easily add/remove/hot-swap modules
without having to mess with the routing layer since the modules are pulled in
dynamically on message events.
Both commands & observers inherit from their parent class. Child modules will do whatever
work they need to, and ultimately return a respond() callback with their response. This
callback will respond with the supplied value to the designated receiver as determined by
the _*Handler (be it a channel, private message, etc). For an better understanding, check
out the observerHandler class.
Commands are explicit commands that start with the !bang syntax and are all listed
under the commands directory. Commands must follow the convention of
module name == command name. In other words, if your command trigger is
!foo [args], your command module must be named foo.js. Every command must extend
the base command class.
Note: By convention, all commands must declare a call function like so:
call(bot, opts, respond) {
// some code
}
Where opts is the options hash created in the handler and respond is a callback
to be fired with the string you wish the bot to echo to the receiver. The bot instance
itself is passed for use in admin commands and ignored otherwise. This call
function should be used to parse the incoming message and delegate to the appropriate
helper functions.
Admin commands act as normal !bang prefixed commands, but only respond to
users who are declared as global or channel-specific admins in config.js.
Observers are triggered when an observable event happens (a keyword or nickname is
mentioned, for example). Each observer instance must declare a matching RegEx in its
constructor which it will trigger upon matching incoming message events. Each observer must
extend the base observer class. Like commands, each observer
must also declare a call function:
call(opts, respond) {
// some code
}
If you need an observer to fire on every message event, for example building a cache of
all recent messages, you should use a regex that captures any message sent: /.*/
Enter psql prompt with psql -d botto.
Import the schema (from psql) with \i db/schema.sql. Old tables will be skipped.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent