Pull in-edges and out-edges up to top-level graph (#48)
Summary: The main problem with having these fields on the node is that this presents the illusion that the API surface area is larger than it actually is. Clients with reference to a node object could somewhat-reasonably expect that mutating these fields would be sufficient to update the structure of the graph, but this isn’t the case (as the edge objects would need to be updated, too). It’s a nice semantic bonus, too, as edges aren’t conceptually “part of” nodes. wchargin-branch: top-level-edges
This commit is contained in:
parent
66243a16c1
commit
f5d486087d
|
@ -8,8 +8,6 @@ export type Address = {
|
|||
|
||||
export type Node<T> = {
|
||||
address: Address,
|
||||
inEdges: Address[],
|
||||
outEdges: Address[],
|
||||
payload: T,
|
||||
};
|
||||
|
||||
|
@ -23,6 +21,8 @@ export type Edge<T> = {
|
|||
export type Graph = {
|
||||
nodes: {[stringAddress: string]: Node<mixed>},
|
||||
edges: {[stringAddress: string]: Edge<mixed>},
|
||||
outEdges: {[nodeAddress: string]: Address[]},
|
||||
inEdges: {[nodeAddress: string]: Address[]},
|
||||
};
|
||||
|
||||
export function addressToString(address: Address) {
|
||||
|
|
Loading…
Reference in New Issue