feat: snapshot read metadata response type and mapper#1079
Merged
peterpeterparker merged 3 commits intomainfrom Oct 3, 2025
Merged
feat: snapshot read metadata response type and mapper#1079peterpeterparker merged 3 commits intomainfrom
peterpeterparker merged 3 commits intomainfrom
Conversation
Signed-off-by: David Dal Busco <david.dalbusco@dfinity.org>
Contributor
size-limit report 📦
|
Signed-off-by: David Dal Busco <david.dalbusco@dfinity.org>
AntonioVentilii
approved these changes
Oct 3, 2025
Collaborator
AntonioVentilii
left a comment
AntonioVentilii
left a comment
There was a problem hiding this comment.
LGTM tks!
I left two suggestions, but up to you
peterpeterparker
added a commit
that referenced
this pull request
Oct 3, 2025
# Motivation A cool idea of @AntonioVentilii shared in this [review](#1079 (comment)): in addition to throwing when a variant is unknown, which can happens when the did types are extended in the IC repo, we can also type the rest to detect the issue at build time. Given there are various usage of the pattern in ic-js, I thought that creating a reusable function can be handy. # Notes I don't know how to actually implement a vitest that would passes the build with an incompatible code. Thought it was kind of a quite an effort so skipped that part. That said we can assert it works out as implementing the function in nns allows to detect that missing types are not implemented, see #1083. # Changes - Create `assertNever` --------- Signed-off-by: David Dal Busco <david.dalbusco@dfinity.org> Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
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
2 participants
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.
Motivation
When I developed support for the read and upload snapshot feature in #1046, I was really hesitant about whether to parse/map the metadata response. On one hand, for consistency with the other functions in the module, we should not parse the response, since none of the other functions do so. On the other hand, we already use custom parameters for the exposed parts of the module, a pattern that should also apply when implementing the upload metadata of the snapshot.
Ultimately, I decided it would be more practical for the consumer to receive a mapped object when reading data. This way, the consumer can simply download a value and pass the same back on upload, without having to implement additional conversions on their side.
I validated this approach with my implementation in Juno's CLI (PR 382).
That said, I’m still not fully satisfied with it. Generally speaking, I hope we’ll find a solution in the future that makes both inputs and outputs consistent.
Changes
Notes
I exposed the all
snapshot.responsemodule inindex.ts, not just the interface, for consistency reasons because we do so with the params.