efficiently render tree structures

[cynecx]

import { render, Dynamic } from "solid-js/web";
import { createSignal, createState, JSX, For, produce } from "solid-js";

type Node = {
  id: number;
  children: Node[];
};

type NodeData = {
  a: string;
  component: (props: { tree: Tree; node: Node }) => JSX.Element;
};

type Tree = {
  nodes: {
    [index: number]: NodeData;
  };
  root: Node;
};

function Expand(props: { tree: Tree; node: Node }) {
  return (
    <div>
      <p>{props.tree.nodes[props.node.id].a}</p>
      <For each={props.node.children}>
        {(child) => (
          <Dynamic
            component={props.tree.nodes[child.id].component}
            tree={props.tree}
            node={child}
          />
        )}
      </For>
    </div>
  );
}

type State = { tree: Tree };
let counter = 1;

function Counter() {
  const [state, setState] = createState<State>({
    tree: {
      nodes: { 0: { a: "root", component: Expand } },
      root: { id: 0, children: [] },
    },
  });

  const [count, setCount] = createSignal(0);
  const increment = () => {
    setCount(count() + 1);

    const n = counter++;

    let node = state.tree.root;
    const path: (string | number)[] = ["tree", "root"];
    while (node.children.length > 0) {
      node = node.children[0];
      path.push("children", 0);
    }

    setState("tree", "nodes", n, {
      a: "sub" + n.toString(),
      component: Expand,
    })

    // is it possible to just use `node` as a path here?
    // to prevent setState from traversing the tree again ?
    setState(...path, "children", (l) => [...l, { id: n, children: [] }]);

    // this doesn't work like I expected because it does trigger a whole tree update and not just a fine granular update
    // setState("tree", produce<Tree>(tree => {
      // .. add new node
      // ...
    // }))
  };

  return (
    <>
      <button type="button" onClick={increment}>
        {count()}
      </button>
      <Expand tree={state.tree} node={state.tree.root} />
    </>
  );
}

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

I've added some inline questions.

What is the most "efficient" and ergonomic way to deal with trees? Efficient, as in doing fine granular updates opposed to updating the whole tree whenever the tree structure changes.

[ryansolid]

I hit this problem in UIBench benchmark. That one was driven off a single data state and I used solid state + reconcile. I'm surprised produce would work any differently. I don't use produce myself much so maybe there is a bug needing fixing. The idea of creating a lens on state is interesting. Let me think about that. I can picture how to do it.. but in a way that isn't abusable is harder.

That being said it's a loop the length of depth.. probably not that big of a deal. I'm curious to see the produce case that doesn't work.

[cynecx]

A workaround would be a different Tree structure which uses one level of indirection:

https://gist.github.com/cynecx/de9deffe4bc5c5475b1f3053e8665d26

The idea is basically, introducing indirection with node ids, which performance/overhead wise is subpar than it could be. That's quite unfortunate.

[ryansolid]

Well I usually wouldn't suggest this but there is createMutable. I don't know why produce wasn't working as exected. createMutable would let you just modify from the node. Normally I can find patterns that make this less necessary but I think for what you are doing it's my easiest answer.

[cynecx]

I've switched to using createMutable and it's so much more ergonomic to use for my use-case. This raises the question what possible downsides it has? Especially when you are saying "Well I usually wouldn't suggest this" :')

[ryansolid]

Only two awkwardnesses with mutable proxies.

1. Performance for shallow lists - inserts, removals trigger every index on an array since it slides their indexes. It's usually just faster to shallow clone then hit the proxy that many times on large lists.
2. Mutability is hard to track once it leaves local scope. Once things are getting passed through props you lose a bit of what it is. Building APIs around the expectation of mutability in a large reactive system is a bit chaotic. You have literally the butterfly effect. When I first created Solid it like the one thing I knew I wanted to make different than Vue and MobX etc.

I've seen people accidentally re-render huge parts of the DOM tree with an accidental local assignment 3 components removed. And worse they didn't even notice it for months since visibly it seemed to work until someone has to go in and find a bug and be like WTF. A lot of the same arguments against 2 way binding fall here.

If the purpose is localized like a widget or something createMutable is fine. It also has application with like integrating with certain 3rd party systems, but it isn't something that I'm usually the happiest to recommend because people will see my recommendation and reach for it much too soon when there are better options.

[ryansolid]

Yeah I worked through the lens scenario and I don't think it really saves work. Since it is all about path and not reference. There is no easy way guard against higher up the tree blowing things up. And even if you made it smart it would require computation to keep in sync. It's just more overhead. I think createMutable is probably the recommended solution for this scenario. So I think that's the answer.