Question: component doesn't update when property changes

[romgrk]

Hi,

First experience with solid, sorry if the question seems trivial. I have a component that passes a state value to another component as a prop. However the inner component (Button in the example above) doesn't update when the state value changes and I don't understand why.

function App() {
  const [state, setState] = createState({ progress: 0 });
  const timer = setInterval(() => setState({ progress: (state.progress + 1) % 100 }), 50);

  onCleanup(() => clearInterval(timer));

  return (
    <div class='App'>
        <Button progress={state.progress}>
            Progress Button
        </Button>
    </div>
  );
}

function Button({ children, progress }) {
  return (
    <button class='Button' data-progress={progress}>
      {children}
    </button>
  )
}

DOM value for data-progress stays at 0 :/
However if I use state.progress in the text of the children of Button as below, the text does update...but data-progress stays at 0 :/

  return (
    <div class='App'>
        <Button progress={state.progress}>
            Progress Button {state.progress}     <------ This updates
        </Button>
    </div>
  );

[ryansolid]

No problem. And there is luckily an easy solution. Unfortunately you have run into the likely biggest gotcha with the approach Solid uses. This is shared by Vue and MobX too. We can't destructure props without losing reactivity. The button component needs to look like:

function Button(props) {
  return (
    <button class='Button' data-progress={props.progress}>
      {props.children}
    </button>
  )
}

I've tried to note this in the docs in several locations but I feel like it's a 50/50 whether people see this.

More detailed explanation:

It isn't the destructure itself doesn't work. It is that tracking for updates happens on property access, so if you reference them outside of a JSX binding or a "hook" (reactive primitive) no one is listening. The granular reactive approach we use doesn't re-render whole components but only the hooks and the JSX expressions so tracking only occurs in them. This is a key part of the performance and the approach we use to avoid diffing (and VDOM) but it does bring this caveat.

As for Component props they lazily evaluate. So when you pass state.progress it isn't resolved at component instantiation time. Instead it is passed through almost like a stream to exactly where it is used. In this way when props are passed through the tree they don't have any effect on intermediate components. So things like Context API or prop drilling(passing props through several components until they get used) has zero performance overhead.

Hope that helps.

[aminya]

I have run to this problem. But mine is a little different. I have created a signal, and I call the function for getting the signal in the JSX. The underlying component expects rows.

In my component, in the beginning, the messages are [], but later they are added using setMessages. But this does not update the children. How can I fix this?

If I replace getMessages with a function which logs the data too (like (() => {const x = getMessages(); console.log(x); return x})()), it shows that the function is called only once.

export default function PanelComponent(props: Props) {
  const [getMessages, setMessages] = createSignal(props.delegate.filteredMessages)
  

  onMount(() => {
    props.delegate.onDidChangeMessages(messages => {
      setMessages(messages)
    })
  })

  /// other code here

  return (
    <div>
      <SimpleTable
        rows={getMessages()}   // only called once in the beginning.
        /// other props here
      />
    </div>
  )
}

@ryansolid

[ryansolid]

Hmm.. my usual next steps are to ask to see Simple Table. Most times the issues are not with the setting but the usage. I mean what you pasted wouldn't work because the arrow function doesn't return anything but Im assuming that doesn't reflect your actual code exactly.

[aminya]

you pasted wouldn't work because the arrow function doesn't return anything but Im assuming that doesn't reflect your actual code exactly.

Sorry. That was a mistake. I pasted the correct code.

My problem is that getMessages is called only once. While I expect that to be called whenever setMessages changes its value.

The SimpleTable code.
https://github.com/aminya/solid-simple-table/blob/master/src/SimpleTable.tsx#L25-L136

The props.rows becomes a signal of the child:
code

  const [getRows, setRows] = createSignal<RowsSignal>(props.rows)

Here is where SimpleTable is used:

https://github.com/steelbrain/linter-ui-default/blob/f6ff81d273ee2da8d32e9216c66a375837cb17b3/lib/panel/component.tsx#L36

[ryansolid]

Yeah that line is exactly the problem. It isn't doing what you think it is. If you initialize a signal with the value of another signal nothing reactive is being tracked. You are just creating a new signal with the value at that time. To illustrate it another way, you are basically doing this:

const [a, setA] = createSignal([]);
const [b, setB] = createSignal(a()); //see this calls `a` once. Now `b() === a()`.

