.astro files in client code

[kishore-FDI]

Body

Summary

Enable importing .astro components directly into client-side JavaScript frameworks such as React or Vue. This would allow for easier reuse of Astro-based UI components across client-side applications.

Background & Motivation

Currently, Astro components are designed primarily for server-side rendering(with the build process to generate the static HTML) and template composition. However, with the increasing demand for shared UI libraries (like ShadCN for React), the inability to import .astro files directly into client components limits the reusability and reach of Astro-based components.

As part of building a UI library focused on accessibility and component composability, enabling .astro imports in client frameworks would:

1. Significantly improve DX for developers building design systems in Astro.
2. Promote Astro as a first-class citizen in the broader component ecosystem.
3. Increase adoption by bridging the gap between server-first Astro and client-heavy ecosystems.

Goals

A concise, bulleted-list outlining the intended goals of this RFC.

• Allow .astro files to be imported and used inside React, Vue, Svelte, or other client-side components.
• Improve reusability of Astro components in hybrid or fully client-rendered contexts.
• Reduce duplication by allowing UI components to be defined once in .astro and consumed both server- and client-side.
• Encourage adoption of Astro for shared component libraries and design systems.
• Preserve accessibility, semantics, and SSR benefits even in client usage contexts.

Example

// ReactClientComponent.tsx
import AccessibleButton from './AccessibleButton.astro';

export default function Wrapper() {
  return (
    <div>
      <h1>Client Component</h1>
      <AccessibleButton label="Click me" />
    </div>
  );
}

[MoustaphaDev]

I understand the value in being able to write UI once and reuse it everywhere, but I think that would be too specific and niche for Astro to support. Some tools (like Mitosis) exist just to enable that. I don't think it is for Astro to try to solve that problem.

Also I have concerns about the technical aspects of having server components running in client components. I imagine Astro components used in client components would work like server islands, a server function/endpoint that returns markup. That may be okay for non-critical components, but for say headers, buttons, etc, having to wait for the client to initiate a request before they're available would make the page very sluggish. And when props change other round trips would be necessary.

I suppose this significant UX degradation is one of the reason why NextJS doesn't support using server components inside client components (they're automatically treated as client ones). The pattern they recommend is passing server components as props to client components, so they can receive the server bits before the page is rendered. This is also what Astro recommends.