solidjs

solidjs Best Practices

This document outlines the definitive best practices for developing with SolidJS 1.x. Adhere to these guidelines to leverage Solid's fine-grained reactivity, ensure optimal performance, and maintain a consistent, scalable codebase.

---

1. Use SolidJS 1.x (Stable)

Always use the current stable 1.x release. SolidJS 2.0 is experimental and not ready for production. Avoid any features or APIs mentioned for 2.0.

2. Component Architecture & Code Organization

2.1. Component File Naming

Use PascalCase for component filenames. This clearly distinguishes components from other modules.

• ❌ BAD: mybutton.jsx, user-profile.jsx
• ✅ GOOD: MyButton.jsx, UserProfile.jsx

2.2. Keep Components Lean

Components should be small and focused. Extract complex logic or UI parts into separate components or custom primitives.

2.3. Colocate Styles

Use Vite's CSS Modules for component-specific styling. This provides scoped styles without runtime overhead.

• ❌ BAD: Global CSS files, CSS-in-JS libraries with runtime.
• ✅ GOOD:

  // MyComponent.module.css
  .container {
    background-color: var(--color-primary);
  }
  .text {
    color: white;
  }
  
  // MyComponent.jsx
  import styles from './MyComponent.module.css';
  
  function MyComponent() {
    return <div class={styles.container}><span class={styles.text}>Hello</span></div>;
  }
  

3. Props Handling

SolidJS props are reactive getters. Incorrect handling breaks reactivity.

3.1. Never Destructure Props Directly

Do not destructure props at the component's top level. This immediately loses reactivity. Access props via props.propertyName.

• ❌ BAD:

  function MyComponent({ name, age }) { // React pattern, breaks Solid reactivity
    return <div>{name} is {age}</div>;
  }
  

• ✅ GOOD:

  function MyComponent(props) {
    return <div>{props.name} is {props.age}</div>; // Access directly
  }