-
Notifications
You must be signed in to change notification settings - Fork 37
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
Implemented non-RDF fetch #104
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.
16d38b8
to
eb29a5f
Compare
Ah btw, I just realised that what I didn't test is whether this actually works with solid-auth-fetcher as well. Given that that was explicitly one of Kevin's concerns, probably good to do that :P Did you happen to have given that a try? |
I did, but for unauthenticated fetches only, because it works directly in command line, which is convenient as opposed to a full-blown webapp where a little more configuration is required. I have been playing around with small webapps yesterday for practice, but they use the |
Good news: with |
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.
Added one new comment for consideration, and two remarks w.r.t. the new changes. There are also a number of conversations that are marked as resolved, even though I don't see either the suggested changes or a response about why they do not apply?
src/index.test.ts
Outdated
@@ -60,6 +61,7 @@ import { | |||
// These tests aren't too useful in preventing bugs, but they work around this issue: | |||
// https://github.com/facebook/jest/issues/10032 | |||
it("exports the public API from the entry file", () => { | |||
expect(getFile).toBeDefined(); |
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.
Oh huh, seeing these two next to each other, I'm starting to wonder whether we shouldn't actually call it fetchFile
for consistency.
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.
My thinking was that there is going to be a deleteFile
and a createFile
, and getFile
is meant to only support a GET
request, so fetchFile
may sound a little too generic for people used to the fetch
API being a gateway to all HTTP
requests. However, given that we use fetch
for the 'retrieve' operation everywhere, you are right, this would be more consistant. I'll make the change.
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 that's a good point - shouldn't there be equivalent methods for LitDataset
s? Given the "Planned API" page, it seems that createFile
would be saveFile
(or saveLitDataset
would be createLitDataset
- though maybe that doesn't cover that it could also overwrite existing datasets, just like (I presume) createFile
could overwrite existing files?), and that we haven't thought of having a deleteLitDataset
yet - which I presume we should have? (And which is probably an alias of deleteFile
or vice versa.)
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.
Right, I didn't think about the overwriting of existing files. I think saveFile
would be good, and we can discuss the exact behaviour in the appropriate PR/ticket.
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.
And adding a deleteLitDataset
seems to be something that we should plan. Also, 1b56737 changes getFile
into fetchFile
src/nonRdfData.ts
Outdated
init: Partial<GetFileOptions> = defaultGetFileOptions | ||
): Promise<Response> { | ||
const config = { | ||
...defaultGetFileOptions, | ||
...init, | ||
}; | ||
// The `fetch` field is not part of the original RequestInit, and it is no longer | ||
// needed in the init object. | ||
delete init.fetch; | ||
return config.fetch(input, init); |
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 think I'd go for separate the options specific to getFile
from the options passed to fetch
, rather than explicitly deleting non-fetch
options, e.g.:
init: Partial<GetFileOptions> = defaultGetFileOptions | |
): Promise<Response> { | |
const config = { | |
...defaultGetFileOptions, | |
...init, | |
}; | |
// The `fetch` field is not part of the original RequestInit, and it is no longer | |
// needed in the init object. | |
delete init.fetch; | |
return config.fetch(input, init); | |
options: Partial<GetFileOptions> = defaultGetFileOptions | |
): Promise<Response> { | |
const config = { | |
...defaultGetFileOptions, | |
...options, | |
}; | |
return config.fetch(input, config.init); |
Otherwise, every option ever added to getFile
will also require adding another delete
statement.
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.
That's a good point. Fixed in d1a2fc8
|
||
expect(mockFetch.mock.calls).toEqual([["https://some.url", {}]]); | ||
}); | ||
|
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.
Maybe we should also have a test that checks that the Response is actually returned to the caller?
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.
Fixed in ee40efb
Good catch about the resolutions ! I think one of the commits in the suggestion batch had an issue (it did not introduce changes), and it messed up the whole batch. |
d1a2fc8
to
3bfa072
Compare
src/nonRdfData.ts
Outdated
init?: RequestInit, | ||
options: Partial<GetFileOptions> = defaultGetFileOptions |
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.
Haha, sorry to keep going on about this, but given that init
is optional, wouldn't it be better as a property on options
(i.e. options.init
)? Because now if you want to pass a different fetch
(or a different option that's added in the future) but not a different init
, you'd have to do fetchFile('https://some.url', undefined, { fetch: fetch })
.
init?: RequestInit, | |
options: Partial<GetFileOptions> = defaultGetFileOptions | |
init?: RequestInit, | |
options: Partial<GetFileOptions> = defaultGetFileOptions |
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.
Don't worry, I was hesitant in the implementation exactly for this reason :). Fixed in c676f1c
getFile fetches a data blob, and returns it to the user. It uses the underlying fallback fetch, and supports content negociation by allowing the user to pass in headers.
Co-authored-by: Vincent <Vinnl@users.noreply.github.com>
In order to not require a documentation additional to the fetch API's, the non-RDF fetching will be closer to the original fetch.
Co-authored-by: Vincent <Vinnl@users.noreply.github.com>
89889a2
to
41b82c0
Compare
New feature description
This PR adds a new function exposing a high-level feature to fetch non-RDF data, while using the internal fallback fetch.
Checklist
index.ts
, if applicable.