Solid.js: Enable Reactivity of Component Props to Match React Behavior

[richard-unterberg]

Background

Coming from the React world, our assumption as developers is that everything is reactive — meaning a component rerenders as soon as its props (like $isLoading) change, causing the component to output a different classname.

Example creation of component in both adapters:

const SomeButton = cm.button`
  text-normal
  md:text-lg
  mt-5
  border-1
  transition-all
  ${someConfig.transitionDurationEaseClass}
  ${({ $isLoading }) => ($isLoading ? "opacity-90 pointer-events-none" : "")}
`;

React implementation:

const ParentComponent = () => {
   // usually dynamic - as soon it's changed the `SomeButton` will rerender due changed props
   const queryLoading = false 

   return <SomeButton $isLoading={queryLoading}>{children}</SomeButton>
}

Problem in Current Solid.js Integration

Due to the restriction that we don't pass an Accessor to our components, these are not profiting from Solid.js's underlying hydration logic. As a result, we must "swap" them completely, which causes extra load on the CPU and renderer:

import { Show } from "solid-js"

const ParentComponent = () => {
   // only dynamic if acessor
   const queryLoading = () => false

   return <Show when={!queryLoading} fallback={<SomeButton $isLoading>{children}</SomeButton>}>
      <SomeButton $isLoading={false}>{children}</SomeButton>
    </Show>
}

This approach is inefficient and does not align with how reactivity works in React integrations.

Goal

Provide a plan for a new version of the Solid.js package that enables prop reactivity in the same way React integration does. Because React's underlying design always reconciles/rerenders on prop changes, our Solid.js integration should follow suit.

Proposal:
We should refactor the Solid.js integration to:

• Accept Accessors as props in custom classmatejs components by default.
• Leverage Solid.js's reactive primitives so changing a prop like $isLoading naturally updates the className output, just as in React.
• Eliminate the need for developers to wrap components in <Show> or rebuild component trees solely to reflect prop changes.

Next Steps

• Investigate the technical approach — review how Accessors can be expected as props for these components.
• Evaluate where breaking changes may occur (types, API contract).
• Provide a migration strategy for users updating from the old pattern (non-reactive, explicit swaps/wrappers) to the new (reactive, Accessor-driven) pattern.
• Document clear examples for new and old usage.

Acceptance Criteria

• Direct prop changes (e.g., $isLoading) on classmatejs components in Solid.js rerender/reconcile the component as soon as the Accessor’s value changes, matching React integration experience.
• Documentation updated.
• Migration guide provided.