@cordis/util

[zaida04]

Feature Request

A helper library that provides abstraction over writing endpoints for common routes. This will be structured in a FP manner, accepting arguments that will be concatenated into the endpoints. It will also handle having typings for each endpoint body (discord-api-types??).

Function List:

(Moved to #32)

[didinele]

My main concern with this is the internal dependency every single function would have on a RestManager or an IRouter.

Think @cordis/util would only export a "factory" function that takes one of those as a parameter and returns an object with all of the helper functions, this way we have a closure.

Either that, or we could export all the functions as usual, but use dependency injection using tsyringe and just expect the user to set a value for their manager themselves.

To clarify, the latter approach would look something like

const fetchChannel = (requiredDataHere: T) => {
  const rest = container.resolve(kRest);
  // code here
};

[zaida04]

I like the closure/factory idea. However, I don’t know enough about TSyringe in order to say whether it’s better. However considering it’s like a single thing that’s going to be passed I think returning an object of functions is better. That way we can just have the Router/REST as an accesible variable to all the functions without having to continuously write resolvers.

The next discussion should be on whether it accepts a Router or the plain REST manager. I’m in favor of having the plain REST manager passed in because using this package would render the Router as extraneous since in idea we would have 100% api coverage.

[didinele]

I like the closure/factory idea. However, I don’t know enough about TSyringe in order to say whether it’s better. However considering it’s like a single thing that’s going to be passed I think returning an object of functions is better. That way we can just have the Router/REST as an accesible variable to all the functions without having to continuously write resolvers.

Overall I think that this package is doomed to export more but just REST utils, its intended name being util, so I suppose "namespacing" things into a closure isn't that bad of an idea.

The next discussion should be on whether it accepts a Router or the plain REST manager. I’m in favor of having the plain REST manager passed in because using this package would render the Router as extraneous since in idea we would have 100% api coverage.

I def would argue that it doesn't really make Router extraneous. It's a smaller dependency and it can def have a usecase.

With that said, yeah, it doesn't really feel necessary for us to take a router as a parameter, if we wanted to use the router internally to keep the code "pretty" we'd just construct one ourselves. For sure take REST in.