-
Notifications
You must be signed in to change notification settings - Fork 213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Translate subset of Wallet API to Servant #76
Conversation
d6d22da
to
8557eaf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good. I have a few questions and one comment.
@jonathanknowles I've continued the work on this PR with some of the points we raised during reviews (cf the commit history). I haven't got time to finalize aligning the primitives with the API and moving types around but it's almost there 👌 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good.
Maybe later - some tests for parsing JSON with invalid amounts/percentages/wallet names.
I also feel (and this may be nitpicking) that |
Didn't do in the previous commit not to mess with git and makes it easy to understand what happened to that file (shows a rename in the git history).
* One space before opening brackets, everywhere. * No multiple consecutive blank lines.
…or types with units of measure.
I tend to agree with this. Having |
The API we provide is an API for the wallet, rather than for Cardano as a whole.
e9f0e03
to
85e386d
Compare
Well... not really :/ ---> #76 (comment) There were still a few types to be moved from the Api.Types to the wallet primitive as mentioned. We have quite a few duplicated logic between both layers and the Api should just be about representing those internal types in Servant / JSON (like I started for |
Translate a subset of the Wallet API to Servant. (See Issue #53)
Included in this PR
This PR:
wallets
namespace.Not included in this PR
This PR:
Design choices
This PR makes some design choices, which should be reviewed.
1. Place each type in a separate module
Reasons:
Example:
WalletName
cannot be constructed without a valid name.2. Favour simple generic JSON encoding
Manually-written JSON code can be tricky to debug.
This PR makes the choice of using generically-derived
ToJSON
andFromJSON
instances wherever possible.Whenever there's a non-trivial mapping between a Haskell type and a desired encoding, we encode the desired structure in a new Haskell type that's closer to the desired encoding, and write a pair of conversion functions that can easily be checked by the compiler.
For example:
WalletState
provides an idiomatic Haskell encoding of a wallet's restoration state, but we also provideUnvalidatedWalletState
as a type that is more trivial to encode as JSON. We providevalidate
andunvalidate
to convert between these two types.