Skip to content

Commit

Permalink
Update docs website (#5827)
Browse files Browse the repository at this point in the history
* query-lifecycle and started modules-interfaces

* query-lifecycle first draft done

* module interfaces first draft

* rest and intro skeletons

* rest and intro done

* small edits and links

* comments

* revisions

* cli.md comments

* comments

* minor edits

* better flow for query lifecycle

* add transactions into core

* hans comments

* add transactions into core

* checkout master-docs files

* deleted some

* remove modules readme

* cli.md comments

* comments

* module-interfaces comments

* Merge PR #4857: Add Context concept doc

* working

* working

* finish messages and queries

* handler

* querier

* last comments!

* punctuation

* querier2

* consolidate intro

* querier

* workiiiing

* refactor for new module interface

* karoly review

* working on baseapp doc

* baseapp work

* reorg

* almost there

* finish first draft

* remove old files

* finish intro

* workinnn

* initial commit after rebase

* query-lifecycle and started modules-interfaces

* query-lifecycle first draft done

* module interfaces first draft

* rest and intro skeletons

* rest and intro done

* small edits and links

* comments

* revisions

* cli.md comments

* comments

* minor edits

* better flow for query lifecycle

* checkout master-docs files

* deleted some

* remove modules readme

* cli.md comments

* comments

* module-interfaces comments

* keeper

* genesis

* finish

* Apply suggestions from code review

Co-Authored-By: Hans Schoenburg <hschoenburg@users.noreply.github.com>

* hans review

* Update docs/core/baseapp.md

Co-Authored-By: Hans Schoenburg <hschoenburg@users.noreply.github.com>

* working

* last comment

* workin

* Apply suggestions from code review

* encoding and node

* almost finish store

* finish docs

* fixes

* fede comments + permalinks

* hans review

* add more permalinks

* update docs theme version (#5239)

* R4R: Docs Cleanup (#5246)

* start

* work

* work

* work

* remove table of content

* links intro

* fix links

* remove junk

* cleanup

* cleanup

* work

* finish cleanup

* addback readmes

* remove nft

* fix links

* remove dup

* remove dup

* remove dup

* remove dup

* remove dup

* fix links

* add subscribe events

* refine rest

* index page

* sidebar

* theme version

* theme version

* testing netlify

* theme version

* tooltip example

* version

* testing code embedding

* reverting back

* theme version

* version

* version

* version

* readme and version

* cleanup

* redo app anatomy

* modules readme, theme version

* theme version

* fix modules list

* theme version

* new snippets

* modules readme

* update docs readme

* modify synopsis

* version

* fix yaml

* version

* version

* version

* version

* version

* version

* version

* version

* version

* version

* add hide banner

* version

* version

* version

* small fixes

* modules readme, version

* remove hotkeys dep, version

* version

* version

* version

* version

* version

* version

* version

* slight notice

* fix links and hide

* permalinks

* small clean

* version

* resolve conflicts, add google analytics

* fix merge remants

* version

* changelog 1/2

* Changelog: docs UI

* version

* remove merge conflicts

* Code: Update link for Contributing to the docs to docs_readme

* HTML/CSS: Update layout of homepage footer to match new layout in Figma

* version

* final modifs

* modules, version

* modules readme

* link to module list from homepage

* version

* building modules link

* version

* version

* fonts

* version

* version

* fix link

* fix package.json

* links in explore sdk section

* core concepts

* version

* change delimeters for frontmatter

* frontmatter in comments

* version

* temp add tiny-cookie

* fixed link issues

* fixed styling issues, copy

* hide frontmatter

* hide frontmatter

* layout fixes, padded ascii diagram

* fira sans font for code

* scrollbar color

* move synopsis from frontmatter

* move synopsis from frontmatter

* code styling in synopsis fix

* tutorial link

* active headers

* 404 fix

* homepage links fix

* fix link in footer

* misc fixes

* version

* prerequisite links on mobile

* version

* version

* Fix footer links

* version

* Fix permalink popup

* Update version

* package-lock.json

* Update Questions section in the footer

* Config for Algolia Docsearch

* Update version

* Update to the latest version of the theme

* Use docs-staging as a branch for staging website

* Update version

* Add google analytics

* Remove {hide} from Pre-Requisite Readings

* Replace Riot with Discord

Co-Authored-By: billy rennekamp <billy.rennekamp@gmail.com>

* Fix yaml syntax error in docs

* Fix formatting in keyring.md

Co-authored-by: Gloria Zhao <gzhao408@berkeley.edu>
Co-authored-by: gamarin <gautier@tendermint.com>
Co-authored-by: Jack Zampolin <jack.zampolin@gmail.com>
Co-authored-by: Hans Schoenburg <hschoenburg@users.noreply.github.com>
Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com>
Co-authored-by: Alexander Bezobchuk <alexanderbez@users.noreply.github.com>
Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com>
  • Loading branch information
8 people committed Mar 24, 2020
1 parent 999a83d commit 43627d0
Show file tree
Hide file tree
Showing 37 changed files with 1,315 additions and 668 deletions.
16 changes: 7 additions & 9 deletions docs/.vuepress/config.js
Original file line number Diff line number Diff line change
@@ -1,11 +1,6 @@
module.exports = {
theme: "cosmos",
title: "Cosmos SDK",
markdown: {
anchor: {
permalinkSymbol: ""
}
},
head: [
[
"link",
Expand All @@ -23,9 +18,6 @@ module.exports = {
kr: {
lang: "kr"
},
kr: {
lang: "kr"
},
cn: {
lang: "cn"
},
Expand All @@ -40,6 +32,11 @@ module.exports = {
docsDir: "docs",
editLinks: true,
label: "sdk",
algolia: {
id: "BH4D9OD16A",
key: "ac317234e6a42074175369b2f42e9754",
index: "cosmos-sdk"
},
sidebar: [
{
title: "Using the SDK",
Expand Down Expand Up @@ -91,10 +88,11 @@ module.exports = {
}
},
footer: {
questionsText: "Chat with Cosmos developers on [Discord](https://discord.gg/W8trcGV) or reach out on the [SDK Developer Forum](https://forum.cosmos.network/) to learn more.",
logo: "/logo-bw.svg",
textLink: {
text: "cosmos.network",
url: "/"
url: "https://cosmos.network"
},
services: [
{
Expand Down
2 changes: 1 addition & 1 deletion docs/architecture/adr-013-metrics.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ func (bm BasicManager) RegisterMetrics(appName string, labelsAndValues... string
}
```

Each module can define its own `Metrics` type and`CreateMetrics` function in the x/<module>/observability/metrics.go file:
Each module can define its own `Metrics` type and`CreateMetrics` function in the x/\<module\>/observability/metrics.go file:

```go
type Metrics struct {
Expand Down
5 changes: 3 additions & 2 deletions docs/basics/accounts.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 3
synopsis: This document describes the in-built accounts system of the Cosmos SDK.
-->

# Accounts

## Pre-requisite Readings {hide}
This document describes the in-built accounts system of the Cosmos SDK. {synopsis}

### Pre-requisite Readings

- [Anatomy of an SDK Application](./app-anatomy.md) {prereq}

Expand Down
3 changes: 2 additions & 1 deletion docs/basics/app-anatomy.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,11 @@
<!--
order: 1
synopsis: "This document describes the core parts of a Cosmos SDK application. Throughout the document, a placeholder application named `app` will be used."
-->

# Anatomy of an SDK Application

This document describes the core parts of a Cosmos SDK application. Throughout the document, a placeholder application named `app` will be used. {synopsis}

## Node Client

The Daemon, or [Full-Node Client](../core/node.md), is the core process of an SDK-based blockchain. Participants in the network run this process to initialize their state-machine, connect with other full-nodes and update their state-machine as new blocks come in.
Expand Down
5 changes: 3 additions & 2 deletions docs/basics/gas-fees.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 4
synopsis: This document describes the default strategies to handle gas and fees within a Cosmos SDK application.
-->

# Gas and Fees

## Pre-requisite Readings {hide}
This document describes the default strategies to handle gas and fees within a Cosmos SDK application. {synopsis}

### Pre-requisite Readings

- [Anatomy of an SDK Application](./app-anatomy.md) {prereq}

Expand Down
5 changes: 3 additions & 2 deletions docs/basics/tx-lifecycle.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 2
synopsis: "This document describes the lifecycle of a transaction from creation to committed state changes. Transaction definition is described in a [different doc](../core/transactions.md). The transaction will be referred to as `Tx`."
-->

# Transaction Lifecycle

## Pre-requisite Readings {hide}
This document describes the lifecycle of a transaction from creation to committed state changes. Transaction definition is described in a [different doc](../core/transactions.md). The transaction will be referred to as `Tx`. {synopsis}

### Pre-requisite Readings

- [Anatomy of an SDK Application](./app-anatomy.md) {prereq}

Expand Down
5 changes: 3 additions & 2 deletions docs/building-modules/beginblock-endblock.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 6
synopsis: "`BeginBlocker` and `EndBlocker` are optional methods module developers can implement in their module. They will be triggered at the beginning and at the end of each block respectively, when the [`BeginBlock`](../core/baseapp.md#beginblock) and [`EndBlock`](../core/baseapp.md#endblock) ABCI messages are received from the underlying consensus engine."
-->

# BeginBlocker and EndBlocker

## Pre-requisite Readings {hide}
`BeginBlocker` and `EndBlocker` are optional methods module developers can implement in their module. They will be triggered at the beginning and at the end of each block respectively, when the [`BeginBlock`](../core/baseapp.md#beginblock) and [`EndBlock`](../core/baseapp.md#endblock) ABCI messages are received from the underlying consensus engine. {synopsis}

## Pre-requisite Readings

- [Module Manager](./module-manager.md) {prereq}

Expand Down
3 changes: 2 additions & 1 deletion docs/building-modules/errors.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,11 @@
<!--
order: 13
synopsis: This document outlines the recommended usage and APIs for error handling in Cosmos SDK modules.
-->

# Errors

This document outlines the recommended usage and APIs for error handling in Cosmos SDK modules. {synopsis}

Modules are encouraged to define and register their own errors to provide better
context on failed message or handler execution. Typically, these errors should be
common or general errors which can be further wrapped to provide additional specific
Expand Down
5 changes: 3 additions & 2 deletions docs/building-modules/genesis.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 9
synopsis: Modules generally handle a subset of the state and, as such, they need to define the related subset of the genesis file as well as methods to initialize, verify and export it.
-->

# Module Genesis

## Pre-requisite Readings {hide}
Modules generally handle a subset of the state and, as such, they need to define the related subset of the genesis file as well as methods to initialize, verify and export it. {synopsis}

## Pre-requisite Readings

- [Module Manager](./module-manager.md) {prereq}
- [Keepers](./keeper.md) {prereq}
Expand Down
5 changes: 3 additions & 2 deletions docs/building-modules/handler.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 4
synopsis: "A `Handler` designates a function that processes [`message`s](./messages-and-queries.md#messages). `Handler`s are specific to the module in which they are defined, and only process `message`s defined within the said module. They are called from `baseapp` during [`DeliverTx`](../core/baseapp.md#delivertx)."
-->

# Handlers

## Pre-requisite Readings {hide}
A `Handler` designates a function that processes [`message`s](./messages-and-queries.md#messages). `Handler`s are specific to the module in which they are defined, and only process `message`s defined within the said module. They are called from `baseapp` during [`DeliverTx`](../core/baseapp.md#delivertx). {synopsis}

## Pre-requisite Readings

- [Module Manager](./module-manager.md) {prereq}
- [Messages and Queries](./messages-and-queries.md) {prereq}
Expand Down
7 changes: 4 additions & 3 deletions docs/building-modules/intro.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 1
synopsis: Modules define most of the logic of SDK applications. Developers compose module together using the Cosmos SDK to build their custom application-specific blockchains. This document outlines the basic concepts behind SDK modules and how to approach module management.
order: 1
-->

# Introduction to SDK Modules

## Pre-requisite Readings {hide}
Modules define most of the logic of SDK applications. Developers compose module together using the Cosmos SDK to build their custom application-specific blockchains. This document outlines the basic concepts behind SDK modules and how to approach module management. {synopsis}

## Pre-requisite Readings

- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
- [Lifecycle of an SDK transaction](../basics/tx-lifecycle.md) {prereq}
Expand Down
5 changes: 3 additions & 2 deletions docs/building-modules/invariants.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 8
synopsis: "An invariant is a property of the application that should always be true. In the context of the Cosmos SDK, an `Invariant` is a function that checks for a particular invariant. These functions are useful to detect bugs early on and act upon them to limit their potential consequences (e.g. by halting the chain). They are also useful in the development process of the application to detect bugs via simulations."
-->

# Invariants

## Pre-requisite Readings {hide}
An invariant is a property of the application that should always be true. In the context of the Cosmos SDK, an `Invariant` is a function that checks for a particular invariant. These functions are useful to detect bugs early on and act upon them to limit their potential consequences (e.g. by halting the chain). They are also useful in the development process of the application to detect bugs via simulations. {synopsis}

## Pre-requisite Readings

- [Keepers](./keeper.md) {prereq}

Expand Down
5 changes: 3 additions & 2 deletions docs/building-modules/keeper.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 7
synopsis: "`Keeper`s refer to a Cosmos SDK abstraction whose role is to manage access to the subset of the state defined by various modules. `Keeper`s are module-specific, i.e. the subset of state defined by a module can only be accessed by a `keeper` defined in said module. If a module needs to access the subset of state defined by another module, a reference to the second module's internal `keeper` needs to be passed to the first one. This is done in `app.go` during the instantiation of module keepers."
-->

# Keepers

## Pre-requisite Readings {hide}
`Keeper`s refer to a Cosmos SDK abstraction whose role is to manage access to the subset of the state defined by various modules. `Keeper`s are module-specific, i.e. the subset of state defined by a module can only be accessed by a `keeper` defined in said module. If a module needs to access the subset of state defined by another module, a reference to the second module's internal `keeper` needs to be passed to the first one. This is done in `app.go` during the instantiation of module keepers. {synopsis}

## Pre-requisite Readings

- [Introduction to SDK Modules](./intro.md) {prereq}

Expand Down
5 changes: 3 additions & 2 deletions docs/building-modules/messages-and-queries.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 3
synopsis: "`Message`s and `Queries` are the two primary objects handled by modules. Most of the core components defined in a module, like `handler`s, `keeper`s and `querier`s, exist to process `message`s and `queries`."
-->

# Messages and Queries

## Pre-requisite Readings {hide}
`Message`s and `Queries` are the two primary objects handled by modules. Most of the core components defined in a module, like `handler`s, `keeper`s and `querier`s, exist to process `message`s and `queries`. {synopsis}

## Pre-requisite Readings

- [Introduction to SDK Modules](./intro.md) {prereq}

Expand Down
5 changes: 3 additions & 2 deletions docs/building-modules/module-interfaces.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 11
synopsis: This document details how to build CLI and REST interfaces for a module. Examples from various SDK modules are included.
-->

# Module Interfaces

## Pre-requisite Readings {hide}
This document details how to build CLI and REST interfaces for a module. Examples from various SDK modules are included. {synopsis}

## Pre-requisite Readings

* [Building Modules Intro](./intro.md) {prereq}

Expand Down
5 changes: 3 additions & 2 deletions docs/building-modules/module-manager.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 2
synopsis: "Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](../core/baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`BeginBlocker` and `EndBlocker`](../basics/app-anatomy.md#begingblocker-and-endblocker)."
-->

# Module Manager

## Pre-requisite Readings {hide}
Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](../core/baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`BeginBlocker` and `EndBlocker`](../basics/app-anatomy.md#begingblocker-and-endblocker). {synopsis}

## Pre-requisite Readings

- [Introduction to SDK Modules](./intro.md) {prereq}

Expand Down
5 changes: 3 additions & 2 deletions docs/building-modules/querier.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 5
synopsis: "A `Querier` designates a function that processes [`queries`](./messages-and-queries.md#queries). `querier`s are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `baseapp`'s [`Query` method](../core/baseapp.md#query)."
-->

# Queriers

## Pre-requisite Readings {hide}
A `Querier` designates a function that processes [`queries`](./messages-and-queries.md#queries). `querier`s are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `baseapp`'s [`Query` method](../core/baseapp.md#query). {synopsis}

## Pre-requisite Readings

- [Module Manager](./module-manager.md) {prereq}
- [Messages and Queries](./messages-and-queries.md) {prereq}
Expand Down
5 changes: 2 additions & 3 deletions docs/building-modules/structure.md
Original file line number Diff line number Diff line change
@@ -1,12 +1,11 @@
<!--
order: 12
synopsis: This document outlines the recommended structure of Cosmos SDK modules.These ideas are
meant to be applied as suggestions. Application developers are encouraged to improve upon and
contribute to module structure and development design.
-->

# Recommended Folder Structure

This document outlines the recommended structure of Cosmos SDK modules. These ideas are meant to be applied as suggestions. Application developers are encouraged to improve upon and contribute to module structure and development design. {synopsis}

## Structure

A typical Cosmos SDK module can be structured as follows:
Expand Down
5 changes: 3 additions & 2 deletions docs/core/baseapp.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 1
synopsis: This document describes `BaseApp`, the abstraction that implements the core functionalities of an SDK application.
-->

# Baseapp

## Pre-requisite Readings {hide}
This document describes `BaseApp`, the abstraction that implements the core functionalities of an SDK application. {synopsis}

## Pre-requisite Readings

- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
- [Lifecycle of an SDK transaction](../basics/tx-lifecycle.md) {prereq}
Expand Down
5 changes: 3 additions & 2 deletions docs/core/context.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 3
synopsis: The `context` is a data structure intended to be passed from function to function that carries information about the current state of the application. It holds a cached copy of the entire state as well as useful objects and information like `gasMeter`, `block height`, `consensus parameters` and more.
-->

# Context

## Pre-requisites Readings {hide}
The `context` is a data structure intended to be passed from function to function that carries information about the current state of the application. It holds a cached copy of the entire state as well as useful objects and information like `gasMeter`, `block height`, `consensus parameters` and more. {synopsis}

## Pre-requisites Readings

- [Anatomy of an SDK Application](../basics/app-anatomy.md) {prereq}
- [Lifecycle of a Transaction](../basics/tx-lifecycle.md) {prereq}
Expand Down
5 changes: 2 additions & 3 deletions docs/core/encoding.md
Original file line number Diff line number Diff line change
@@ -1,13 +1,12 @@
<!--
order: 6
synopsis: Amino and Protobuf are the primary binary wire encoding schemes in the Cosmos SDK.
-->

# Encoding

> NOTE: This document a WIP.
The `codec` is used everywhere in the Cosmos SDK to encode and decode structs and interfaces. The specific codec used in the Cosmos SDK is called `go-amino`. {synopsis}

## Pre-requisite Readings {hide}
## Pre-requisite Readings

- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}

Expand Down
7 changes: 3 additions & 4 deletions docs/core/events.md
Original file line number Diff line number Diff line change
@@ -1,13 +1,12 @@
<!--
order: 7
synopsis: "`Event`s are objects that contain information about the execution of the application.
They are mainly used by service providers like block explorers and wallet to track the execution of
various messages and index transactions."
-->

# Events

## Pre-Requisite Readings {hide}
`Event`s are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. {synopsis}

## Pre-requisite Readings

- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}

Expand Down
5 changes: 3 additions & 2 deletions docs/core/node.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 4
synopsis: The main endpoint of an SDK application is the daemon client, otherwise known as the full-node client. The full-node runs the state-machine, starting from a genesis file. It connects to peers running the same client in order to receive and relay transactions, block proposals and signatures. The full-node is constituted of the application, defined with the Cosmos SDK, and of a consensus engine connected to the application via the ABCI.
-->

# Node Client (Daemon)

## Pre-requisite Readings {hide}
The main endpoint of an SDK application is the daemon client, otherwise known as the full-node client. The full-node runs the state-machine, starting from a genesis file. It connects to peers running the same client in order to receive and relay transactions, block proposals and signatures. The full-node is constituted of the application, defined with the Cosmos SDK, and of a consensus engine connected to the application via the ABCI. {synopsis}

## Pre-requisite Readings

- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}

Expand Down
5 changes: 3 additions & 2 deletions docs/core/store.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
<!--
order: 5
synopsis: A store is a data structure that holds the state of the application.
-->

# Store

## Pre-requisite Readings {hide}
A store is a data structure that holds the state of the application. {synopsis}

### Pre-requisite Readings

- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}

Expand Down
Loading

0 comments on commit 43627d0

Please sign in to comment.