Open andreasciamanna opened 1 year ago
Hi @andreasciamanna, you are right, the query param is mostly not supported at the moment (only on issues), and this would be a great addition.
As for implementation I think it would be most ergonomic if we'd extend the options type to include the query param, so in the end it would look something like this:
export declare class UserEndpoint extends BaseEndpoint {
current(): Promise<User>;
all(options?: RequestParams): Promise<ReducedUser[]>;
byId(userId: string): Promise<User>;
}
export interface QueryOptions {
query: string | Record<string, string>; // also maybe support strings as well
}
export interface RequestParams extends QueryOptions, PaginationOptions {
}
Makes sense!
I'm working on a PR.
Great project, but it lacks flexibility and seems like this project is not being developed anymore. So I made my own implementation Youtrack client, I hope it will be useful for you.
Like pagination options, a
query
parameter is accepted by many endpoints (see here.I assume that where it is not accepted, it's ignored.
Adding a
query
parameter would improve the API by a good measure as, without it, in many cases, I'm resorting to calling someall
method, dealing with pagination, and filtering the results.I'd like to suggest the following (I'll try to work on a PR).
QueryOptions
:All methods that accept as
PaginationOptions
would gain an extra optional parameter. Example:When building the request, that is, converting
paginationOptions
to query string parameters, the same will be done forqueryOptions
.I didn't go deep enough in the source code to point to a specific file, but I'll soon clone the project and give it a shot.
This, of course, unless the feature is already implemented and I've completely missed it.