-
Notifications
You must be signed in to change notification settings - Fork 935
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
Enable jsonschema support in debug page for annotated too #5253
base: main
Are you sure you want to change the base?
Conversation
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.
I'm not super familiar with annotated service but tried making this PR, as in my go implementation I'm also trying to add support for REST, and want it to also have autocomplete :)
https://github.com/curioswitch/go-docs-handler/pull/2/files
I tried running AnnotatedDocServiceTest
and could get completion in the JSON method, so AFAICT this should be pretty nice for annotated users if the change makes sense.
/** | ||
* Creates a new instance. | ||
*/ | ||
public MethodInfo(String serviceName, String name, |
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.
I have added yet more craziness to this file. Hopefully not for this PR, but probably need to get a builder in
@@ -130,7 +152,6 @@ public MethodInfo(String serviceName, String name, | |||
|
|||
this.returnTypeSignature = requireNonNull(returnTypeSignature, "returnTypeSignature"); | |||
this.parameters = ImmutableList.copyOf(requireNonNull(parameters, "parameters")); | |||
assert !useParameterAsRoot || this.parameters.size() == 1; |
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.
I could tweak the assertion to look for a single root parameter but it seemed like overkill
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5253 +/- ##
============================================
+ Coverage 73.95% 74.11% +0.15%
- Complexity 20115 20982 +867
============================================
Files 1730 1819 +89
Lines 74161 77324 +3163
Branches 9465 9879 +414
============================================
+ Hits 54847 57308 +2461
- Misses 14837 15365 +528
- Partials 4477 4651 +174 ☔ View full report in Codecov by Sentry. |
Hello - I think things were hectic with release when sending this but is it possible to get a review now? Thanks |
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.
Although I do think the current change will cover most cases, let me think a little more of a way to filter out false-positive cases
@@ -130,6 +130,7 @@ private ObjectNode generate(MethodInfo methodInfo) { | |||
methodFields = ImmutableList.of(); | |||
} else { | |||
methodFields = structInfo.fields(); | |||
root.put("useParamaterAsRoot", true); |
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.
root.put("useParamaterAsRoot", true); | |
root.put("useParameterAsRoot", true); |
methodInfos.computeIfAbsent(serviceClass, unused -> new HashSet<>()).add(methodInfo); | ||
}); | ||
List<FieldInfo> fieldInfos = fieldInfos(service.annotatedValueResolvers()); | ||
boolean useParamaterAsRoot = false; |
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.
boolean useParamaterAsRoot = false; | |
boolean useParameterAsRoot = false; |
|
||
const hasJsonSchema = useMemo(() => { | ||
const schema = jsonSchemas.find((s: any) => s.$id === method.id); | ||
if (schema && (schema.useParamaterAsRoot || forceJsonSchema)) { |
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.
if (schema && (schema.useParamaterAsRoot || forceJsonSchema)) { | |
if (schema && (schema.useParameterAsRoot || forceJsonSchema)) { |
@@ -130,7 +152,6 @@ public MethodInfo(String serviceName, String name, | |||
|
|||
this.returnTypeSignature = requireNonNull(returnTypeSignature, "returnTypeSignature"); | |||
this.parameters = ImmutableList.copyOf(requireNonNull(parameters, "parameters")); | |||
assert !useParameterAsRoot || this.parameters.size() == 1; |
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.
Note: the following is also a valid method that has multiple resolvers, but uses headers/query params instead of the body to fill the bean.
Since the last non-param/query will be used, in the worst case it is possible that wrong autocomplete/recommendations are done.
@Post("/bean2")
public HttpResponse bean2(@RequestObject JsonRequest jsonRequest, CompositeBean compositeBean1) {
return HttpResponse.of("world");
}
Having said this, I'm not sure if there is a non-trivial way to intelligently find the parameter that should be used as the body.
Let me think about this a little more..
Hey, sorry about the late update. So talked with the team and a couple of ideas: I think one of the concerns was autocompletion for the wrong schema which may confuse users.
The downsides of this idea was that
We accept that we can't know for sure how exactly the user would like to deserialize the request. For this reason, we disable the monaco validate option for annotated services, and just offer autocompletion for all parameters that seem like a request body as a best-effort.
And the user can choose which This approach probaby requires a lot of changes. cc. @line/dx let me know if I missed/misunderstood any ideas. Alternatively, if all of these approaches sounds like too much, I think it's also reasonable to add client-side changes only for this iteration. (since I heard that you are working on a separate server implementation which also tries to use the doc service) |
Haven't forgotten about this issue, but there's a lot going on at the moment 😅 Let me try to brainstorm a little more before the next release |
@jrhee17 Sorry for letting this PR be stale, haven't been heads-down in Java enough to give a deep thought on it and it hasn't been on my critical path yet. Happy to make some changes though if we decide on an approach to take. |
Motivation:
Annotated services can define JSON bodies which benefit from autocomplete.
Modifications:
Query for JSON schema for annotated services too when there is a body parameter by setting it as the "root parameter", have docs client always render with autocomplete when there is a root parameter regardless of service type.
Result:
Annotated services with a request body can take advantage of autocomplete