-
Notifications
You must be signed in to change notification settings - Fork 490
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: replace redux-bundle with ipfs-provider #1563
Conversation
@rafaelramalho19, @lidel can one (or both) of you please review / land this ? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I have figured out everything. Now it works as expected and passes all the tests. |
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.
Thank you @Gozala, this will make http client upgrades muuuuuch easier!
Works as expected in browser and ipfs-desktop, but there is a small UI regression on Status page.
Instead of the URL of detected API (apiAddress
) the name of provider
is displayed:
|
||
try { | ||
const result = await getIpfs({ | ||
// @ts-ignore - TS can't seem to infer connectionTest option |
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.
Q: would adding TS to ipfs-provider help?
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.
Absolutely, but I would not want to block on that
Co-authored-by: Marcin Rataj <[email protected]>
Co-authored-by: Marcin Rataj <[email protected]>
Co-authored-by: Marcin Rataj <[email protected]>
This comment has been minimized.
This comment has been minimized.
@lidel I have fixed the issue reported in #1563 (review) |
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!
@olizilla @rafaelramalho19 @hacdias any concerns on your end, or ok to merge this?
}, | ||
loadHttpClientModule: () => HttpClient, | ||
providers: [ | ||
providers.httpClient({ apiAddress }) |
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.
Q: what happens when user loads webui via API port in go-ipfs, but used custom port?
Namely, webui should "just work" when loaded from http://127.0.0.1:5002/webui
(note custom port 5002
).
Old code tried current origin and logged:
Trying ipfs-api at current origin /ip4/127.0.0.1/tcp/5002/http
What we need is something like PoC below (try potentially customized apiAddress
, if that fails try current origin's root):
providers.httpClient({ apiAddress }) | |
providers.httpClient({ apiAddress }), | |
providers.httpClient({ apiAddress: window.location.origin }), |
@Gozala thoughts?
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 was under impression that ipfs-provider does that already (inline below):
// Current origin is not localhost:5001 so try with current origin info
const { location } = root
if (location && !(location.port === '5001' && location.hostname.match(/^127.0.0.1$|^localhost$/))) {
const origin = new URL(location.origin)
origin.pathname = '/'
const res = await maybeApi({
apiAddress: origin.toString(),
connectionTest,
httpClient
})
if (res) return res
}
As an aside it would be nice if ipfs-provider
had an API that was easier to introspect, e.g.
const provider = new IPFSProvider({
loadHttpClientModule: () => window.IpfsHttpClient,
loadJsIpfsModule: () => window.Ipfs,
providers: [ /* see Usage below */ ]
})
console.log(provider.strategy) // => prints out ever strategy that `provide()` will try until one succeeds.
const { ipfs } = await provider.provide()
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.
Ah, right, the fallback to origin
kicks in if apiAddress
is undefined:
// Explicit custom apiAddress provided. Only try that.
if (apiAddress) {
return maybeApi({ apiAddress, connectionTest, httpClient })
}
// fallback to origin
// Current origin is not localhost:5001 so try with current origin info
// ...
In that case disregard my comment :)
(strategy inspector for ipfs-provider is a good idea – feel free to PR, you should have write access to the repo too)
LGTM, thank you @Gozala! @rafaelramalho19 @jessicaschilling FYSA I am merging this so #1571 can switch to the new logic |
This rips out ipfs-redux-bundle and substitutes it with ipfs-provider so that we can update ipfs-http-client as needed without having to do it through ipfs-redux-bundle.
Note: I keep gettingEdit: Turns out I had to doError: Cannot find module 'ky/umd'
when runningnpm test
locally but so far have no idea what causes it.npm build
first.