-
Notifications
You must be signed in to change notification settings - Fork 342
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make Tesla.Env maintain both request and response #196
Comments
Regarding "what if" - not much, besides the need for duplicated headers manipulation functions and a breaking change for existing codebase, not only for headers but also body. You can keep request info easily with a tiny middleware like #156. |
Thanks for the feedback! First of all, I'm aware that this will introduce breaking changes. I'm not asking for this changes right now but instead trying to discuss long-term changes for explicit and simple interface. I see Also if there is a middleware putting random headers, currently callers cannot get the actual request header, unless the remote server response it back. If the purpose of Or even further, it may be better to extract {:ok, %{body: %{"id" => id}}} = Tesla.get(client, "/hello")
{:ok, %{response: %{body: %{"id" => id}}}} = Tesla.get(client, "/hello") |
I think adding one more level of nesting ( Your points are perfectly valid, can't argue with that. However, at the same time it is quite a hypothetical discussion - I haven't yet encountered a case where having single body/headers fields caused an issue. Do you have any real-world example? |
1. middleware wrapping
|
I can't see the benefit of adding more layers - these are all private functions, used in a very limited scope. Besides, the
Can you explain this point a bit more? I don't think I completely understand what you mean.
It's hard to keep it compatible & consistent at the same time. Just adding these fields and populating them before/after request isn't enough. All calls to
I think it's the same reason why it's preferable to use simple maps/kwlists instead of deeply nested named structures - convenience. As I mentioned before, pattern matching on response is very important part of tesla's design. You may like to read 0.x to 1.0 Migration Guide to see upcoming changes. All feedback is highly appreciated.
What "style" do you mean? (Unfortunately ex_force has no README I could look at for examples) |
Thanks for the feedback! Let me try to make it clear. 1. Temporal coupling in a middleware needs both request and response(Originally I called them as middleware wrapping (I know that logger is for
This is not necessarily bad, since Tesla functions return only response data (not request data) in However, if we split request data and response data in 2. Having both
|
As we have |
Right now,
Tesla.Env
is used for two use cases - to represent a request, or a response. That makes middlewares to keep the request before runningTesla.run
if the middleware needs both information (e.g. logger).I'm just wondering what if
Tesla.Env
contains both request and response - likereq_headers
andresp_headers
, etc. likePlug.Conn
.The text was updated successfully, but these errors were encountered: