Skip to content
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(javascript): add browser xhr requester #115

Merged
merged 9 commits into from
Feb 7, 2022

Conversation

shortcuts
Copy link
Member

@shortcuts shortcuts commented Feb 3, 2022

🧭 What and Why

🎟 JIRA Ticket: https://algolia.atlassian.net/browse/APIC-287

Changes included:

This PR introduces an XHR requester for browser builds and remove usage of classes in our clients.

  • Move HttpRequester to its own requester-node-http package.
  • Introduce XhrRequester in requester-browser-xhr package.
  • Inferred return type of our client, which should be handled by a generated type later if needed. (See Next steps)
  • Generated clients now output node.ts and browser.ts that will be used by our bundler to generate umd and esm files.
  • Remove usage of classes, we now return a client with generated methods.
  • Update CTS/Playground accordingly

Limitations:

Generator

As of now, we use a tweaked predefined openapi generator template, which does not allow us to provide external files or change file name.

I've then added a post-gen script for JavaScript to rename unused template files so we can use them to generate our node.ts and browser.ts build files.

  • api.mustache output is renamed to node.ts after a successful generation
  • api-all.mustache output is renamed to browser.ts after a successful generator

ESLint

Some of our parameters have the same name as the function, weirdly, the no-shadow option does not work in this case, so we only warn this error in the meantime.

Next steps:

  • Generated return type of our clients (with method typing)
  • Remove classes usage for XhrRequester and HttpRequester (this PR is already too big)
  • Bundling for umd and esm
  • (?) Create our own template to avoid the rename thing

🧪 Test

CI :D

@shortcuts shortcuts self-assigned this Feb 3, 2022
@shortcuts shortcuts removed the request for review from bodinsamuel February 3, 2022 12:24
@shortcuts shortcuts force-pushed the feat/APIC-287/javascript-xhr-requester branch from 88ab698 to 99730b8 Compare February 3, 2022 12:34
@shortcuts shortcuts force-pushed the feat/APIC-287/javascript-xhr-requester branch from 99730b8 to c2969a8 Compare February 3, 2022 12:36
@shortcuts shortcuts requested review from eunjae-lee, bodinsamuel and millotp and removed request for eunjae-lee February 3, 2022 12:43
@shortcuts shortcuts marked this pull request as ready for review February 3, 2022 12:43
tests/output/javascript/tests/client/analytics.test.ts Outdated Show resolved Hide resolved
@@ -1,26 +1,21 @@
// @ts-nocheck
import { SearchApi, EchoRequester } from '@algolia/client-search';
import { EchoRequester } from '@algolia/client-common';
import { searchApi } from '@algolia/client-search';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if we drop Api and just call it search? Seeing Api on the end users' source code might be weird.

Copy link
Member Author

@shortcuts shortcuts Feb 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we've kept the Api because the generator forces it somewhere in the template, and it also makes the naming match across all API clients.

I can try to change that if other agree on this naming cc @millotp @damcou

Copy link
Contributor

@eunjae-lee eunjae-lee Feb 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway, I was just triggering a discussion, and it doesn't have to happen in this PR, so it's not a blocker. But I'm still wondering about what others think about the renaming.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely a good point!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be fine with just search but at the same time it would collide with a lot of others interface/var that it might be counter productive

eunjae-lee
eunjae-lee previously approved these changes Feb 3, 2022
Copy link
Contributor

@eunjae-lee eunjae-lee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me!

@shortcuts shortcuts changed the title feat(js): add browser xhr requester feat(javascript): add browser xhr requester Feb 3, 2022
bodinsamuel
bodinsamuel previously approved these changes Feb 4, 2022
Copy link
Contributor

@bodinsamuel bodinsamuel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
Minor comments

NB: be mindful of those reviewing, this PR could have been split

}
] as Host[]
).concat(
shuffle([
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not do the shuffle here, this makes the get unpredictable for testing (I guess it's done like to highlight that we should not pick host directly but that's an advanced use case anyway)

baseHeaders: {
'content-type': 'application/x-www-form-urlencoded',
},
userAgent: options.userAgent,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should have a default value for userAgent otherwise people using the create<N>Api will never setup the appropriate userAgent.
And we could have a getDefaultUserAgent to make it portable/testable

Copy link
Member Author

@shortcuts shortcuts Feb 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

otherwise people using the createApi will never setup the appropriate userAgent

True, but I'm also not sure if it make sense to export the create function actually 🤔 wdyt

we could have a getDefaultUserAgent to make it portable/testable

Definitely

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes more sense like this indeed: db68d10. Is that what you had in mind?

templates/javascript/package.mustache Show resolved Hide resolved
@@ -1,26 +1,21 @@
// @ts-nocheck
import { SearchApi, EchoRequester } from '@algolia/client-search';
import { EchoRequester } from '@algolia/client-common';
import { searchApi } from '@algolia/client-search';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be fine with just search but at the same time it would collide with a lot of others interface/var that it might be counter productive

@shortcuts
Copy link
Member Author

@bodinsamuel

NB: be mindful of those reviewing, this PR could have been split

True, but at the same time it would have made reviewers check dead code (e.g. only adding xhr requester -> moving to classes), so I've went will the full package, sorry!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants