docs(arfs): name the snapshot body field jsonMetadata, not dataJson - #137
Open
vilenarios wants to merge 1 commit into
Open
docs(arfs): name the snapshot body field jsonMetadata, not dataJson#137vilenarios wants to merge 1 commit into
vilenarios wants to merge 1 commit into
Conversation
The Snapshot Entity Data section documents the per-entry metadata field as `dataJson`. Both implementations write and read `jsonMetadata`: - ardrive-web `lib/utils/snapshots/snapshot_types.dart` (`TxSnapshot`, serialized by `tx_snapshot_to_snapshot_data.dart`) and read back in `snapshot_item.dart` as `item['jsonMetadata']` - ardrive-core-js `src/snapshots/snapshot_types.ts` (`TxSnapshot`) A client written from this page emits a key neither reader looks for, so every entity in its snapshots reads as having no metadata — silently, since a missing metadata body is a legitimate state. `dataJson` also already means something else in this ecosystem: an entity's own Data JSON custom metadata fields, in ardrive-core-js `arfs_builders.ts`. Three further corrections to the same passage: - `tsSnapshot` was a typo for `txSnapshot`. - The prose said the `gqlNode` object "also contains" the metadata field. It does not; the two are siblings, as the example on this page already showed. - The field is a string, and may be null for an entry captured for its GQL node alone. It was described as an object.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Snapshot Entity Data section documents the per-entry metadata field as
dataJson. Both implementations write and readjsonMetadata.TxSnapshotinlib/utils/snapshots/snapshot_types.dart, serialised bytx_snapshot_to_snapshot_data.dart, and read back insnapshot_item.dartasitem['jsonMetadata']TxSnapshotinsrc/snapshots/snapshot_types.tsA client written from this page emits a key neither reader looks for, so every entity in its snapshots reads as having no metadata — and silently, because a missing metadata body is a legitimate state for an entry captured for its GQL node alone. Nothing errors; the data is just never there.
dataJsonalso already means something else in this ecosystem: an entity's own Data JSON custom-metadata fields, in ardrive-core-jssrc/arfs/arfs_builders/arfs_builders.ts. So the page is not only wrong, it overloads a term with an established and different meaning.Three further corrections to the same passage:
tsSnapshotwas a typo fortxSnapshot.gqlNodeobject "also contains" the metadata field. It does not — the two are siblings, as the JSON example on this page already showed. Prose and example contradicted each other.nullfor an entry captured for its GQL node alone. It was described as an object.This is independent of any current feature work — it is a live documentation bug against every snapshot already on chain.
🤖 Generated with Claude Code
https://claude.ai/code/session_01LFV6xYmFz2meXf5EW2M1FB