Skip to content

Document Astro.originPathname #11610

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

TheOtterlord
Copy link
Member

Document the originPathname context, implemented in withastro/astro#12373 and first released in [email protected]

Copy link

netlify bot commented May 4, 2025

Deploy Preview for astro-docs-2 ready!

Name Link
🔨 Latest commit 8bda69f
🔍 Latest deploy log https://app.netlify.com/sites/astro-docs-2/deploys/68174d567986a100082e9b7a
😎 Deploy Preview https://deploy-preview-11610--astro-docs-2.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@astrobot-houston
Copy link
Contributor

Lunaria Status Overview

🌕 This pull request will trigger status changes.

Learn more

By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.

You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

File Note
en/reference/api-reference.mdx Source changed, localizations will be marked as outdated.
Warnings reference
Icon Description
🔄️ The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

@sarah11918
Copy link
Member

Thanks @TheOtterlord !

I'm wondering whether there should be mention of/link to this in the rewrite() entry? (it's specific to rewrites only? not redirects?)

Also, given our description of rewrites:

rewrite() allows you to serve content from a different URL or path without redirecting the browser to a new page.

It doesn't seem like Astro.url.pathname and Astro.originPathname would be different? I would expect url to match the URL in my browser bar, and if we haven't redirected the browser to a new path (only pulled content in from a new path), then do either of the descriptions for redirect or url have to change?

@TheOtterlord
Copy link
Member Author

I'm wondering whether there should be mention of/link to this in the rewrite() entry? (it's specific to rewrites only? not redirects?)

Yes, this is specific to rewrites. I positioned it under rewrite since it's related, but we can also find a way mention it there if it's helpful.

It doesn't seem like Astro.url.pathname and Astro.originPathname would be different? I would expect url to match the URL in my browser bar, and if we haven't redirected the browser to a new path (only pulled content in from a new path), then do either of the descriptions for redirect or url have to change?

Astro.url.pathname is the URL of the page you rewrite to, which is why originPathname exists (afaik). So Astro.originalPathname matches the path you'd see in the browser, whereas Astro.url.pathname would be the /404 or whatever you called rewrite() with.

@sarah11918
Copy link
Member

So, my confusion is that this is what we say about rewrites in the routing guide:

A rewrite allows you to serve a different route without redirecting the browser to a different page. The browser will show the original address in the URL bar, but will instead display the content of the URL provided to Astro.rewrite().

So, I'm trying to wrap my head around what I think the above says:

  • someone requests URL-a (is this originPath? the original pathname requested, before rewrites were applied?)
  • according to what we say about rewrites, the browser bar displays that you're on URL-a (what I'd expect url.pathname to show because that is the path you can see?) but shows the content that exists at URL-b.
  • is URL-b the url.pathname since it's the location of the content you're seeing (but not actually the URL pathname of the page you're on right now? If that's the case, if url.pathname can be a different address then you are currently visiting, then I think that needs more explaining?

I get that we request one path and see the content for a different one, and that there's a "ask for this, get this" relationship. But, if the URL of the initial request, and the one shown in the browser are the same (because you didn't redirect, you just put different content at the requested path), then I would expect displaying originPath (the path I requested) and url.pathname (the URL I see in my browser tab, because I did in fact go there, and that wasn't changed on me) to be the same.

This is what I'm trying to figure out, and whether any other explanations need to change, because the example you added here makes me think that those would return two different URL paths, but I'm trying to figure out how that would be. 😅

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

Successfully merging this pull request may close these issues.

3 participants