-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
docs via example apps #1376
docs via example apps #1376
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #1376 +/- ##
========================================
Coverage 62.16% 62.16%
========================================
Files 103 103
Lines 5838 5838
========================================
Hits 3629 3629
Misses 1999 1999
Partials 210 210 |
64e3f9f
to
1178589
Compare
eb5dba6
to
6a5a8b4
Compare
This is still a WIP but a lot of the content is in place in a really good way again and I think we could merge to develop and then pick up from 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.
This is great @ebuchman. It helped me a lot in terms of understanding the overall SDK structure. I left a few comments and questions 👍
There are still a handful of TODO's so I take it this is still a WIP?
docs/core/app1.md
Outdated
} | ||
``` | ||
|
||
Note it is unforgiving - it panics on nil keys! |
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.
Is it desirable to panic on nil
keys here? Or can we bubble an error upstream to handle gracefully...or panic?
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.
docs/core/app1.md
Outdated
|
||
We have only a single message type, so just one message-specific function to define, `handleMsgSend`. | ||
|
||
Note this handler has unfettered access to the store specified by the capability key `keyAcc`. So it must also define items in the store are encoded. |
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.
So it must also define items in the store are encoded.
A bit confusing to me.
docs/core/app1.md
Outdated
|
||
```go | ||
// Handle MsgSend. | ||
// NOTE: msg.From, msg.To, and msg.Amount were already validated |
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.
Do you think it might be worthwhile mentioning how and where validation occurs (i.e. What calls ValidateBasic
?
docs/core/app2.md
Outdated
sdk.Msg | ||
|
||
PubKey crypto.PubKey | ||
Signature crypto.Signature |
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.
Bad indentation here :)
docs/core/examples/app2.go
Outdated
} | ||
|
||
// Return error result if msg Issuer is not equal to coin issuer | ||
if !reflect.DeepEqual(metadata.Issuer, msg.Issuer) { |
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.
Not sure what the overhead of reflect is here, but do you think it'll be easier to understand and slightly more performant if we do: bytes.Equal(metadata.Issuer.Bytes(), msg.Issuer.Bytes())
?
docs/core/app3.md
Outdated
amount of coins in an account: | ||
|
||
```go | ||
acc := GetAccount(ctx, addr) |
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.
acc := accountMapper.GetAccount(ctx, addr)
?
docs/core/app3.md
Outdated
the store. | ||
|
||
Creating an AccountMapper is easy - we just need to specify a codec, a | ||
capability key, and a prototype of the object being encoded (TODO: change to |
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.
How do we anticipate the constructor changing?
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.
instead of passing in a prototype, we pass in a constructor: #1379
docs/core/app3.md
Outdated
The PubKey is required for signature verification, but it is only required in | ||
the StdSignature once. From that point on, it will be stored in the account. | ||
|
||
The fee is paid by the first address returned by `msg.GetSigners()` for the first `Msg`. |
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.
I see this function, but in the actual Antehandler impl, I don't see this being called? It just uses the first sig it sees from the TX.
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.
first sig in the tx must match first signer in the msgs
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.
I meant I don't see FeePayer
actually being used, but I don't think it's a big deal.
docs/core/app3.md
Outdated
|
||
Earlier, we noted that `Mappers` abstactions over a KVStore that handles marshalling and unmarshalling a | ||
particular data type to and from the underlying store. We can build another | ||
abstraction on top of `Mappers` that we call `Keepers`, which expose only |
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.
👌 I really like this abstraction
docs/core/examples/app3.go
Outdated
accountMapper := auth.NewAccountMapper(cdc, keyAccount, &auth.BaseAccount{}) | ||
accountKeeper := bank.NewKeeper(accountMapper) | ||
metadataMapper := NewApp3MetaDataMapper(keyMain) | ||
feeKeeper := auth.NewFeeCollectionKeeper(cdc, keyFees) |
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.
The underlying implementation also performs serialization logic which makes it seem more of a mapper. Can Keepers also perform the same logic as Mappers? Seems like a bit of a blurry line.
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.
left as a TODO for now to clarify the feeKeeper (not sure if we can remove it from the base AnteHandler, or else we need to say something like we'll explain it after since we introduce the AnteHandler first
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.
Changes look great! I think it's good step forward indeed.
Apps1-3 are basically complete. Everything else still needs a bunch of work, but all the links work and every thing at least points in the direction of more information until we have time to fill things in and explain properly :) We should spend some time on the UX before we provide full docs for the CLI. In the meantime we just point to the testnet tutorial. We should keep working on the writing for app4-5 and the Eventually, we'll want to also add a See some follow up notes in #1445 |
Implements #1330