Allow skipping normalizing of request path into a URL

[fiadliel]

Perceived Problem

I would like to be able to use the fetch from SvelteKit with graffle. Amongst the differences with stock fetch, is the ability to accept a relative path, and "do the right thing" on the client or server.

I can call the custom fetch in an anywhere hook, but by this point any configured path is converted (or an attempt is made) into a URL; this does not work with relative paths. I could try to create a dummy URL and ignore it, but trying to duplicate a Request object opens up a number of issues.

Ideas / Proposed Solution(s)

One idea is to allow either URL | string all through the system, and just pass directly when creating a Request. Alternatively, maybe modify the Http transport to allow this to be built as a custom transport, without having to copy the whole implementation.

[jasonkuhrt]

Hey @fiadliel, I generally understand the use-case of this feature. Another motivation to avoid URL parsing of string is performance. Only certain code paths leverage a URL data type. See below.

---

Background on current system:

There are cases where the URL needs to be manipulated, such as the HTTP transport method mode of GET for queries (opt-in).

I don't like the premise of URL string manipulation because of the edge-cases I presume there are if doing it correctly. Meanwhile there is a host platform that has solved it.

---

Here is some logic I am thinking of:

// we've entered a code path where:
// 1. we need to manipulate the URL
// 2. we have a URL string

const blankUrlString = 'http://blank'

const tryParse = (urlString): { type: 'cannot' } | { type: 'canAsIs', url:URL } | { type: 'canWithBase', url:URL } => {
  const canParseAsIs = URL.canParse(configUrl)
  if (canParseAsIs) return ...

  const canParseWithBase = URL.canParse(configUrl, blankUrlString)
  if (canParseWithBase) return ...

  return ...
}

// ...

const result = tryParse(userConfigUrl)

if (result.type === 'cannot') throw new Error('...')

if (result.type === 'canAsIs') {
  const updatedUrl = result.url // do stuff
  return updatedUrl // We can leave this as URL now, it was valid anyways and we've paid the "parse" cost now, so ahead we go
}

if (result.type === 'canWithBase') {
  const updatedUrl = result.url // do stuff
  const updatedUrlString = updatedUrl.slice(blankUrlString.length) // back to string since we don't actually know the base so we must do this.
  return updatedUrlString 
}

throw new Error('unknown case ...')

Any thoughts? Would this work for you?

Related:

• https://developer.mozilla.org/en-US/docs/Web/API/URL_API/Resolving_relative_references
• https://datatracker.ietf.org/doc/html/rfc3986.html#section-5.2
• https://nodejs.org/api/url.html#new-urlinput-base

[fiadliel]

Ah — I understand your issue — for example, trying to pass a query as part of a GET request, right? It's a pain that safe modification like this requires a full URL, rather than being based on path alone.

That idea works fine for me! It's obviously hacky, but when needs must, the devil drives, as they say. A user can choose between making use of svelte fetch's support for paths, OR save on this cost, so the cost is avoidable if it were necessary.

I'm actually pretty new to frontend web development again (much better than the last time I looked), so I can't help but wonder if there are any reliable libraries that handle path-only manipulation (but I also get that URL is the tried and tested option).

[jasonkuhrt]

Cool, I will proceed with this solution and add documentation to the extension about how URL is handled.