chore: fix spelling errors (backport #22888) (#22899)

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:
mergify[bot] 2024-12-16 18:46:00 +01:00 committed by GitHub
parent 896911659d
commit 9b38363003
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
4 changed files with 5 additions and 5 deletions

View File

@ -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

View File

@ -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

View File

@ -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).

View File

@ -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.