Customize Piece loading strategy

Hello all 👋 🙂 I would like to customize the strategy by which Sapphire enumerates and loads pieces - specifically Commands, at least to start with. TL;DR: I'm wondering how to make the CommandStore instance use a custom ILoaderStrategy (or specifically, LoaderStrategy subclass with a customized walk() override)? I have come up with an approach, but it seems inelegant any way I cut it - mostly for copying and pasting all of CommandStore into a new class verbatim just to modify the constructor body - or using any number of hacks to add or invoke CommandStore's functionality on my class. This would be my effort to get around the inability to pass arguments through CommandStore to AliasStore - e.g. being unable to simply do this:
export class MyCommandStore extends CommandStore {
public constructor() {
super({ strategy: new MyLoaderStrategy() });
}
}
export class MyCommandStore extends CommandStore {
public constructor() {
super({ strategy: new MyLoaderStrategy() });
}
}
Am I overlooking a more simple or elegant solution? Thank you for you time :)
5 Replies
A Dapper Raccoon
A Dapper RaccoonOP•4mo ago
Huh... I guess I might be able to reassign CommandStore.defaultStrategy prior to initialization as well? The property's comment sorta hints to me that this might be a canonical solution? If this is the case, where would be a good place to do so - perhaps src/lib/setup.ts?
Favna
Favna•4mo ago
Can you explain why you want to customize it? Because I suspect you may be overengineering it.
A Dapper Raccoon
A Dapper RaccoonOP•4mo ago
@Boomeravna I assure you, I am overengineering it 😆 Honestly I'm just experimenting with like 8 new and unfamiliar things... Sapphire, ESM-only source, monorepos... And a means to compose my commands and subcommands from interfaces rather than directly extending the Command class. Long story short, I currently have a lot of localized packages and dependencies for... reasons, lol. I didn't want Sapphire trying to read nested node_modules and things and complaining that every little thing isn't a command. I'd also like to load pieces over the wire for funsies - but I guess virtual pieces are probably the canonical solution there... Admittedly the piece directories are probably just supposed to contain entry-points, and I'll move my logic and things out before long anyway, lol So no special necessity - mostly just some sort of foolish and incredibly disorganized academic curiosity 😂 I did write a little glob loader with some options exposed through the constructor and it works great - but sadly the only way to apply it to the default stores is by reassigning Store.defaultLoader - can't target them with different loaders, or ListenerStore at all, since it's loader is a hard-coded option. There are more possible hacks, of course - but not worth it.
Favna
Favna•4mo ago
It is possible to overwrite the loader by extending the respective classes and all that I don't know it from the top of my head though But it shouldn't be too hard to find if you open both the framework and pieces repos recommended locally in your editor
A Dapper Raccoon
A Dapper RaccoonOP•4mo ago
I was thinking about that a bit - the only thing I could figure out was to remove the default stores from the registry and re-register my variants with the same keys. I didn't try it though 😅 I appreciate your feedback here, in any case. Thank you! I think I'll stick to the defaults for now - but it was nice to see how I might do some custom stuff later

Did you find this page helpful?