-
Notifications
You must be signed in to change notification settings - Fork 17
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
feat(js): group parameters #46
Conversation
* @param {{paramName}} {{^description}}The {{paramName}}{{/description}}{{#description}}{{{description}}}{{/description}} | ||
{{/allParams}} | ||
{{! We group parameters under an object if there are more than 5}} | ||
{{^allParams.5}} |
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 would say this is create more inconsistencies than needed, we should stick to one coding style imo. Wdyt?
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.
Like having everything under an object?
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.
yes
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.
Hm.. this indeed creates inconsistencies but only for a few methods, while having objects everywhere would impact all the methods.
On a side note, this also creates inlined types (since it does not come from the specs), and would make the client much more verbose
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.
@bodinsamuel should we postpone the merge of this PR until further discussion?
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.
We can postpone if there is strong pushback on the team, otherwise if the team agreed with > 5
you can merge
(I personally stand with object all the time but it's just my opinion)
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'll ask in core-apiclients
after xmas, this is not urgent anyway
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.
LGTM
1e1749c
to
134a386
Compare
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.
LGTM 💯
clients/algoliasearch-client-javascript/client-analytics/src/analyticsApi.ts
Show resolved
Hide resolved
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.
A couple comments, looking good !
@@ -2,7 +2,7 @@ | |||
{ | |||
"method": "browse", | |||
"testName": "get browse results with minimal parameters", | |||
"parameters": ["indexName"], | |||
"parameters": [{ "indexName": "indexName" }], |
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.
Should the parameters be an object instead of an array if we always pass one object ?
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.
Since parameters will diverge in every languages, yes.
I'd say we should have an object with language: parameters
.
(We could also generate code snippets later from this file, since we have the usage of each methods for each languages 🤔 )
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.
The people writing the CTS shouldn't care about the langage, I think the template should handle all the details (and the generator script can help by providing a parametersArray
for example)
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.
Good point, also makes the thing a bit magic, but it should be easier to handle it in the templates.
@@ -2575,7 +2575,7 @@ public DeletedAtResponse deleteBy( | |||
/** | |||
* Delete all records matching the query. Remove all objects matching a filter (including geo | |||
* filters). This method enables you to delete one or more objects based on filters (numeric, | |||
* facet, tag or geo queries). It doesn’t accept empty filters or a query. | |||
* facet, tag or geo queries). It doesn't accept empty filters or a query. |
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.
Can you change {{&description}}
to {{{description}}}
(I'm not sure what the &
does) in api-single.mustache
to remove the '
?
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 can also use & to unescape a variable: {{& name}}. This may be useful when changing delimiters (see "Set Delimiter" below).
Not sure what is our use here 🤔
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.
Yeah I don't know, we are not using delimiters yet.
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.
Actually, adding the &
removed the &#..
escaped chars, so I've added it to the Java template.
getRecommendations({ | ||
getRecommendations, | ||
}: GetRecommendationsProps): Promise<GetRecommendationsResponse> { |
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.
Since GetRecommendations
is already an object, we can pass it directly, I find it weird to write getRecommendations({ getRecommendations: {
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.
Indeed, but it requires some investigation on how to do so via mustache files, since we can't do comparison.
We could have a special case for this client, but it's not the right way to handle it if it happens again
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.
ok 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.
(We should indeed not forget about this issue before releasing a stable client IMO, especially if it's the only case)
🧭 What and Why
🎟 JIRA Ticket: https://algolia.atlassian.net/browse/APIC-227
Changes included:
To improve our DX, we decided wrap parameters under an object which:
🧪 Test
CI :D