Closed Jernik closed 4 years ago
I think this is already possible, more or less, in individual commands, just with a little bit of extra lifting. I think adding a StateService to make it a bit easier is a good idea. Making it so it is isolated like state per user per channel (per guild)
that individual commands can manage how they want, sort of like LocalDB or cookies per website (that different pages use different keys). It's probably good to define an interface sooner rather than later so it can eventually be swapped out for Redis or a DB in one place instead of letting it get too spread out.
Wdyt?
I think having a big cache with a key of (user, channel, guild, commandId)->(Context), where Context is... something that commands can define for themselves makes sense
As part of reworking, I added DI and the framework for caching, which allowed me to make an example command for future use. See https://github.com/Awkewainze/FriendBot/blob/main/src/commands/multipartCommandExample.ts
The example I use has a bit more manual individual key/value pairing, but for sure you could just store the entire Context and serialize/deserialize it on each instance of command run.
Actually, nvm, I can make this better, probably with more of a React style, setState
and setPersistentState
methods. Will get something else soon. I miss sleep.
Bam, better example 😎 https://github.com/Awkewainze/FriendBot/blob/main/src/commands/simpleMultipartExample.ts
I don't know of any specific examples that I want, but it's worth considering adding support for the project for FriendBot to ask for more information from a user or something similar and then the next message from that user is parsed in the context or the original command