createEffect(() => {
  // render some stuff based on `b`
  render(b())` // `b` is being tracked
})

// later
setA(data); .. nothing happens because no on is listening to `a`

As a rule of thumb if it isn't in JSX or wrapped in a primitive with a function closure (like createMemo, createEffect etc.. it's not tracking**

Now I don't know if it is intentional but there is a lot of prop destructuring that is happening in here so many things aren't being tracked. But you don't upgrade props to signals. Props are readonly. So as I see it comes down to intention and data ownership/source of truth.

Is the intention that these are using the same data that is in sync? It's ok for the child to filter or derive new data from it but there is a single source of truth so the parent has to expose a way to update the data if the child needs to update it and you should just use props.rows or a derivation of that data like a createMemo. Ie.. pass both the data and the setter to the child like:

<SimpleTable
        rows={getMessages()}   // only called once in the beginning.
        onRowsChange={setMessages}
        /// other props here
      />

Or is it that the child SimpleTable wants to maintain its own copy that occasionally gets synchronized from parent, almost like a reset. In that case create the signal like you have been but you need to create a computation to keep it in sync. Using createComputed to write to your local copy can keep it in sync like:

const [getRows, setRows] = createSignal();
createComputed(() =>{
  // update the local copy whenever the parent updates
  setRows(props.rows);
})

While the local version can diverge from the parent, if the parent ever writes it will synchronize. This might seem like the easiest way to proceed but unless there is a real reason to keep multiple copies it's probably better to let the parent own the data.

I hope that makes sense. Solid by API design sort of forces you think about data flows. It keeps things really clean but it means like porting typical VDOM code takes a bit extra consideration.

[aminya]

Thanks for the thorough explanation.

Now I don't know if it is intentional but there is a lot of prop destructuring that is happening in here so many things aren't being tracked. But you don't upgrade props to signals. Props are readonly. So as I see it comes down to intention and data ownership/source of truth.

These that are restructured are my "static props". That means that only their initial value is used. I mostly did the destructuring as an optimization. Because some of these are inside loops and the property access can be cached. Maybe, I should measure the performance difference, and see if this is actually a good idea.

Is the intention that these are using the same data that is in sync?

Here the rows will change by the parent, but in the table, they can be reordered. Whenever the rows change by the parent, the rendering should be reset. So, based on your explanation, I think the second approach (using createComputed) is better for me. The issue is fixed now in the newer version of solid-simple-table.

Are there any performance differences between the first and the second approach?

Thanks for the help!

BTW, can we merge createSignal and crateComputed together to make a new hook? Something like createComputedSignal

[ryansolid]

If it is truly static then that is definitely the best way. Saves work all the way down the line. You reduce creation costs greatly when there is no chance the binding can be dynamic, especially in large lists. So that's good

The first approach will be generally more performant. I think you are looking for the first approach if you are only re-ordering. It would be different if the table was editing the rows but ordering is just projection derivation. You could in the SimpleTable:

const orderedRows = createMemo(() => props.rows.sort(/*... sort order*/))

The second approach is much more of a scratchpad approach..Like editing then committing. I suppose if you want the sorting to reset too it wouldn't be that bad to do the 2nd approach but the first approach doesn't cause a cascading propagation and removes chances for weird synchronization bugs. Since we are dealing with state those synchronization concerns probably aren't a thing since they are sharing the same objects. When we use a computed to write we basically start a new batch of change updates (these still happen before any rendering so it isn't really that bad, but computations can run multiple times). Generally speaking if it can be expressed as a derivation createMemo it's better.

[MattStopa]

I got stuck for about 45 minutes today with this exact issue. I'm curious what the solution is when you need a rerender like you would get in React. I have resorted to just using components as functions rather than tags and it works but it's not great.

So:

import { render } from "solid-js/web";
import { createSignal, For, createEffect } from "solid-js";

function Printer(props) { 
  let total = 0;
  props.items.map((item) => { 
    total += item
  })
 
  return (
    <div>{ 
      total
    }</div>
  )
}

function Counter() {
  const [nums, setNums] = createSignal([0,1,2,3,4]);

  return <div>
    <button onClick={() => setNums([Math.random(),4,3,2,1])}> HI</button>
    <Printer items={nums()}/>  
    {Printer({items: nums()})}
  </div>
}
 
render(() => <Counter />, document.getElementById("app")!);

The tag for Printer doesn't work but using it as a function does. I have looked through the documentation the best I can but I can't seem to figure how what you are supposed to do here. I tried useEffect and a bunch of other stuff.

Any insight or pointing to the docs would be great.

[xdev1]

@MattStopa Something like this?
I'll explain it, if this is what you've wanted.

[MattStopa]

Wow, thanks for the quick reply. Why on earth does that work exactly? Just stick the compute in a function it knows to regen that function when the data changes? So weird.

[xdev1]

In Solid (in contrast to React) component functions will only be invoked exactly once per usage in the DOM tree, while in React they will be called over and over again each time the component updates.
So in your original example there's no way that the calculation of total will be run again as the only way to run that calculation again would be to call function Printer itself again, what will not happen as, like I've said, Solid is running component functions only once per usage in the DOM tree.

The most important part is the difference between { total } in your version versus { calcTotal() } in my version. The solid JSX compiler makes sure that each time it find a { ... } expression inside the JSX tree it will always track while evaluating this little { ... } expression whether there are any signal accessor functions or props getters be called. If no, then this { ... } expression will never be re-evaluated again, but if yes, then this expression will be re-evaluated each time some of the involved signals/reactive items change. In your version, { total } means just evaluating a number, this does not involve any reactive items so { total } will never be re-evaluated, that's why your version of the demo fails. In my version, however, the expression in the JSX tree is { calcTree() }. When this expression is evaluated it calls the calcTree method and this calls reactive items, namely that props object. So each time that reactive props object changes that JSX expression { calcTree() } will be re-evaluated, which means it will invoke that calcTree function again (not the Printer function!!!).
That's basically all the magic.

The fun thing in Solid is that what Solid calls "components" are nothing else than basically just normal functions which just happen to have a fancy name for their kind. So solid components do not have something like a lifecycle or component instance like React and other UI libraries may have. All the magic is done by this reactivity system.
Dear Solid folks, please correct me if I might have said something wrong.

[MattStopa]

Okay thanks for the explanation. So basically it just tracks what's injected and sees if anything in that evaluation path uses a signal... That makes sense. I knew component didn't rerender but I figured that somehow it was looking at the final value and realizing what I did to that value. In retrospect that makes no sense.

I get it now! Thank you!