JSON树存储格式

Question

This is more of a conceptual type of question for storing and updating the data for a tree. Let's take a common example - a virtual dom from something like React.

A common json storage for a tree that represents a dom would be something like:

{
  nodeId: 'nodeId1',
  ...nodeData,
  childrenNodes: [
    {
      nodeId: 'nodeId2',
      ...nodeData,
      childrenNodes: [...]
    },
    ...
  ]
}

So, I'm looking at a tree with either BFS or DFS (I believe React does DFS) to find a specific element to change it.

Another possible implementation of this same tree might be where I store it more like a hash table looking format:

{
  nodeId1: {...nodeData, childrenNodes: [nodeId2]},
  nodeId2: {...nodeData, childrenNodes: [nodeId3, nodeId4]},
  ...
}

So getting a specific node could be potentially O(1), since we're just hashing all the node ids, rather than having to traverse the tree each time.

For something like a virtual dom where we could be storing the state for tens or even hundreds of thousands of possible elements, I think storing one way over the other would be negligible, but we probably wouldn't want to have both structures in memory (though maybe it would be fine to have both?).

Assuming both structures have assigned ids for each node, adding and removing nodes would be fairly easy in both cases. We could also assume in both cases, each child has a reference to its parent node.

The question I'm down to is which structure would make more sense to use in a general case, or would it make sense to track with both structures if we were focused on updating a node or set of nodes as quickly as possible? If I was going to make a framework from scratch, I could see both cases being useful for different scenarios, but I would have to keep in mind limited memory devices like older phones.

Answer 1

Nobody answered, so I'll just give my opinion based on additional research and observations.

The hash solution presented would be faster in some scenarios for accessing a node. However, readability and extending this solution for other possible integrations makes it a much tougher structure to deal with. If I was going to use those arrays of ids, I would want to do it as a separate structure meant only for searching, but not for updating many nodes at once.

For most scenarios, the more verbose tree outline will make sense and be easier to work with.