mirror of
https://github.com/status-im/sourcecred.git
synced 2025-02-11 03:56:41 +00:00
7ccef98c87
`NodeReference` and `NodePorcelain` act as abstractions over the two states a Node can be in. - We might have the address of a node (because some edge pointed to it), but don't actually have the Node in the graph. In that case, we can do some queries on the node (e.g. find its neighbors), but can't access the payload. This corresponds to having a `NodeReference`. - We might have the node in the graph. In that case, we can access a `NodePorcelain`. The main benefit this abstraction brings is type-safety over accessing data from a `NodePayload`. Previously, the coding conventions encouraged clients to ignore the distinction, and the type signatures incorrectly reported that many payload-level properties were non-nullable. Now, the `get` method that mapp a `Reference` to a `Payload` is explicilty nullable. Given a `NodePorcelain`, it's always possible to retrieve the reference via `ref()`. Given the `NodeReference`, you might be able to retrieve the `NodePorcelain` via `get()`. Clients that subtype `NodePorcelain` and `NodeReference` should, in general, override the `ref()` and `get()` methods to return their subtype. We also recommend having subclasses overwrite the constructors to take a base `NodePorcelain` and `NodeReference` respectively (although the base classes take a `Graph` and `address` as constructor arguments). Test Plan: Inspect the unit tests, they are pretty thorough. Paired with @wchargin