Skip to content
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

Way to get base relative path #3376

Closed
jhwz opened this issue Jan 17, 2022 · 2 comments
Closed

Way to get base relative path #3376

jhwz opened this issue Jan 17, 2022 · 2 comments

Comments

@jhwz
Copy link

jhwz commented Jan 17, 2022

Describe the problem

Recently there was a change that updated the $page store which moved the $page.path attribute to $page.url.pathname.
When running an app with paths.base set in svelte.config.js, this changed the properties of the path. Before, $page.path was relative to base set in the config. Now $page.url.pathname is always the full path.

If there was enough demand, it may make sense to make the relative path available through the framework.

Having more than one path may cause confusion to developers new to kit, and if this isn't a common use case it may not make sense.

Describe the proposed solution

Additional attribute path or relpath on the $page store

Alternatives considered

Its not a big deal to write $page.url.pathname.substring(base.length)

Importance

nice to have

Additional Information

No response

@iacore
Copy link

iacore commented Apr 23, 2022

Kind of related: vitejs/vite#7644

@Rich-Harris
Copy link
Member

Generally our stance on this sort of thing is that it's better to have a leaner API in the framework itself at the cost of slightly more verbose code, rather than having the same concept represented in multiple ways, since every new feature adds maintenance and documentation overhead.

In this case, $page.url.pathname.substring(base.length) works, but if that gets old you could also do something like this:

import { relative } from '$lib/path';
$: path = relative($page.url);

Note that you also have access to $page.routeId which depending on your use case might actually be preferable to dealing with the pathname.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants