You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Title says it all, think it's an addon that could either be very complex or very simple depending on what "scope" is deemed the best. I made a very simple version for work that I will attach below, but I would say it has some issues which I will discuss as well; which (if any) direction the graph addon ends up going I don't mind, think this library has a history of introducing good apis!
Code:
importtype{Wretch,WretchAddon,WretchResponseChain}from"wretch";exportinterfaceGraphAddon{/** * Executes a graph request * * @param query - The graph query * @param variables - Variables for the graph query */graph<TextendsGraphAddon,C,R>(this: T&Wretch<T,C,R>,query: string,variables?: object): Rextendsundefined ? C&WretchResponseChain<T,C,R> : R;}/** * Adds the ability to make a graph request. * */constwretchGraph: WretchAddon<GraphAddon>={wretch: {graph(query,variables={}){returnthis.post({ query, variables });},},};exportdefaultwretchGraph;
Issues:
removes the possibility of passing "url" to the post request
Almost issues:
should do post().json<type>() where it gets type passed from caller (should it add the data property itself or the caller?)
It has been a while since I have used graphql so apologies if I am mistaken, but sending / receiving graphql messages seem pretty basic and there two ways of hosting an HTTP graphql server - either a GET route with an url encoded query parameter or a POST route having a a json payload body.
Furthermore there are existing graphql clients that you can use on the frontend side which already do the work pretty well (apollo, relay).
So I do not really see the value in writing a dedicated addon for that.
Yeah graphql is very basic, haven't seen anyone using GET for graph in production ever, so I wouldn't really worry about it.
There exists a lot of graphql clients yeah, but as you've stated most of them are targeted for frontend which doesn't really give a lot of options for backend but there's also the issue of adding a lot of extra bloat for no reason (since graph is a very simple format).
I wouldn't expect a full blown out "perfect" graph implementation, the code I've supplied I'd argue would be the mvp for it, anything beyond that is just quality of life.
Title says it all, think it's an addon that could either be very complex or very simple depending on what "scope" is deemed the best. I made a very simple version for work that I will attach below, but I would say it has some issues which I will discuss as well; which (if any) direction the graph addon ends up going I don't mind, think this library has a history of introducing good apis!
Code:
Issues:
Almost issues:
post().json<type>()
where it getstype
passed from caller (should it add thedata
property itself or the caller?)Potential improvements:
graph(opts: { query: string, variables?: object }, url?: string)
?The text was updated successfully, but these errors were encountered: