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:
William Chargin 2018-03-01 00:48:23 -08:00 committed by GitHub
parent 66243a16c1
commit f5d486087d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 2 deletions

View File

@ -8,8 +8,6 @@ export type Address = {
export type Node<T> = { export type Node<T> = {
address: Address, address: Address,
inEdges: Address[],
outEdges: Address[],
payload: T, payload: T,
}; };
@ -23,6 +21,8 @@ export type Edge<T> = {
export type Graph = { export type Graph = {
nodes: {[stringAddress: string]: Node<mixed>}, nodes: {[stringAddress: string]: Node<mixed>},
edges: {[stringAddress: string]: Edge<mixed>}, edges: {[stringAddress: string]: Edge<mixed>},
outEdges: {[nodeAddress: string]: Address[]},
inEdges: {[nodeAddress: string]: Address[]},
}; };
export function addressToString(address: Address) { export function addressToString(address: Address) {