Possibility to use custom reviver in deserialization?

[hansmbakker]

Crosspost from octokit/graphql.js#414 since the request/response logic is done here

Is it possible to use custom revivers in the deserialization, so that Date strings could be serialized back directly to Date objects?

See https://stackoverflow.com/a/35923990/1114918 for reference.

Should I maybe do something with a custom fetch implementation?

[hansmbakker]

I see response.json() is hardcoded - is there a way I could override this behavior?

request.js/src/fetch-wrapper.ts

Lines 138 to 142 in 5b03156

	async function getResponseData(response: Response) {
	const contentType = response.headers.get("content-type");
	if (/application\/json/.test(contentType!)) {
	return response.json();
	}

[gr2m]

you can pass your a custom fetch function as { request: { fetch } } option

[hansmbakker]

@gr2m I saw how I could supply a custom fetch implementation, but I am wondering whether it is solved that way?

I found https://stackoverflow.com/questions/45425169/intercept-fetch-api-requests-and-responses-in-javascript on how to create a fetch modification, but the getResponseData() function I mentioned will still be called for the response - even if I already do deserialization in my modified fetch. This confuses me - I guess double deserialization won't work.

Could you explain how you would see that working?

[gr2m]

I got it now, please ignore my comment, it doesn't resolve your problem.

So what you want is in the JSON you receive from GitHub's API, all timestamp strings should be turned into Date objects?
As in iterate through all keys of the JSON recursively, look for keys and/or values that look like time stamps, and turn them into JSON objects?

You could implement that with a request hook, using options.request.hook in @octokit/request options. But better to use https://github.com/octokit/core.js/ and its .hook API as it doesn't interfere with other request hooks that might have been previously registered.

Something like this

octokit.hook.wrap("request", async (request, options) => {
  const response = await request(options);
  
  // TODO: turn all timestamp strings into Date objects in `response`
  
  return response
});

I wonder why you want that though. It feels like a intransparent side effect that you might trip over easily in the future. I'd rather turn the timestamps into Date objects as needed.