Astro Guidelines

Minimal props

Components should specify a minimal Props interface that contains just the data a component needs. Do not anticipate future needs, if the component does not currently use a property it should not be in the Props.

Any data passed into the component should not include properties that are not specified in the Props. Extra fields should be stripped out, otherwise they will end up in the production html.

Example

If a Button component has

interface Props {
  user: { name: string };
}

and the parent has the following data

const aUser = {
  name: "Any Thing",
  id: "123abc",
};

strip the 'id' in the component script first, so you have

const propUser = {
  name: "Any Thing",
};

and only use propUser in the template

---
import Button from './Button.astro';
const propUser = {
  name: 'Any Thing',
}
---
<Button user={propUser} />

Avoid null returns

If using both @astro/react and @astro/mdx, components rendered with client:\* directive should not return null. If they do, they will trigger a spurious "Invalid hook call." warning. To avoid this, return <></> (i.e. an empty fragment) instead of null.

Fonts

Do not use @import url(...) or @font-face{} to add fonts to style sheets. Instead use Astro's fontProviders which will optimize font loading. Guide.

Prefer .astro components

Even if the application supports other UI frameworks (React, Vue etc.), use them sparingly. If a component does not need interactivity, use a .astro component instead. This makes it clear that hydration is not possible and gives access to powerful .astro specific features like script directives and build time javascript execution.

When creating new components, only use a UI framework component if either of the following is true. The component is inherently interactive or it needs to be imported by a UI framework component. If the static component can be passed into the UI component via a <slot>, then the static component should come from a .astro file.