Support Request

Currently I'm using Datastar 1.0.0-rc.5 in a web app that acts like a portal to various apps/modules are users have access to, and it has been great for a lot of the tasks I've thrown at it. However, I was surprised when using something like a @get() that relative URLs aren't resolved against the page's base URL when its set.

In my case, I'll render something like <base href="/{some-tenant-id}/"> in the head of the initial HTML document I serve up along with a nav placeholder that has a data-on-load="@get('api/portal/main-nav')" attribute. The intent is to have that relative URL resolve against the page's base URL to a tenant-qualified URL (i.e., https://example.com/{some-tenant-id}/api/portal/main-nav).

That all works good when someone navigates to the root of the site originally. However, when someone navigates first to some deep link in the web app (say https://example.com/{some-tenant-id}/fancy-reports-module/), the @get() attribute sends the request to https://example.com/{some-tenant-id}/fancy-reports-module/api/portal/main-nav instead. I can see why that happens in the fetcher code linked below where it resolves the URL against window.location.href.

Ideally, it would be nice if Datastar resolved against the page's base URL here since that seems to be how other relative URLs on the page get resolved by the browser (say for script or img tags). Would that be something in line with how Datastar is expected to work? If so, it seems like using document.baseURI in the fetcher would address this since it seems like its fallback behavior is to use window.location.href if no base element is found on the current document (MDN link). If not, I'm able to at least adjust the URL accordingly in my @get() call.

Datastar Version

1.0.0-rc.5