Why Prop Destructuring is Not Recommended

[MinJieLiu]

I use the destructuring method, and the following code runs correctly:

import type { Accessor } from 'solid-js';
import { createSignal } from 'solid-js';
import { render } from 'solid-js/web';

function Counter() {
  const [count, setCount] = createSignal(1);

  const increment = () => setCount((count) => count + 1);

  return <Child count={count} increment={increment} />;
}

interface ChildProps {
  count: Accessor<number>;
  increment: () => void;
}

// Destructuring is used here
function Child({ count, increment }: ChildProps) {
  return (
    <div>
      child <button onClick={increment}>{count()}</button>
    </div>
  );
}

render(() => <Counter />, document.getElementById('app')!);

This way also maintains uniformity in use.

[atk]

Once you use stores, you need to wrap the access in functions, which is unwieldy, thus we tend to avoid it.

[MinJieLiu]

I don’t understand your answer. What I’m asking about is parameter destructuring. It would be better to use getter to keep it consistent with createSignal.

[atk]

Let me elaborate then. Consider you have a component that takes a prop. The parent feeds that prop from a store. Currently, it looks like this:

function ParentComponent() {
  const [store, setStore] = createStore({ bar: "works" });
  return <ChildComponent foo={store.bar} />;
}
function ChildComponent(props) {
  return <p>{props.foo}</p>;
}

To keep it reactive, we would have to make a function out of the prop:

function ParentComponent() {
  const [store, setStore] = createStore({ bar: "works" });
  return <ChildComponent foo={() => store.bar} />;
}
function ChildComponent({ foo }) {
  return <p>{foo()}</p>;
}

Since it is easier to forget always passing functions than it is to remind not to destructure, we choose the latter as default - but of course it is up to you how you use solid.