-
Notifications
You must be signed in to change notification settings - Fork 12
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
Conversation
88ab698
to
99730b8
Compare
99730b8
to
c2969a8
Compare
@@ -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'; |
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.
what if we drop Api
and just call it search
? Seeing Api
on the end users' source code might be weird.
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.
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.
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.
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.
Definitely a good point!
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 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
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.
looks good to me!
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
Minor comments
NB: be mindful of those reviewing, this PR could have been split
} | ||
] as Host[] | ||
).concat( | ||
shuffle([ |
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 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, |
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 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
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.
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
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.
Makes more sense like this indeed: db68d10. Is that what you had in mind?
clients/algoliasearch-client-javascript/requester-browser-xhr/package.json
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'; |
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 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
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! |
db68d10
🧭 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.
HttpRequester
to its ownrequester-node-http
package.XhrRequester
inrequester-browser-xhr
package.Next steps
)node.ts
andbrowser.ts
that will be used by our bundler to generateumd
andesm
files.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
andbrowser.ts
build files.api.mustache
output is renamed tonode.ts
after a successful generationapi-all.mustache
output is renamed tobrowser.ts
after a successful generatorESLint
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:
XhrRequester
andHttpRequester
(this PR is already too big)umd
andesm
🧪 Test
CI :D