You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(tree): make codec dependencies more explicit and auditable (#25619)
## Description
The main goal of this PR to make the hierarchy of codec dependencies
that are scattered across the SharedTree codebase more explicit and more
auditable. This is accomplished in two ways:
### Specific Version Types
Specific types are introduced for each format version and used whenever
possible. For example, referring to a specific version of the
`EditManager` format is now done with an instance of
`EditManagerFormatVersion` instead of a plain `number` or
`FormatVersion`.
This makes clearer what the space of version number is being addressed.
The type acts as a code reference that can be followed with Ctrl+Click.
This also enforces that version literals correspond to a valid version
for the target version space. For example, the code `const
editManagerVersion: EditManagerFormatVersion = 42;` will not compile
because there is no version 42 for the edit manager format.
### Queryable Codec Trees
This PR introduces the `CodecTree` type so that dependencies between
codec versions can be reified. Most codecs involved in SharedTree now
come with an associated free function that returns a `CodecTree` for a
given version of that codec.
These are used in a new set of snapshot tests that capture the codec
dependency trees of each SharedTree format version. While the primary
motivation of such tests is to end up with files that can easily be
inspected, these tests also have value in preventing unintentional
changes in codec dependencies.
## Other Changes
The changes involved in building the above have also led to the
realization that some dependencies were hard coded in the wrong place:
the format version for representing SharedTree changes used to be hard
coded in the `EditManager` and `Message` codecs. This was questionable
because `EditManager` and `Message` are completely agnostic to such
details. These dependencies are now hard-coded in sharedTree.ts.
## Breaking Changes
None
Copy file name to clipboardExpand all lines: packages/dds/tree/docs/main/compatibility.md
+8Lines changed: 8 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -215,6 +215,14 @@ For example, a format change in `SchemaChangeCodec` could be implemented by addi
215
215
This new version would use the same code for all bits of `MessageCodec`, `EditManagerCodec`, and `SharedTreeChangeFamilyCodec`, but pass enough context down to `SchemaChangeCodec` to resolve to the newer format.
216
216
In this manner, the mapping between explicitly versioned data and implicitly versioned data for composed codecs is managed in code.
217
217
218
+
## Auditing Codec Resolution
219
+
220
+
Because the dependencies between different codec versions are distributed over the various codec layers,
221
+
it can be hard to understand the relationship between top-level `SharedTreeFormatVersion` values from [sharedTree.ts](../../src/shared-tree/sharedTree.ts)
222
+
and the myriad of codec versions available.
223
+
To help audit such relationships, the `getCodecTreeForSharedTreeFormat` function in [sharedTree.ts](../../src/shared-tree/sharedTree.ts) can be used.
224
+
Snapshots of the dependencies are captured in the ["SharedTree Codecs"](../../src/test/shared-tree/sharedTreeCodecs.spec.ts) test suite and can be inspected [on disc](../../src/test/snapshots/codec-tree/SharedTreeFormatVersion.v1.json).
225
+
218
226
## Current code guidelines
219
227
220
228
Codecs which explicitly version their data should export a codec which takes in a write version and supports reading all supported versions.
0 commit comments