Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: marbar3778 <marbar3778@yahoo.com>
This commit is contained in:
parent
896911659d
commit
9b38363003
@ -72,7 +72,7 @@ type (
|
||||
// MarshalInterface is a helper method which will wrap `i` into `Any` for correct
|
||||
// binary interface (de)serialization.
|
||||
MarshalInterface(i proto.Message) ([]byte, error)
|
||||
// UnmarshalInterface is a helper method which will parse binary enoded data
|
||||
// UnmarshalInterface is a helper method which will parse binary encoded data
|
||||
// into `Any` and unpack any into the `ptr`. It fails if the target interface type
|
||||
// is not registered in codec, or is not compatible with the serialized data
|
||||
UnmarshalInterface(bz []byte, ptr interface{}) error
|
||||
@ -88,7 +88,7 @@ type (
|
||||
// MarshalInterfaceJSON is a helper method which will wrap `i` into `Any` for correct
|
||||
// JSON interface (de)serialization.
|
||||
MarshalInterfaceJSON(i proto.Message) ([]byte, error)
|
||||
// UnmarshalInterfaceJSON is a helper method which will parse JSON enoded data
|
||||
// UnmarshalInterfaceJSON is a helper method which will parse JSON encoded data
|
||||
// into `Any` and unpack any into the `ptr`. It fails if the target interface type
|
||||
// is not registered in codec, or is not compatible with the serialized data
|
||||
UnmarshalInterfaceJSON(bz []byte, ptr interface{}) error
|
||||
|
||||
@ -378,7 +378,7 @@ replacing `Keeper` interfaces altogether.
|
||||
|
||||
* an alternative to keepers which can more easily lead to stable inter-module interfaces
|
||||
* proper inter-module OCAPs
|
||||
* improved module developer DevX, as commented on by several particpants on
|
||||
* improved module developer DevX, as commented on by several participants on
|
||||
[Architecture Review Call, Dec 3](https://hackmd.io/E0wxxOvRQ5qVmTf6N_k84Q)
|
||||
* lays the groundwork for what can be a greatly simplified `app.go`
|
||||
* router can be setup to enforce atomic transactions for module-to-module calls
|
||||
|
||||
2
docs/build/building-modules/00-intro.md
vendored
2
docs/build/building-modules/00-intro.md
vendored
@ -63,7 +63,7 @@ While there are no definitive guidelines for writing modules, here are some impo
|
||||
The SDK provides a set of APIs that a module can implement, and a set of services that a module can use.
|
||||
Those APIs are defined in the `cosmossdk.io/core/appmodule` package, and are used to defined the module capabilities, which is used by `runtime` during the wiring of the application.
|
||||
|
||||
Whenever possible, a module should strive to use only the core APIs (`cosmossdk.io/core`) and not import the `github.com/cosmos/cosmos-sdk` module. This makes modules reusable accross SDK versions and reduces the risk of breaking changes.
|
||||
Whenever possible, a module should strive to use only the core APIs (`cosmossdk.io/core`) and not import the `github.com/cosmos/cosmos-sdk` module. This makes modules reusable across SDK versions and reduces the risk of breaking changes.
|
||||
|
||||
Learn more about the core APIs for modules [here](../../learn/advanced/02-core.md).
|
||||
|
||||
|
||||
@ -59,7 +59,7 @@ In general, the core of the state-machine is defined in a file called `app.go`.
|
||||
|
||||
The first thing defined in `app.go` is the `type` of the application. It is generally comprised of the following parts:
|
||||
|
||||
* **Embeding [runtime.App](../../build/building-apps/00-runtime.md)** The runtime package manages the application's core components and modules through dependency injection. It provides declarative configuration for module management, state storage, and ABCI handling.
|
||||
* **Embedding [runtime.App](../../build/building-apps/00-runtime.md)** The runtime package manages the application's core components and modules through dependency injection. It provides declarative configuration for module management, state storage, and ABCI handling.
|
||||
* `Runtime` wraps `baseapp`, meaning when a transaction is relayed by CometBFT to the application, `app` uses `runtime`'s methods to route them to the appropriate module. Baseapp implements all the [ABCI methods](https://docs.cometbft.com/v1.0/spec/abci/) and the [routing logic](../advanced/00-baseapp.md#service-routers).
|
||||
* It configures automatically the **[module manager](../../build/building-modules/01-module-manager.md#manager)** based on the app wiring configuration. The module manager facilitates operations related to these modules, like registering their [`Msg` service](../../build/building-modules/03-msg-services.md) and [gRPC `Query` service](#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`PreBlocker`](#preblocker) and [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker).
|
||||
* [**An App Wiring configuration file**](../../build/building-apps/00-runtime.md) The app wiring configuration file contains the list of application's modules that `runtime` must instantiate. The instantiation of the modules are done using `depinject`. It contains as well at which order the modules `InitGenesis`, `Pre/Begin/EndBlocker` should be executed.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user