My idea is to decouple stuff from each other, separate the view from the data operations, make logs and PRISM handlers return data transformed into objects and then views/discord handles decide what to do with it.
We can do it using current model and building on top, which might create trouble in the future when we'll want to add more functionalities to one single event (say a roundend event or mapvote) - then we'll have to add into the handlers.
We can also do it using pools (listening for events emited by data handles), which is different from the current approach by allowing multiple actions to happen after received event. This is a common way of handling live event streams.
We should also simplify the external interaface of PRISM, for it to handle different operations.
PRISM.writePrism2('say', `!unbanid ${hashId}`)
// This should become
PRISM.unban(hashId)To discuss.
My idea is to decouple stuff from each other, separate the view from the data operations, make logs and PRISM handlers return data transformed into objects and then views/discord handles decide what to do with it.
We can do it using current model and building on top, which might create trouble in the future when we'll want to add more functionalities to one single event (say a roundend event or mapvote) - then we'll have to add into the handlers.
We can also do it using pools (listening for events emited by data handles), which is different from the current approach by allowing multiple actions to happen after received event. This is a common way of handling live event streams.
We should also simplify the external interaface of PRISM, for it to handle different operations.
To discuss.