What's the point of having a "container" object exported which consists of client and other stuff?
What I found kind of unique in sapphirejs is that it uses an object called
container which consists of client, stores, etc. But how is that better than just exporting client and stores directly? For example, instead of using this.container.client in command classes, why is not better to just use this.client?Solution:
Jump to solution
this.container (or container for that matter) is an object that can be extended by plugins and bots. In base @sapphire/pieces it's an object with only the PieceStore, but @sapphire/framework augments it by adding client: SapphireClient in the same way as plugin register their augmentations.
For example, if you use @sapphire/plugin-api, you'd have access to container.api. In fact, some plugins do not require discord.js or even Sapphire due to this system, which allows some projects to be library and/or framework agnostic. Another advantage to this approach is that we do not pollute the discord.js Client class with a lot of properties.
For example in my bot, I have a lot of properties:...5 Replies
Solution
this.container (or container for that matter) is an object that can be extended by plugins and bots. In base @sapphire/pieces it's an object with only the PieceStore, but @sapphire/framework augments it by adding client: SapphireClient in the same way as plugin register their augmentations.
For example, if you use @sapphire/plugin-api, you'd have access to container.api. In fact, some plugins do not require discord.js or even Sapphire due to this system, which allows some projects to be library and/or framework agnostic. Another advantage to this approach is that we do not pollute the discord.js Client class with a lot of properties.
For example in my bot, I have a lot of properties:it's Dependency Injection
Dependency injection
In software engineering, dependency injection is a programming technique in which an object or function receives other objects or functions that it requires, as opposed to creating them internally. Dependency injection aims to separate the concerns of constructing objects and using them, leading to loosely coupled programs. The pattern ensures t...
Yup, and it's the only way to have access to
Client in pieces, @sapphire/pieces is library agnostic and can be used without @sapphire/framework or even without discord.js, so it can't have a dependency of it, keeps code cleaner and we can pass more dependencies to your pieces.So the advantage of using container is that other sapphire plugins can access store and client without having to require djs or sapphire, and that's it right?
also keeping the Client class clean
yes
ideally you dont need to extend the SapphireClient anymore if you use container
which means less code