Skip to content

Conversation

@jonathanyeong
Copy link
Contributor

@jonathanyeong jonathanyeong commented Feb 10, 2026

This PR also makes some other fixes:

  • Fix embed not being loaded because of the change to BLUESKY_API which now omits the xrpc url.
  • Refactor bluesky author profiles with comments and file name changes to clarify how it connects with the server side API call.

Note

I'm adding a new lex type so you will need to rerun pnpm generate:lexicons or pnpm install to pull in the new types.

Testing

Anonymous missing template warning

Before the change, console shows the missing template warnings:

Screenshot console showing missing template warnings

After changes, no errors in the console:

Screenshot console showing no warnings related to missing template

Bluesky embeds

Before the change, my bluesky embeds were not loading with a 502 error:

Screenshot broken bluesky embed on the blog post with a 502 error in the console

After the change, I can see the bluesky embed:

Screenshot fixed bluesky embed on the blog post after changes

Author profile images

Tested that OG image still loads author profiles

…omponent warning

The EmbeddableBlueskyPost plugin was client-only (.client.ts), meaning the component was
unregistered during SSR when unplugin-vue-markdown compiles the blog.md files.
This produces the "missing template or render function" warning.
Convert the component and plugin to be included during SSR but use <ClientOnly> for browser-only rendering.
The oembed endpoint used a raw fetch and is missing the `/xrpc` path prefix. This causes
a 502 error when trying to fetch embeds. We can use the typed client to be consistent
with author-profiles and other atproto api routes. And means we don't need to specify the
/xrpc path in the fetch.
…arity

Add a comment to hopefully clarify how useBlueskyAuthorProfiles works with
the bluesky-author-profiles server end point.
@vercel
Copy link

vercel bot commented Feb 10, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
npmx.dev Ready Ready Preview, Comment Feb 10, 2026 9:49pm
2 Skipped Deployments
Project Deployment Actions Updated (UTC)
docs.npmx.dev Ignored Ignored Preview Feb 10, 2026 9:49pm
npmx-lunaria Ignored Ignored Feb 10, 2026 9:49pm

Request Review

Copy link
Contributor Author

@jonathanyeong jonathanyeong Feb 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By removing .client this component will now appear during SSR for unplugin-vue-markdown to pick up when it's compiling the blog posts. But the <ClientOnly> tag should mean it's only rendered by the browser.

Copy link
Contributor

@Kai-ros Kai-ros Feb 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Feel free to correct my Nuxt/Vue ignorance on anything I say.
  • My understanding is that Nuxt's .client.vue suffix is equivalent to the Nuxt <ClientOnly> wrapper component, so they're interchangeable in this regard.
    https://nuxt.com/docs/4.x/directory-structure/app/components#client-components
  • Is the only reason to move the component to server-side to ensure it is picked up by unplugin-vue-markdown ?
  • The app/plugins/bluesky-embed.ts below should already be doing the work of registering the component during the build process.

Copy link
Contributor Author

@jonathanyeong jonathanyeong Feb 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that Nuxt's .client.vue suffix is equivalent to the Vue wrapper component, so they're interchangeable in this regard.

They are very similar, but adding .client to the component means the entire component won't be available during SSR. While when we specify ClientOnly tag it's only applied at the usage site. So the component is still available during SSR with ClientOnly.

Is the only reason to move the component to server-side to ensure it is picked up by unplugin-vue-markdown ?

Yup!

The app/plugins/bluesky-embed.ts below should already be doing the work of registering the component during the build process.

That's true, my change doesn't do anything regarding registering the component. But we still need to import the plugin during ssr rather than only client side.

Side note: I was looking at unplugin-vue-components and this might be something we can add in the future so we don't have to explicitly import a global component.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I'm not sure I understand the distinction well enough to see the value add here, but if it satisfies a need or resolves a bug, then send it!
  • I tried to make it work with unplugin-vue-components in an earlier attempt but it was unsuccessful so more power to you if you get it to.

@whitep4nth3r
Copy link
Contributor

Thank you!!!!!!!

@whitep4nth3r whitep4nth3r requested a review from Kai-ros February 11, 2026 10:03
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