search

discordjs / discord.js-modules

Modularisation of discord.js (WIP)
Apache License 2.0
192 stars 30 forks source link

chore: add client methods #38

Closed PraveshKunwar closed 3 years ago

PraveshKunwar commented 3 years ago

Please describe the changes this PR makes and why it should be merged: [WIP] Added new structures, BaseClient and Client. Client hasn't been worked on, but BaseClient is almost done.

Status and versioning classification:

PraveshKunwar commented 3 years ago

feat(client): Added client.ts with some methods. need a review on the type defs though

kyranet commented 3 years ago

Before you continue much further, have you disclosed your structure and plans with the team?

-next's structure is vastly different to any other version of discord.js, and many things haven't been set on stone yet.

For example, this Client class, we could end up using tsyringe (or a custom solution) to access to the WS and REST modules, and since containers are globally available, no Client class would be necessary (and this would reduce discord.js's memory usage as we'd remove a property from all structures). We could even end up doing something similar to what Hydra did in voice: a helper function that initialises all -next components, e.g. initialize({ ...options });.

Again, nothing of this is set on stone, our focus right now is on v13.

PraveshKunwar commented 3 years ago

Before you continue much further, have you disclosed your structure and plans with the team?

-next's structure is vastly different to any other version of discord.js, and many things haven't been set on stone yet.

For example, this Client class, we could end up using tsyringe (or a custom solution) to access to the WS and REST modules, and since containers are globally available, no Client class would be necessary (and this would reduce discord.js's memory usage as we'd remove a property from all structures). We could even end up doing something similar to what Hydra did in voice: a helper function that initialises all -next components, e.g. initialize({ ...options });.

Again, nothing of this is set on stone, our focus right now is on v13.

mm good idea. haven't thought much about it, and didn't know that we were planning on using tsyringe. we could definitely try using tsyringe. if you have any ideas on how we can start doing that, that would be pretty good.

PyroTechniac commented 3 years ago

Before you continue much further, have you disclosed your structure and plans with the team?

-next's structure is vastly different to any other version of discord.js, and many things haven't been set on stone yet.

For example, this Client class, we could end up using tsyringe (or a custom solution) to access to the WS and REST modules, and since containers are globally available, no Client class would be necessary (and this would reduce discord.js's memory usage as we'd remove a property from all structures). We could even end up doing something similar to what Hydra did in voice: a helper function that initialises all -next components, e.g. initialize({ ...options });.

Again, nothing of this is set on stone, our focus right now is on v13.

mm good idea. haven't thought much about it, and didn't know that we were planning on using tsyringe. we could definitely try using tsyringe. if you have any ideas on how we can start doing that, that would be pretty good.

He didn't specify we were using tsyringe, he just used it as an example that you should discuss stuff with the d.js dev team beforehand, as we could end up using it

PraveshKunwar commented 3 years ago

@PyroTechniac yeah mb I understood what he said, I just mistyped. Anyways, haven't thought about structure too much. Kind of continued what was already being implemented currently tbh, within the current version of discord js. Not sure how we could go about it, and also not sure what you guys were thinking. How do you guys think we could go about working on this?