-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
[typescript] add call-time middleware support #20430
Changes from all commits
6328625
9821963
852829d
126d7e6
53c55a6
47df511
4ecba42
58f001e
fc4fd1c
80b3629
87be984
1407e0d
38b0008
cc898ee
ab57038
9ff3ec6
c380cbd
84e79b8
df9cb12
788b22c
43874f5
d717a85
9fbf9f3
f1468a4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Am I missing code here where
allMiddleware
is a reversed list of the original before?Thought: If I had two middlewares before this change that did something based on each other - for the sake of an example: one that parses JSON and one that transforms it - i.e. they couldn't be run in any order but one is dependent on the mutation of the other, then this change would mean that after an upgrade of my generated code it would now try to transform end then parse?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are correct that the middleware was not a reversed list before, so your example is correct in that by upgrading this code the order of two
post()
middleware methods would be changed.my interpretation of the current implementation is that it is not actually executing a middleware pattern
in your example, you'd have two middlewares: a ParseJSON and a TransformJSON each composed of a
pre
andpost
method. the presumed goal would be to allow the TransformJSON to wrap the ParseJSON such that it does not access non-json contentthe current call order would be
ParseJSON.pre() => TransformJSON.post() => external response => ParseJSON.post() => TransformJSON.post()
since the middleware are being called in the same order while traversing down and up the call stack, there is no implementation that allows encapsulating something like a JSON Parse on both ends. at one side, the Transform is being called on non-parsed JSON. Reversing this list correctly implements the middleware pattern to allow each middleware to send requests to and receive responses from the next middleware. Unparsed JSON would have to reach the transform middleware on either the request or response calls since they're in the same order, assuming the
pre
andpost
methods are doing inverse steps of parsing/stringifyingthe current
_options
parameter replaces the whole middleware array, so stacking middleware requires reconstructing the fullconfiguration
object, which is why i suspect this wasn't identified sooner.this would change the order, so we can push that particular change to a later release if needed, but I understood this to be a bug