Lots of functions missing interface to request
Opened this issue · 11 comments
I need to be able to set headers etc. in the request. Many functions in solid-client are missing this ability.
e.g. https://github.com/solid/solid-client/blob/master/src/solid/profile.js#L619-L658
Those are at a higher level of abstraction than setting up request headers, though. The idea with these is that you set up the web client (including whatever custom headers) once, and the solid-client functions just use that.
It's quite possible that one would need to use different headers on each request.
It's possible, sure. It doesn't quite seem right, from a design standpoint. If one is asking a developer to manually juggle http headers with each function call, something about that level of abstraction is not right.
The interface you export in solid-client prevents the developer from "setting up the web client (including whatever custom headers) once", since it actually injects the web client into the profile for you
Which means you can override it centrally, once, and that propagates to the various components (like the profile-related functions).
It's possible, sure. It doesn't quite seem right, from a design standpoint. If one is asking a developer to manually juggle http headers with each function call, something about that level of abstraction is not right.
But what if you need to make requests to different servers using different authorization bearer tokens? Are you supposed to initialize the Solid client every time?
Which means you can override it centrally, once, and that propagates to the various components (like the profile-related functions).
No, you can't, not the way this is currently built. Your webclient abstraction is constructed by the index module (not by a client developer) and injected into the profile. Unless you're suggesting that developers should go create their own web client object, and mutate the profile object directly with that new webclient object, which is an unacceptable interface.
@deiu no, that would be even worse than manually having to pass in custom headers. We'd need to add a "token by intended relying party" store to the web client, so that stuff is handled automatically.
@dan-f not at all suggesting that. They can customize the web client directly from the solid-client instance, like solid.web.whatever = ...
@dan-f not at all suggesting that. They can customize the web client directly from the solid-client instance, like solid.web.whatever = ...
No, they can't. The closures you set up on those linked functions mean that solid.web = ... will not have that effect.
The point is that I cannot set headers where I want to using solid-client. Even if I could mutate the web client object, there's no data on that object which specifies headers to be used on each request.
I think you're mis-understanding the situation. A reference to the web client is passed into those linked functions. And that same reference is set on the solid-client instance, so modifying it there will reflect inside those functions.
there's no data on that object which specifies headers to be used on each request
True, which is a different issue. That's the bit that needs to be added, but my point in this discussion is that it needs to be added centrally, on the web client level, and not in each function.