Trying to understand the reactive lifecycle

[usrlocl]

Please see this simple example which renders a list of items. A console.log inside the shows how many times each item was rendered.

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

function App() {
  const [cats, setCats] = createSignal([
    { name: 'Keyboard Cat' },
  ]);

  const li = () => {
    return (
      <For each={cats()}>{(cat, i) =>
        <li>
          {(() => {
            console.log('name');
            return <span>{cat.name}</span>
          })()}
        </li>
      }</For>
    );
  }
  
  return (
    <>
      <button onClick={() => setCats([...cats(), { name: 'topcat' }])}>Add</button>
      <ul>
        {li()}
        {/*li(cats())*/}
      </ul>
    </>
  );
}

render(() => <App />, document.getElementById('app'))

https://playground.solidjs.com/anonymous/63e3a992-3a1c-4d9b-bd11-2e1c06811b16

When run, it logs just once when an item is added. I presume this is because memoizes each value, thus existing items do not get re-rendered.

If you replace, line 26 with line 27, this behaviour changes completely and it logs for each existing item as well i.e. as many times as the size of the list. Why is the memoization not effective in this case, despite there being no change in the memo function's dependencies?

And what difference does it make to li function whether you pass the signal from outside as in line 26? Shouldn't its dependencies be same in both cases?

[ryansolid]

It's because in your first case For is being subscribed to alone, cats is being passed to it and wrapped in isolation. Whereas in the second case you are creating a subscription to cats above where you do the For.. so every time it changes it redoes creating the whole For component.

Where you call the cats function matters. Calling it in the expression in the <ul> means that is the expression that is reactive, whereas passing it to the For means that it manages where it is tracked.

The main reason we untrack components is this. Because otherwise any top level read would trigger the parent context. This is why we can't destructure. The alternative would have been that destructuring "worked" but it would be super inefficient like this.

[usrlocl]

Ah gotcha, that makes sense. Thank you.