Does solid support guaranteed top-down reactivity?

[cynecx]

I can't post the full source code because of copyright, however the situation is the following:

// const propertyComponents = /* reactively computes an array of components supported by the store.selectedNode */
return (
    <>
      {hasSelectedNode() && (
        <For each={propertyComponents()}>
          {(component) => (
            <Dynamic component={component} node={store.selectedNode!} />
          )}
        </For>
      )}
    </>
  );

The initial situtation is:

• hasSelectedNode = true
• propertyComponents produces an array of one component with node={store.selectedNode!} as its props

When the selectedNode changes, it seems that updates aren't updated top-down, as in:

• store.selectedNode has changed
• propertyComponents produces an empty array because the new selectedNode has no properties
• ! The dynamic component from before has node={store.selectedNode!} in its props and therefore is updated, however this component should "disappear" since propertyComponents produces an empty array.
• The For gets updated now

The third bullet-point is my current issue because a property component is instantiated with a node that doesn't support that property. This wouldn't happen when the For is evaluated first, therefore "destroying" the dynamic component.

I hope this description isn't too opaque.

[ryansolid]

I see. I do up and down traversals to check if a parent could be disposed and resolve it first since the order of the queueing itself can't be guaranteed especially when there are multiple changes. It's possible that since a For loop interaction is its own root that it isn't looking up far enough. I think this would be a good scenario to isolate and work through. I thought I'd come up with a robust way to handle these situations, since subscriptions generally are made in initial execution order this usually only gets you on multiple change scenario. It's also possible this is the side effect of a more recent change.

What version of Solid are you using?

[cynecx]

Hmm, I see. I am sorry, I still can't exactly wrap my head around it where I should be proactive (like using the Show "workaround") and where it should just work. Perhaps you could provide some examples where someone just can't expect something?

I think that anything that will be disposed shouldn't run in the same cycle

So the minimized issue should be considered a bug, iiuc?

[ryansolid]

Yes I think so. I need to see what's happening exactly but from what you described yes.

What I meant was while I can't ensure top-down from like your render function perspective or say the DOM tree, I do ensure(well supposed to) topological execution of the reactive graph within any execution assuming you aren't setting other signals as side effects.

[ryansolid]

Yeah it looks like it was my optimization that caused this. Something introduced in the 1.0 RC builds. So good news is easy fix. Bad news is I have to rethink my optimization. But I'm glad we found this before official release.

[cynecx]

@ryansolid Thanks for the fix.

I have another tree example, which has a similar issue:

https://playground.solidjs.com/?hash=-1391246675&version=1.0.0
https://gist.github.com/cynecx/1cc32b7b2eafc47d8b696cdfd518056b

To reproduce add some nodes. And then click reset.

The issue is similar to the one above. Solid is doing stale updates.

[ryansolid]

Ok thanks for the reproduction. Helps immensely.